このサイトは、只今WEB業界で活躍中のデザイナー、プログラマーの方々の情報を集めたweb統合情報サイトです。

Archives Details

Django django-rest-auth + Nuxt.js auth-module で作る SPA JWT OAuth ログインシステム その1

Python

2020.06.07

この記事は最終更新日から1年以上が経過しています。

どもです。

今回は、Django(django-rest-auth)と、Nuxt.jsを使って、SPAサイト(マイクロサービス)における、OAuth認可の仕組みを使ってJWTログインの仕組みを作って行きましょう。

という事で、どういう事?と思っている方も少なくないかと思われますので、端的に説明させて頂きます。

まずフロント、サーバー等の構成は以下の様な感じとなります。

SPAなどマイクロサービスにおけるよくある構成かと思います。

フロントエンドにNuxt.js、サーバーサイドにdjango、OAuthプロバイダーサーバーと言った構成となります。

これは、フロントエンドがReactでもAngularでも、バックエンドサーバがRailsでも、SpringBootでも違いはありません。

OAuth認証認可フレームワークを用いた、ソーシャルログインを実装しようとすると、色んな形がありますが、上記の様な構成の場合は、OAuth2.0、OIDC(Open ID Connect)での、マルチプルレスポンスタイプである、ハイブリッドフローでの実装が最適なOAuthグラントタイプだと考えます。

 

OAuth 2.0 Multiple Response Type Encoding Practices

https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

 

モノリシックな構成の時とは異なり、SPA構成ではフロント側での画面遷移の処理が行われます。

フロントエンド側にOAuthログインの為、コンフィデンシャルであるプロバイダーのシークレットキー等を保持することは、安易にシークレット情報漏洩させる形となりますので、コンフィデンシャルクライアントであるdjango側にシークレットキーを保持し、フロント、サーバーと両方で認証(検証)を行う形となります。

今回は、このSPAとコンフィデンシャルクライアント構成の場合、最適と思われるハイブリッドフローを用いて、認証認可にJWTを用いて実装を行っていきたいと思います。

ここで、軽く OAuthフロー等をまとめてみたいと思います。

OAuthおさらい

OAuth ロール
名称 概要
リソースオーナー(ユーザー)  ユーザーのデータの所有者。

サービス上で、画像や動画アップロード後、閲覧編集できるユーザー。

クライアント 上記の保護されたリソースにアクセスできるアプリケーション。web、ネイティブアプリ問わず。
認可サーバー リソースオーナーの認証、クライアントのリソースアクセスの許可、アクセストークン発行などを担う。
リソースサーバー 画像や動画などの機能を提供するサービス。

リソースオーナーがアクセスを許可し、主にアクセストークンを用いてリソースにアクセスする。

OAuthのロール(登場人物)は主に4つ。

詳細は割愛させてもらいます。

 

 グラントタイプ
名称 概要
認可コードグラント  コンフィデンシャルクライアントに最適化されたグラントタイプ。
インプリシットグラント  非推奨。

パブリッククライアントのためのグラントタイプ。

認可コードグラント+PKCEを推奨されている。

クライアントクレデンシャルグラント  クライアントと認可サーバー間だけのやり取りのグラントタイプ。
リソースオーナーパスワードクレデンシャルグラント リソースサーバー及び認可サーバーとクライアンと提供が同じの場合のグラントタイプ。
ハイブリッドフロー  インプリシットフローと認可コードフローのハイブリッドなフロー。

ここで、まず注目するところは「インプリシットグラント」でしょう。

パブリッククライアント。つまりwebアプリケーションやネイティブアプリケーション向けのためのグラントタイプではありますが、非推奨となっております。

非推奨となった理由としまして、アクセストークンがリダイレクトでクライアントに受け渡されるため、漏洩や置き換えのリスクが生じるのが主な理由となってます。

そのため、置き換えを防ぐためSender-Constrainedアクセストークンを用いる方法も提示されていますが、webやネイティブアプリなどクライアントIDやクライアントシークレットをセキュアに保存できない、パブリッククライアントには適応できず、認可コードグラント+PKCEを用いたフローが推奨されております。

OAuth 2.0 Security Best Current Practice

PKCE(Proof Key for Code Exchange)は、OAuthの拡張仕様(RFC7636)で、定義されている仕様で、パブリッククライアント、ネイティブアプリでのOAuthを利用する場合の脆弱性を防ぐ仕組みとなっております。

PKCEは、code_verifierやcode_challengeを用いて検証するフローとなりますが、詳細に関しては他の有志たちなどがネットなどにアッ

プされていて、多くの解説もあることと、今回OAuth認証フローの解説ではなく実装に関する解説ということもあって割愛させて頂きます。

それと、今回Djangoでのサーバーサイドがあり、コンフィデンシャルクライアントが存在するのもあって、別のフローを検討していきます。

OpenID connect(OIDC)

という訳で、OAuth認証に関して見てきましたので、OpenID connect(OIDC)も見ていきたいと思います。

OpenID connect(OIDC)は、OAuthの拡張されたもので、IDトークンとUserInfoエンドポイントが加えられた仕組みとなります。

OpenID connect(OIDC) ロール
名称 概要
エンドユーザー OAuthでのリソースオーナーに相当。

OIDCでは、リソースの概念がないので単にエンドユーザーとなる。

リライング・パーティー OAuthでのクライアントに相当。
IDプロバイダ OAuthでの認可サーバーに相当。

OIDCでは、IDトークン、アクセストークンを発行するものはIDプロバイダとなる。

