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トークンはアプリケーションに対してユーザーの認証に必要な情報を提供する目的で発行される。

参考

  1. Auth0 Identity Glossary https://auth0.com/docs/glossary
  2. OAuth 2.0 Authorization Framework https://openid-foundation-japan.github.io/rfc6749.ja.html
  3. OAuth 2.0 Threat Model and Security Considerations https://openid-foundation-japan.github.io/rfc6819.ja.html
  4. 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 CIC(Customer Identity Cloud)を代表とするIDaaSを活用したデジタルサービス開発のプロフェッショナルです(Customer Identity Cloudの認定も取得しています)。

すでに実践的に設計・実装された基盤サービスとして2024年5月末に、「Tactna Identity Platform」を発表しました!このサービスを活用いただくことで、事業部やサービス間の調整を減らし、リリースまでの期間を早め、ユーザー体験を向上させるといったメリットの多い開発プランをご提供します。

サービス紹介サイト

トライアル・MVP開発の段階から、どのようにIDaaS/CIAMを導入するかについてもサポートさせていただきますので、お気軽にお問い合わせください。

Tactna Identity Platformに関する詳細のご紹介資料は以下からダウンロードいただけます!

ひとまず情報のキャッチアップだけしておきたいという方は、こちらからニュースレターの購読ができます。