OAuth 2.0とOIDCの理解は、ウェブアプリケーションのセキュリティを確保するために重要です。この記事では、これらのプロトコルがAuth0上どのように機能し相互に関連しているのかを解説します。アプリケーション開発者が認証基盤への理解をより深める一助となることを目的としています。
データモデル
以下の図はAuth0の主要機能から抽出したデータモデルです。
注) Auth0が公式で公開しているものではありません。
用語の解説
データモデル中の用語について解説します。
| 用語 | 読み | 説明 |
|---|---|---|
| Auth0 Tenant | オースゼロテナント | このモデルを束ねるルート。本番環境、開発環境のような単位でテナントを分けることが多い。 |
| Authorization server | オーソリゼーションサーバー | OAuth 2.0で定義されているユーザの身元を確認または拒否するサーバー。OIDCで定義されているOpenID Provider(OP)は通常これを指す。 Auth0テナントにつき1つ提供される。 |
| Connection | コネクション | Auth0ではこの単位で複数のユーザーが境界付けされる。デフォルトではAuth0の内部データベースが一つ用意されている。それ以外には、例えばGoogle(ソーシャル)ログイン、パスワードレスログインといった認証方法の単位でコネクションを新しく作ることができる。 |
| User | ユーザー | ユーザーはコネクションに紐づく。そのため、エンドユーザーが複数の認証方法でログインした場合、別々のユーザーとして認識される。 |
| Account Linking | アカウントリンキング | 認証方法が異なるだけの同じエンドユーザーをまとめたい場合、親となるユーザーを指定してそのユーザーに複数のユーザーを紐付けることができる。紐付けのロジックはActionsにて任意のスクリプトを定義する。 |
| Application | アプリケーション | OAuth 2.0で定義されるクライアントを表す。Auth0ではユーザーは必ずアプリケーションを一つだけ選択してログインする必要がある。 |
| 3rd-party Application | サードパーティーアプリケーション | Auth0でアプリケーションを作ると、デフォルトでは自身の保有するアプリケーション(1st party)となるが、自身以外の人が保有するアプリケーション(3rd party)を登録することも可能。この区別は各機能を横断する形でセキュリティレベルに影響を与える。例えば1st partyであれば、スコープ同意画面をスキップすることができる。 |
| M2M Application | エムツーエムアプリケーション | M2MはMachine-to-Machineの略。機器間(=エンドユーザーが介在しない)の通信に利用する。JWT Claimのsub(主体)は通常エンドユーザーだが、OAuth 2.0のクライアントクレデンシャルフローにおいてはApplicationがsubになる。 |
| API | エーピーアイ | OAuth 2.0で定義されるリソースサーバーとしての役割も持つ。リソースサーバーはエンドユーザーの情報を持ち、アプリケーションに対してそれを提供する。ユーザーはアプリケーションに対してリソースサーバーの持つ自身の情報へのアクセス権(スコープ)を与える。 |
| Permission | パーミッション | APIが提供するデータのアクセス権を細分化したもの。OIDC/OAuth 2.0のスコープとしても利用される。APIごとに任意のパーミッションを定義できる。 |
| Role | ロール | ユーザーの役割。複数のパーミッションをユーザーの役割の単位で束ねたもの。アプリケーションごとにユーザーの役割は異なるのが一般的だが、Auth0ではアプリケーションを横断する形でロールが定義される。そのため複数の異なるアプリケーションを一つのテナントで管理する場合にはロールの持ち方に工夫が必要。 |
| Organization | オーガニゼーション | B2Bアプリケーションを作る際、Organizationを用意することでエンドユーザーの組織に応じてログイン時の認証方式を変えるといったことができる。 |
| Organization member | オーガニゼーションメンバー | 組織に所属するユーザー。1人のユーザーが複数の組織に所属することができる。その場合にはログイン時に組織選択画面を出せる。 組織メンバーに対してもそれぞれロールを付与することができる。 |
| JSON Web Token (JWT) | ジョット | トークンの表現方法として広く用いられている。 |
| JWT Claims | ジョットクレーム | 属性と同義。以下はJWTに含まれる属性の一部: – sub: Subject(主語, 主体) – aud: Audience(宛先) – azp: Authorized party(アプリケーション, クライアント) – scope: 許可されたスコープ, パーミッション – org_id: Auth0独自属性。組織ID |
| Access Token | アクセストークン | OAuth 2.0において、アプリケーションがAPIにアクセスするために使用する。 トークンの表現方法にはハンドルとアサーションがあり、ハンドルは実態を参照するポインタで、実態であるユーザー情報にアクセスするために認可サーバーに都度問い合わせを行う必要がある。Opaqueトークンとも呼ばれる。一方アサーションはそれ自体に実態を内包しているもので、その実装としてJWTが一般的に用いられる。 |
| ID Token | アイディートークン | OIDCにおいて、エンドユーザーの認証に関するクレームを含んだトークン。JWTで表現される。 アクセストークンのオーディエンスはAPIだが、IDトークンのオーディエンスはアプリケーションであるように、IDトークンはアプリケーションに対してユーザーの認証に必要な情報を提供する目的で発行される。 |
参考
- Auth0 Identity Glossary https://auth0.com/docs/glossary
- OAuth 2.0 Authorization Framework https://openid-foundation-japan.github.io/rfc6749.ja.html
- OAuth 2.0 Threat Model and Security Considerations https://openid-foundation-japan.github.io/rfc6819.ja.html
- OpenID Connect Core 1.0 https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html
Author: Yuki Sanada – Technical lead
おわりに
TC3では『デジタル顧客接点トータルサービス』として、Okta Customer Identity Cloud（旧Auth）の導入からアプリケーション開発までをトータルでご支援しております。トライアルの段階から、どのようにIDaaS/CIAMを導入するかについてもサポートさせていただきますので、お気軽にお問い合わせください。
●資料ダウンロード●
デジタル顧客接点トータルサービスに関する詳細のご紹介資料は以下からダウンロードいただけます！
