この記事は、多くのナレッジベース記事で見られる「これをやる、あれをやる」という単純な説明を少し超えた内容になります。代わりに、6clicks がユーザーと 6clicks 内のロールをマッチングするために使用するカスタムスコープについて説明しようとしています。
SSO 設定内のチェックボックス「認証リクエストに「groups」スコープを含めて認可してください。」の使用方法と、そのチェックが必要な場合について説明します。
注意: Okta Org Server を使用している場合、つまり提供された Issuer URI が https://{yourOktaDomain} となっている場合は、チェックボックスにチェックを入れ、常に ‘groups’ スコープを送信する必要があります。
OpenID Connect (OIDC) は、OAuth 2.0 の上に構築された認証プロトコルで、クライアントがアイデンティティプロバイダー (IdP) による認証に基づいてユーザーの身元を検証できるようにします。一般的な IdP には Okta、Azure AD (Entra ID)、Ping、One Login、ForgeRock などがあり、その他にも AWS、Google、SAP など多くのプロバイダーが存在します。
OIDC では、「スコープ」とは認証済みユーザーに関する特定の情報（「クレーム」と呼ばれる）をリクエストするための仕組みです。一般的な OpenID Connect スコープのいくつかの例を以下に示します。6clicks はそれぞれのスコープを使用しています：
-
openid: これは必須のスコープで、クライアントが OpenID Connect を使用していることを示すために、すべての OIDC リクエストに含めなければなりません。結果として返される ID トークンには、ユーザーに関する基本的なアイデンティティクレームが含まれます。
-
profile: このスコープは、名前、優先ユーザー名、名と姓、プロフィール写真など、ユーザーのデフォルトのプロフィールクレームへのアクセスを要求します。
-
email: このスコープは、ユーザーのメールアドレスへのアクセスを要求します。
これらの標準の OIDC スコープに加えて、アプリケーション固有の追加クレームをリクエストするために、カスタムスコープを定義することが可能です。6clicks には ‘6clicksRoles’ というカスタムクレームがあり、変数として ‘6clicks-roles-<rolename>’ の値を必要とします。各ユーザーは複数のロール値を持つことができ、これらは 6clicks 内で設定されたロールと一致します。
6clicks 内のロールの例。
残念ながら、一貫性の観点から見ると、各 IdP はカスタムスコープとクレームの実装方法において若干異なる方法を取っています。例えば：
-
Okta の Org Authorization Server は、すべてのカスタムクレームを ‘groups’ スコープに追加します。つまり、ID トークンに 6clicksRoles クレームを含むグループスコープが含まれるように、「Include "groups" scope in Authentication Request to Authorization」のチェックボックスを選択する必要があります。
-
Okta の Custom Authorization Server では、既存のスコープにカスタムクレームを追加することが可能です。これは本KB記事で示した方法です。しかし、カスタムスコープ ‘groups’ を作成し、このスコープにカスタムクレーム 6clicksRoles を付与することも可能です。この方法を選択した場合、「Include "groups" scope in Authentication Request to Authorization」のチェックボックスにチェックを入れて ‘groups’ スコープを含める必要があります。
要するに、各ユーザーの ID トークンに対応する値を持つカスタムクレーム 6clicksRoles をどのようにして取り込むかは重要ではなく、存在している限り問題はありません。