ユーザーを認可して標準クレームを要求する
この例では、ユーザーを認証し、ユーザーインターフェイスをパーソナライズできるようにユーザー詳細を取得したいとします。このためには、ユーザー名、ニックネーム、プロフィール画像、およびメール情報を含んだIDトークンが必要です。-
ユーザーに認証URLを送信して、認可フローを開始します。
この例では、以下の点に注意してください。
-
response_type
パラメーターには1つの値が含まれます。code
:標準のWebアプリケーションを使用しているため、最初に認証コードに対する要求が行われます。このコードを使ってトークンを要求すると、認証に必要なIDトークンが送られてきます。
-
scope
パラメーターには、3つの値(要求されたOIDCスコープ)が含まれます。openid
:アプリケーションがユーザーの身元検証にOIDCを使用することを伝えるためprofile
:name
、nickname
、およびpicture
を取得するためemail
:email
とemail_verified
を取得するため
-
- ユーザーが同意し(必要な場合)、Auth0がアプリにリダイレクトした後、トークンを要求します。
-
応答からIDトークンを抽出し、解読します。次のクレームが表示されます。
アプリはユーザー属性を取得し、この属性を使ってUIをパーソナライズできるようになります。
カスタムAPIへのアクセスを要求する
以下の例では、呼び出す側のアプリケーションがユーザーの予定を読み取れるようにするカレンダーAPIのカスタムスコープを要求します。このため、APIから予定を読み取るための適切なスコープを含んだアクセストークンを取得します。アクセストークンの要求は、IDトークンの要求に依存することはありません。 カスタムAPIを使用する前に、呼び出すAPIで使用できるスコープを知っておく必要があります。カスタムAPIを管理できる場合、Auth0を使ってアプリケーションとAPIの両方を登録し、Auth0 DashboardでAPIのスコープを定義する必要があります。定義された権限を使って、ユーザーの同意プロンプトをカスタマイズすることもできます。-
ユーザーに認証URLを送信して、認可フローを開始します。
この例では、以下の点に注意してください。
-
response_type
パラメーターには1つの値が含まれたままです。code
:標準のWebアプリケーションを使用しているため、最初に認証コードに対する要求が行われます。このコードを使ってトークンを要求すると、APIの呼び出しに使用できるアクセストークンが送られてきます。
-
scope
パラメーターには、1つの値(要求されたAPIスコープ)が含まれます。read:appointments
:APIからユーザーの予定を読み取れるようにするため
-
audience
パラメーターは新しいパラメーターで、1つの値が含まれます。- APIの一意識別子で、ここからユーザーの予定を読み取ります。
-
- 前の例にあるように、ユーザーが同意し(必要な場合)、Auth0がアプリにリダイレクトした後、トークンを要求します。
- 応答からアクセストークンを抽出し、アクセストークンを資格情報に使ってAPIを呼び出します。
ユーザーを認可し、標準クレームとカスタムAPIアクセスを要求します。
この例では、前の2つの例を組み合わせて、ユーザーの認可と標準クレームの要求を行うほか、呼び出す側のアプリケーションがユーザーの予定を読み取れるようにするカレンダーAPIのカスタムスコープも要求します。このために、2つのトークンを取得します。-
IDトークンに含まれるもの:
- ユーザー名
- Nickname(ニックネーム)
- プロファイル画像
- メール情報
- 適切なスコープを含むトークンにアクセスし、APIから予定を読み取ります。アクセストークンの要求は、IDトークンの要求に依存することはありません。
-
ユーザーに認証URLを送信して、認可フローを開始します。
この例では、以下の点に注意してください。
-
response_type
パラメーターには1つの値が含まれたままです。code
:標準のWebアプリケーションを使用しているため、最初に認証コードに対する要求が行われます。このコードを使ってトークンを要求すると、認証に必要なIDトークンとAPIの呼び出しに使用できるアクセストークンの両方が送られてきます。
-
scope
パラメーターはOIDCスコープとAPIスコープの両方に使用されるため、4つの値が含まれるようになりました。openid
:アプリケーションがユーザーの身元検証にOIDCを使用することを伝えるためprofile
:name
、nickname
、およびpicture
を取得するためemail
:email
とemail_verified
を取得するためread:appointments
:APIからユーザーの予定を読み取れるようにするため
-
audience
パラメーターには1つの値が含まれます。- APIの一意識別子で、ここからユーザーの予定を読み取ります。
-
- 前の例にあるように、ユーザーが同意し(必要な場合)、Auth0がアプリにリダイレクトした後、トークンを要求します。
- 応答からIDトークンを抽出、解読し、ユーザー属性を取得し、その属性を使ってUIをパーソナライズします。
- 応答からアクセストークンを抽出し、アクセストークンを資格情報に使ってAPIを呼び出します。
カスタムクレームをトークンに追加する
以下の例では、ユーザーのお気に入りの色と使用する連絡先方法をIDトークンに追加します。このためには、これらのクレームを追加することで、アクションを作成し、IDトークンをカスタマイズします。追加すると、/userinfo
エンドポイントを呼び出すときに、カスタムクレームを取得することもできます(ただし、Actionは認可プロセス中のみ実行されます)。
Auth0では、名前空間を指定したクレームと名前空間を指定しないクレームが使用できますが、特定の制限があります(「一般的な制限」を参照してください)。名前の衝突を避けるために、名前空間を指定したクレームの使用をお勧めします。衝突が生じた場合、トランザクションは失敗しませんが、カスタムクレームがトークンに追加されません。
- ユーザーが
preferred_contact
メソッドにemail
、favorite_color
にred
をぞれぞれ選択し、ユーザーのuser_metadata
の一部として保存しました。 - Management APIまたはDashboardを使用して、このユーザーのアプリケーション固有情報を設定しました。
sub
クレームには、user_id
プロパティの値が含まれます。favorite_color
プロパティもuser_metadata
プロパティも存在しません。これは、 Connect (OIDC)がfavorite_color
またはuser_metadata
を表す標準クレームを定義しないためです。
- [Auth0 Dashboard]>[Actions(アクション)]>[Library(ライブラリ)]に移動し、[Build Custom(カスタムビルド)] を選択します。
-
アクションにわかりやすい 名前 を入力し(たとえば、「
ユーザーメタデータをトークンに追加する
」)、[Login / Post Login(ログイン/ログイン後)]
トリガーを選択し(アクションをログインフローに追加することになるため)、 [Create(作成)] を選択します。 -
Actions Code Editor(アクションコードエディター)を検索し、以下のJavaScriptコードをコピーし、 [Save Draft(下書きを保存)] を選択して内容を保存します。
- [Actions Code Editor(アクションコードエディター)]サイドバーから、[Test(テスト)](再生アイコン)、 [Run(実行)] の順にクリックし、コードをテストします。
- アクションを稼働する準備ができたら、 [Deploy(導入)] を選択します。
favorite_color
およびpreferred_contact
のカスタムクレームが含まれます。
api.idToken.setCustomClaims
メソッドを使用するIDトークンに追加されています。これらのクレームをアクセストークンに追加するには、api.accessToken.setCustomClaim
メソッドを使用します。
トリガーのイベントオブジェクトの詳細については、「Actionトリガー:post-login - eventオブジェクト」をお読みください。トークンの詳細については、「トークン」をお読みください。