INNOVATED.当サイトは、ブラウザのJavaScript設定を有効にしてご覧ください。2.0とOIDCの理解は、ウェブアプリケーションのセキュリティを確保するために重要です。この記事では、これらのプロトコルがAuth0上どのように機能し相互に関連しているのかを解説します。アプリケーション開発者が認証基盤への理解をより深める一助となることを目的としています。参考ソリューションサービスのご紹介データモデル以下の図はAuth0の主要機能から抽出したデータモデルです。Auth0が公式で公開しているものではありません。用語の解説データモデル中の用語について解説します。ような単位でテナントを分けることが多い。2.0で定義されているユーザの身元を確認または拒否するサーバー。Provider(OP)は通常これを指す。Auth0テナントにつき1つ提供される。Auth0ではこの単位で複数のユーザーが境界付けされる。デフォルトではAuth0の内部データベースが一つ用意されている。それ以外には、例えばGoogle(ソーシャル)ログイン、パスワードレスログインといった認証方法の単位でコネクションを新しく作ることができる。ユーザーはコネクションに紐づく。そのため、エンドユーザーが複数の認証方法でログインした場合、別々のユーザーとして認識される。認証方法が異なるだけの同じエンドユーザーをまとめたい場合、親となるユーザーを指定してそのユーザーに複数のユーザーを紐付けることができる。紐付けのロジックはActionsにて任意のスクリプトを定義する。2.0で定義されるクライアントを表す。Auth0ではユーザーは必ずアプリケーションを一つだけ選択してログインする必要がある。party)を登録することも可能。この区別は各機能を横断する形でセキュリティレベルに影響を与える。partyであれば、スコープ同意画面をスキップすることができる。M2MはMachine-to-Machineの略。機器間(=エンドユーザーが介在しない)の通信に利用する。2.0のクライアントクレデンシャルフローにおいてはApplicationがsubになる。2.0で定義されるリソースサーバーとしての役割も持つ。リソースサーバーはエンドユーザーの情報を持ち、アプリケーションに対してそれを提供する。ユーザーはアプリケーションに対してリソースサーバーの持つ自身の情報へのアクセス権(スコープ)を与える。APIが提供するデータのアクセス権を細分化したもの。2.0のスコープとしても利用される。APIごとに任意のパーミッションを定義できる。複数のパーミッションをユーザーの役割の単位で束ねたもの。アプリケーションごとにユーザーの役割は異なるのが一般的だが、Auth0ではアプリケーションを横断する形でロールが定義される。そのため複数の異なるアプリケーションを一つのテナントで管理する場合にはロールの持ち方に工夫が必要。B2Bアプリケーションを作る際、Organizationを用意することでエンドユーザーの組織に応じてログイン時の認証方式を変えるといったことができる。組織に所属するユーザー。1人のユーザーが複数の組織に所属することができる。その場合にはログイン時に組織選択画面を出せる。組織メンバーに対してもそれぞれロールを付与することができる。トークンの表現方法として広く用いられている。