シングルIDプロバイダー：認可

認可では通常、誰に何が許可されるのかをどのようにして決定するのか、そして、この許可に関する情報をどのようにしてアプリケーションやAPIに伝えるのかを考える必要があります。使用しているアプリケーションによっては、それらの片方または両方の影響を受けることがあります。当社のアーキテクチャシナリオでは、B2B認可に関する一般的なガイダンスを提供しています。こちらのガイダンスと併せて確認することをお勧めします。

  • IDトークンは一般的に、カスタムクレームを使って、ユーザーの認可情報をアプリケーションへ伝えるために使用されます。このカスタムクレームはルール拡張を使って追加することができます。追加されたクレームは、ユーザーの許可されていない操作を阻止するユーザーインターフェイスを表示できるようにします。また、IDトークンの認可情報は、ユーザーが従来型のWebアプリでフロントエンドの制御を迂回できないようにする方法をアプリケーションのバックエンドに提供します。

  • 共有リソースサービスへの公開アクセスを提供するAPIは通常、アクセス制御メカニズムによって保護されます。このため、Auth0には認可ベアラートークンまたはOAuth 2アクセストークンを作成する機能が備わっており、これでユーザー認可情報をAPIに伝えることができます。通常は、Auth0のRole-Based Access Control (RBAC)を使用して1つ以上のメンバーシップが割り当てられたロールを適用するか、ルール拡張を介してカスタムクレームを追加することで実行されます。Auth0のRBAC機能を活用して、アクセストークンのスコープクレームを自動的に調整することもできます。APIはこの情報を使って適切なレベルのアクセス制御を適用し、ユーザーについての情報を追加で検索することなく、ポリシールールを適用できるようにします。

  • Auth0テナントでアプリケーションレベルのポリシーを実装したい場合には、広範囲のアプリケーションやリソースサービス（API）にポリシーを適用できるようになります。個別に変更する必要はありません。これを実装するには通常、ルール拡張を使用します。

IDトークンのクレーム

通常、クレームはIDトークンクレームのベストプラクティスガイドに説明されるように、IDトークンに追加することができます。Auth0組織機能を使用する場合、org_idクレームは組織メンバーシップを持つユーザーに発行された任意のIDトークン（例については、「トークンと組織を使用する」を参照）に自動的に追加されます。このパラメーターはAuth0 SDKが検証します。また、IDトークンにカスタムクレームを追加して、Auth0の組織に関連付けられた補足情報を追加することもできます。

context.idToken['http://travel0.net/multifactor'] = context.multifactor;

Was this helpful?

/

注意:Authentication APIで組織名が使用できるようにテナントを構成した場合には、org_nameクレームがIDトークンに自動的に含まれます。詳細については、「Authentication APIでOrganization名を使用する 」を参照してください。

SAMLアサーション

Auth0 Organizations（組織）機能は 、SAML対応のアプリケーションには対応していませんが、アップストリームのIDプロバイダー（IdP）が生成したSAMLアサーションを構成して、ダウンストリームで使用されるIDトークンに標準やカスタムのクレームを追加することはできます。たとえば、以下のように、SAMLエンタープライズ接続にあるマッピングセクションを定義することができます。

{ 
  "user_id": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ],
  "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
  "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
  "given_name": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ], 
  "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
  "groups": "http://schemas.xmlsoap.org/claims/Group"
}

Was this helpful?

/

この例では、各フィールドにルールのuserオブジェクト内の値が割り当てられ、IDトークンの標準クレームにマッピングするか、カスタムクレームを使ってマッピングされます。SAMLマッピングをカスタマイズする方法の詳細については、「アプリをSAML IDプロバイダーに接続する：マッピングをセットアップする」を参照してください。

アクセストークンのクレーム

アクセス制御を決定する上でアクセストークンに追加するその他のクレームに加えて（アクセストークンのクレームのベストプラクティスに関する一般的なガイダンスを参照）、通常は、ユーザーが属する組織にも伝えるようにしましょう。

IDトークンと同様に、Auth0組織機能を使用する場合、org_idクレームは組織メンバーシップを持つユーザーに発行された任意のアクセストークン（例については、「トークンと組織を使用する」を参照）に自動的に追加されます。また、アクセストークンにカスタムクレームを追加して、Auth0の組織に関連付けられた補足情報を追加することもできます。

context.accessToken['http://travel0.net/multifactor'] = context.multifactor;

Was this helpful?

/

注意:Authentication APIで組織名が使用できるようにテナントを構成した場合には、org_nameクレームがアクセストークンに自動的に含まれます。詳細については、「Authentication APIでOrganization名を使用する 」を参照してください。

または、各組織に一意のAPIオーディエンスを作成することもできます。そうすると、APIの定義がAuth0で一意のものになります。この方法では、カスタムのルール拡張を取り入れる必要がなくなりますが、複雑性が伴うため、困難になるかもしれません。以下の表は簡単な比較をまとめたものです。

手法 長所 短所
一意のAPIオーディエンス
  • 1つの組織におけるM2Mアクセスの対応がそのままで便利に使用できる。
  • オーディエンスはアクセストークン内の標準クレーム
  • リフレッシュトークンの処理が組織のロジックを追加で必要としない
  • 各組織にAPIを自動作成する必要がある
  • RBACの使用では、独立したロールを作成する必要があるかもしれない
    • メンバーシップにロールを自動でプロビジョニングしなければならない
  • APIの実装が複数のオーディエンスを処理しなければならない
カスタムクレーム Auth0テナントの構成を簡素化する トークンにアクセスする組織を追加するには、ルール内にカスタムコードがなければならない

Roles（ロール）

Auth0組織機能は、Auth0テナントに関連する認可コア機能を使用して、Role-Based Access Control (RBAC)もサポートします。RBACは、Auth0組織のメンバーシップレベルで適用されます。

アクセス制御

リソースレベルのポリシーを適用することは、システムにあるアプリケーションとAPIの責任です。Auth0テナントなど、中央集中型の認可サーバーでポリシーの適用を管理しようとすると、制御システムが複雑になり、維持と理解が難しいという問題に直面することになります。そこで代わりに、ユーザーについての適切な情報がトークンに確実に含まれていことを中央集中型の認可サーバーが管理して、アプリケーションやAPIがポリシーの適用を決めるのに必要な情報を持っているようにします。少なくとも、1つのトークンに含めるには情報が多すぎる（リソースレベルの許可など）か、情報が頻繁に変わるため、直接アクセスしたトークンの情報が古くなっている場合には、アプリケーションやAPIが正しい情報を検索する必要があります。

一方で、大体のポリシーは中央管理で適用することができます。たとえば、Auth0テナントの場合、すべてのアプリケーションやAPIに同じ制約を適用しなくてもいいように、ルールを実装できるような状況もあります。それらの状況には以下が挙げられます。

  • 特定のIPアドレスからのユーザーアクセスを阻止する

  • Contextual MFAやAdaptive MFAに固有の要件を実装する

  • メールアドレスが確認されたユーザーのみにログインを制限する

  • 特定のAPIオーディエンスへのアクセスを制限する。これによって、ユーザーがアクセストークンを取得できるAPIオーディエンスが限られるか、ユーザーがオーディエンスからアクセストークンを取得できる状況が制限される。このとき、各組織にカスタムAPIオーディエンスを作成している場合には、認証しているユーザーの組織がAPIオーディエンスの組織と一致していることを、ルールで保証しなくてはなりません。