UserInfoエンド OAuthでのリソースサーバーに相当。

OIDCで提供されるリソースはプロフィール情報のみとなるため、UserIfoエンドポイントが定義されている。

scopeに「openid」を指定することによって、OIDCでのシーケンスを開始することを宣言します。

よって、OIDCではscopeにopenidの指定が必須となります。

 

フロー
名称 概要
認可コードフロー  コンフィデンシャルクライアントに最適化されたフロー。
インプリシットフロー  パブリッククライアントのためのフロー。
ハイブリッドフロー インプリシットフローと認可コードフローのハイブリッドなフロー。

OpenID connect(OIDC)では、グラントタイプと呼ばれていたものがフローとして呼ばれております。

また、クライアントクレデンシャルグラント、リソースオーナーパスワードクレデンシャルグラントなどに該当するものがなく3つとなっております。

と、OAuthグラントタイプでもあった「ハイブリッドフロー」について見ていきます。

ここで、ようやく冒頭のOAuth 2.0 Multiple Response Typeに関してのお話となります。

OAuth 2.0 Multiple Response Type Encoding Practices

https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

 

ハイブリッドフローとは?

ハイブリッドフローはインプリシットフローと認可コードフローのハイブリッドなフローてとなります。

パブリッククライアント(今回でいうとNuxt.js)とコンフィデンシャルクライアント(今回でいうとDjango)の両方で構成されているクライアントに主に利用されます。

フローの切り替えは認証リクエストに含まれる「response_type」の値として「code」「token」「id_token」を複数指定することによって切り替えることができ、認証レスポンスに含まれるトークンも変化されます。

指定方法と、フローの切り替えは以下の通りとなります。

 

response_type とフロー
response_type フロー
code 認可コードフロー
id_token インプリシットフロー
id_token token インプリシットフロー
code id_token ハイブリッドフロー
code token ハイブリッドフロー
code id_token token ハイブリッドフロー

 

実装するresponse_type とフローとシーケンス

と、言うわけで、ざっくりとOAuthとOIDCに関しておさらいをしてきました。

そこで、今回実装するresponse_typeとフローは、上記の表の

「code token」のハイブリッドフロー となります。

フロントエンドにNuxt.js、サーバーサイドにdjangoを用いた簡易なシーケンスは以下の通りとなります。

 

こうすることによって、シークレット情報漏洩させることなくSPAサイトでのOAuth認証ログインの仕組みが作れそうです。

と、ちょっと長くなりそうなので、続きは次回にしたいと思います。

まず、次回はDjango側の実装から進めて行きたいと思います。

ではではぁ。

続きはこちら、

Django django-rest-auth + Nuxt.js auth-module で作る SPA JWT OAuth ログインシステム その2

Comment

Related Article

【M1 Mac】Python ScrapyがImportErrorで大ハマリ。lxmlなど環境作成し対応した件。

2023.05.24

Django (DRF)で、ユーザーのモデルを作成時にハッシュidを別で保存する。

2020.09.10

macOS pyenv環境でtkinterが動かないので、再度インストール

2020.08.09

Django django-rest-auth + Nuxt.js auth-module で作る SPA JWT OAuth ログインシステム その3

2020.06.14

Django django-rest-auth + Nuxt.js auth-module で作る SPA JWT OAuth ログインシステム その2

2020.06.08

Django django-rest-auth + Nuxt.js auth-module で作る SPA JWT OAuth ログインシステム その1

2020.06.07

Django django-allauthで、サクッとソーシャルログイン機能を実装

2020.04.12

PythonでGUIアプリ開発「PyQt」を使った感想

2019.07.18

CATEGORY LIST

LATEST NEWS

Mac 容量足りない問題は、外付けSSDで快適に解決!おすすめ外付けSSD

mac

2024.10.16

Z80エミュレータ- EMUZ80の組み立て

電子工作

2024.10.13

Mac VSCodeで、SFML C++開発環境を作る。

C++

2024.09.09

Rust-SDL2 examplesをすべて試す

Rust

2024.09.01

JavaScriptで、DOMを放り投げる処理

JavaScript

2024.07.27

Rustで創る MOS 6502 CPU その2

Rust

2024.07.23

Rustで創る MOS 6502 CPU その1

Rust

2024.07.19

汎用 3D mesh/model viewerを求め。と、簡単に、FBXファイルをglTF(glb)に変換ツールを求め。

C++

2024.06.06

M1 Macで、OpenGL GLUTを使ってコンパイルする

C

2024.04.27

Rust - Actix Web mongo ユーザー登録 JWT認証

Rust

2024.03.24

Rust - Actix Web JWT 認証認可 APIの作成

Rust

2024.02.25

Rust - Actix Web × JSON 静的ファイルをAPIで返却

Rust

2024.01.19

RANKING

Follow

SPONSOR

現在、掲載募集中です。



Links

About Us

WEBデザイナーの、WEBデザイナーによる、WEBデザイナーの為のサイト。「みんなで書こう!」と仲間を募ってみたが、結局書くのは自分だけとなってしまいました。日々のメモを綴っていきます。

Entry Profile

Graphical FrontEnd Engineer
- Daisuke Takayama

MAD CITY 北九州市で生まれ育つ。20代はバンド活動に明け暮れ、ふと「webデザイナーになりたい。」と思い、デジタルハリウッド福岡校入学。卒業後、数々の賞を受賞、web業界をざわつかせる。
現在、主に、ゲーム制作中心に港区六本木界隈で活動中。

FOLLOW US