利用可能性はAuth0プランによって異なる
この機能が利用できるかどうかは、ご利用のAuth0プラン(または契約)によります。詳細については、「価格設定」をお読みください。
拡張性
組織は拡張ポイントに対応しているため、組織メタデータにプロパティーを定義して、そのデータをActionsに反映することができます。これにより、各顧客またはアプリケーションのために機能をカスタマイズできます。たとえば、組織のメタデータに特定の顧客のサブスクリプションプラン情報を保管しておくと、カスタムロジックをActionsで実行することができます。アクションのイベントオブジェクト
アクションのイベントオブジェクトには、ユーザーのIPアドレスやアプリケーション、位置情報など、実行中の認証トランザクションに関するコンテキスト情報が保管されます。 アクション内でイベント
オブジェクトを使用してトークンの内容を変更すると、すべてのルールの実行が終わった後でトークンに反映されます。
SDK
メンバーが自分の組織を独自に管理できるように、メンバーにロールを割り当てて、APIやSDKを用いてプロダクトにダッシュボードを作成することができます。管理者はシングルサインオン()を構成したり、ユーザーを組織に招待したり、メンバーを組織に割り当てたり、メンバーに役割を割り当てたりできます。 SDKを利用して組織に実行すると良いタスクには、以下のような例があります。以下の例で言及している
org_id
クレームは、IDトークンとアクセストークンにデフォルトで含まれています。ただし、テナントは、Authentication APIで組織名を使用できるように構成することも可能です。そうすると、トークンにorg_id
クレームとorg_name
クレームの両方が含まれることになります。その場合は、org_id
クレームに加えてorg_name
クレームも検証し、受け取った値が信頼できるエンティティと一致することを確認します。一般に、トークンの検証には組織IDを使用することが推奨されます。ただし、組織名の方が適している状況では、組織名を使用してかまいません。トークンの検証に組織名を使用をした場合の影響については、「Authentication APIで組織名を使用する」をお読みください。ユーザーのログイン先に特定の組織を指定したい
新しいクライアントを定義する際に、組織IDを組織パラメーターに渡します。次にコールバック時に、IDトークンで返された組織が/authorize
要求で送信された組織と同じであることを確認します。そのためには、org_id
クレームをexp
やnonce
などの他のクレームが検証されたのと同じ方法で検証します。
詳細については、以下をお読みください。
- 認可コードフローを使用してログインを追加する
- 認可コードフローを使用してAPIを呼び出す
- PKCEを使った認可コードフローでログインを追加する
- PKCEを使った認可コードフローでAPIを呼び出す
- フォームPOSTを使った暗黙フローでログインを追加する
- ハイブリッドフローを使用してAPIを呼び出す
- 組織に基づいてセッションの非アクティブタイムアウトをカスタマイズする
独自のアプリケーションを使用して、認証ユーザーのログイン先組織を取得したい
ユーザーが組織を使用して認証された場合には、組織IDがIDトークンのorg_id
クレームに表示されます。Auth0 SPA SDKを使用すると、これは次のようにして取得することができます:
const { org_id } = await client.getIdTokenClaims();
独自のAPIを使用して、アクセストークンが発行された組織を取得したい
ユーザーが組織を使用して認証され、オーディエンスが指定された場合、アクセストークンはになり、ユーザーがログインした組織IDを持つorg_id
クレームが含まれます。
これは、他のクレームと併せてバックエンドで検証されます。以下はRubyでの例です。
Auth0ドメインを見つけるテナント名がAuth0ドメインである場合は、地域のサブドメイン(テナントが米国地域にあり、2020年6月より前に作成された場合を除く)の後に「
.auth0.com
」が続きます。たとえば、テナント名が「travel0
」の場合、Auth0のドメイン名は「travel0.us.auth0.com
」になります。(テナントが米国内にあって、2020年6月よりも前に作成された場合、ドメイン名は「https://travel0.auth0.com
」になります。)カスタムドメインを使用している場合には、これがカスタムドメイン名になります。