この記事では、IDトークンから属性/クレームが欠落している場合がある理由と、そのような場合にすべてのユーザークレームやOktaグループを取得する方法について説明します。

この記事では、次のことを想定しています。

• ユーザー属性
  • Org Authorization Server：［Application User Profile（アプリケーションユーザープロファイル）］にこの属性が存在し、入力されている（nullではない）。これはProfile Editorの［マッピング］で、または［プロビジョニング］ページを開くことで確認できます。
  • カスタム認可サーバー：［Oktaユーザープロファイル］にこの属性が存在し、入力されている（nullではない）。これは［ユーザー属性］ページから確認できます。
  • これらのオプションのいずれかに関する詳細については、「Oktaユーザープロファイルとアプリケーションユーザープロファイル」の記事をご覧ください。

• Implicitフロー
• Authorization codeフロー
• リソース所有者のパスワードフロー（grant_type = password）

アクセストークンと一緒に返されたIDトークンは、ThinトークンまたはThin IDトークンとみなされます。Thin IDトークンは、基本クレームといくつかのスコープ依存クレームのみを持っています。たとえば、「profile」スコープがリクエストされ、Thinトークンが返された場合、IDトークンのペイロードには「preferred_username」クレームと「name」クレームが含まれますが、「given_name」や「family_name」など、「profile」スコープ依存のほかのクレームは含まれません。

IDトークンとアクセストークンが一緒に返される例として、たとえば次のような場合があります。

• Implicitフロー（response_type=id_token+tokenの場合）
• Authorization codeフロー（「openid」スコープが認可リクエストで渡される場合）
• リソース所有者のパスワードフロー（「openid」スコープがトークンリクエストで渡される場合）

注：Implicitフロー（response_type=id_token）でIDトークンのみが（たとえばアクセストークンなしで）返される場合、返されるIDトークンはFatトークンとみなされ、profileスコープが渡される場合にはすべてのプロファイル属性、groupsスコープが渡される場合にはすべてのグループが含まれます。 

この挙動は、スコープ依存のクレームに関するOpenIDの仕様に基づいています。セクション5.4からの次の引用をご覧ください：

• 「処理の結果としてアクセストークンが発行されるresponse_typeを使用したとき、profile、email、address、およびphone scope値により要求されるクレームは、セクション5.3.2にある通りUserInfo Endpointから返される。しかし、（response_type値がid_tokenであるケースのように）アクセストークンが発行されない場合、結果クレームはIDトークン内で返却される。」

これらのフローでは、アクセストークンはIDトークンと一緒に返されます。このアクセストークンは、ユーザークレーム（適切なスコープが渡されている場合はすべてのプロファイル属性/クレーム）を取得するために使用できます。

アクセストークンは、Userinfoリクエストの認可ヘッダーでベアラートークンとして送信することができます（つまり、基本URLがhttps://OktaDomain.okta.comまたはカスタムドメインの場合はPOST ${baseUrl}/oauth2/v1/userinfo）。

関連資料

• Implicitフロー
• Authorization codeフロー
• リソース所有者のパスワードフロー（grant_type = password）