OpenID のConnect for Open Bankingアプリケーションにおけるシングルサインオンの設定

オンラインで編集

OpenID Connect for Open Banking を使用して、IBM® Verifyによって実行される認証に基づいてアプリケーションがユーザーの ID を検証できるようにします。ユーザーは、アプリケーションでアカウントを登録する必要はありません。ユーザーはログインのためにに Verify リダイレクトされます。 Verifyは、ユーザーの ID を検査し、ID トークンを介して情報を送信し、ユーザーがリソースへのアクセスと使用を許可されていることを依拠当事者に確認します。このアプリケーションでは、新しい OpenID Connectプロバイダーを使用しており、その検出エンドポイントは https://<tenant-host>/oauth2/.well-known/openid-configuration. です。

始める前に

このタスクを完了するには管理者権限が必要です。
少なくとも 2 つのブラウザー・ウィンドウを開いて、セットアップを完了します。 1つは管理コンソール Verify 用、もう1つは対象アプリケーションの管理コンソール用です。
- Verify 管理コンソールにログインしてください。
- 管理者アカウントでターゲット・アプリケーション管理コンソールにログインします。
一般タブで、アプリケーション・インスタンスの基本情報をセットアップする必要があります。「アプリケーションの基本情報の設定」を参照してください。

このタスクについて

Verifyアプリケーションを追加する際は、「 OpenID Connect for Open Banking 」アプリケーションテンプレートを選択し、 OpenID Connectの依存先として機能するアプリケーション、またはユーザーの認証を委任するクライアントアプリケーションとして設定してください。

Verifyと依拠当事者が相互に対話するように構成します。 OpenID Connect シングル・サインオンを有効にするには、以下を指定する必要があります。

依拠当事者からの特定のデータを含むVerify。
Verifyからの特定のデータを持つ依拠当事者。

IBM Verify Accessおよびモバイル・アプリケーションを OpenID Connect リライング・パーティーとして構成できます。

手順

[サインオン] タブに移動します。

依拠当事者に関する基本情報を検証に提供します。

表 1. 依拠当事者の情報
フィールド	説明
アプリケーション URL	これは、 OpenID Connect の依存先へのログインに使用されるシングルサインオン初期化 URL です。アプリケーションは、この URL を使用して、ユーザーの詳細が含まれている ID トークンを Verify に要求します。ユーザーがこの URL を介してアプリケーションにアクセスすると、ユーザーは認証のために Verify にリダイレクトされます。この情報は、許可プロバイダーまたは OpenID Connect プロバイダーをそのサイトで構成するときに、依拠当事者から取得できます。
付与タイプ	Verifyこれは、依存先がIDトークンを取得するために利用できる仕組みを示しています。 OpenID Connect for Open Banking は、以下の付与タイプをサポートします。許可コード暗黙的クライアント資格情報許可コードと暗黙的 (ハイブリッド・フロー) トークン交換 JWT ベアラーデバイス・フローコンテキスト・ベースの許可少なくとも 1 つの付与タイプを選択する必要があります。「助成金の種類」を参照して、対象となる助成金の種類を簡単に比較し、申請にどの助成金の種類を設定すべきかを確認してください。
応答タイプ	応答タイプは、希望する認証処理フローを認証サーバーに通知します。注：レスポンスタイプが設定されていない既存のアプリケーションを編集する場合、有効化されているグラントタイプに対して適用可能なすべてのレスポンスタイプがデフォルトで設定されます。 OpenID Connectでは、以下の応答タイプに対応しています： `none` `code` `token` `id_token` `code token` `code id_token` `token id_token` `code token id_token` 応答タイプ`code`または`none`が選択されている場合、応答モード`query`が有効になります。それ以外の場合は、応答モード `query` がクリアされ、無効になります。
応答モード	応答モードは、Authorization Server が許可エンドポイントから結果パラメーターを返す方法を示します。 OpenID Connect for Open Banking は、以下の応答モードをサポートしています。照会断片フォーム POST JWTの照会 JWTフラグメント POSTリクエストによるJWT
クライアント ID	これは、 OpenID Connectの信頼先であるクライアントアプリケーションに割り当てられる一意の公開識別子です。許可サーバーはこの情報を使用して、依拠当事者と許可要求を識別します。この情報は、「 OpenID Connect 」アプリケーションを保存すると自動的に生成されます。アプリケーションの管理コンソールでVerifyを OpenID Connect プロバイダーとして構成する場合は、この情報を依拠当事者に提供する必要があります。依拠当事者は、アクセス・トークンを要求するたびにクライアント ID を使用します。
パブリック・クライアント (クライアント秘密鍵なし)	アプリケーションが提供する必要がある秘密鍵がクライアントにないことを示します。クライアント秘密鍵を生成するのは、クライアント・タイプが機密の場合のみです。機密クライアントは、クライアント ID とクライアント秘密鍵をセキュアな方法で保持でき、これらの資格情報を無許可の関係者に表示することはありません。クライアント・シークレットは、クライアント・アプリケーションと許可サーバーにのみ認識される必要があります。注：このオプションを選択すると、クライアントシークレットの入力欄は非表示になります。
クライアント秘密鍵	このデータは、依拠当事者を認証し、ID トークンの許可コードを交換するために、クライアント ID とともに使用されます。この情報は、「 OpenID Connect 」アプリケーションを保存すると自動的に生成されます。アプリケーションの管理コンソールでVerifyを OpenID Connect プロバイダーとして構成する場合は、この情報を依拠当事者に提供する必要があります。
リダイレクト URI	これはコールバック URL であり、Verifyがその認証応答を依拠当事者に送信するアドレスです。ユーザーは、Verify によって認証および許可された後、この URL にリダイレクトされます。少なくとも 1 つの URI を指定する必要があります。最大 400 個の URI を追加できます。この情報は、許可プロバイダーまたは OpenID Connect プロバイダーをそのサイトで構成するときに、依拠当事者から取得できます。
クライアント認証方式	Verify は、以下のクライアント認証方式をサポートしています。デフォルトクライアント秘密鍵 Basic クライアント秘密鍵 POST 秘密鍵 JWT 相互TLS デフォルトのままにした場合、クライアント秘密鍵 Basic と POST の両方が許可されます。このクライアントがパブリック・クライアントの場合、クライアント・シークレットの基本と POST は許可されません。依拠当事者がサポートしている場合は、構成として秘密鍵 JWT または相互 TLS を使用します。 Mutual TLS クライアント認証の詳細については、 OpenID を参照してください。Mutual TLS クライアント認証と証明書バインド型アクセストークンを連携させます。クライアントシークレットJWTおよび秘密鍵JWTの詳細については、「クライアントシークレットJWTの作成」および「秘密鍵JWTの作成」を参照してください。
クライアント・アサーション JTI の検証 (Validate client assertion JTI)	クライアント・アサーション JWT 内の JTI が単一使用に対して検証されるかどうかを示します。このオプションは、秘密鍵 JWT クライアント認証方式が選択されている場合にのみ表示されます。
クライアント・アサーション署名アルゴリズム	このオプションは、秘密鍵によるJWT クライアント認証方式が選択されている場合にのみ表示されます。
TLS クライアント認証属性	認証に使用される証明書属性です。このオプションは、相互 TLS クライアント認証方式が選択されている場合にのみ表示されます。サブジェクト DN SAN DNS SAN URI SAN IP SAN E メール・アドレス
TLS クライアント認証属性値	認証に使用される証明書内の属性の値です。このオプションは、相互 TLS クライアント認証方式が選択されている場合にのみ表示されます。
Proof Key for Code Exchange (PKCE) の検証が必要	PKCE は、許可コード傍受攻撃を軽減するために使用されます。これは、許可コード・フローの続行前に、コードのチャレンジを必要とします。このオプションが表示されるのは、許可コードの付与フローを選択したときのみです。
プッシュされた許可要求 (PAR) が必要	PAR により、クライアントは、許可要求のペイロードを直接要求を介して許可サーバーにプッシュし、許可エンドポイントへの後続の呼び出しでデータへの参照として使用される要求 URI を許可サーバーに提供することができます。
アクセストークンをSSOセッションと交換できるようにする	SSOセッション用のアクセストークンの交換。許可：アクセストークンをSSOセッションと交換できます。トークンの許可と失効：アクセストークンはSSOセッションと交換できますが、そのトークンは失効します。拒否：アクセストークンをSSOセッションと交換することはできません。デフォルト：OIDCアプリケーションの一般設定により、アクセストークンをSSOセッションと交換できるかどうかが決まります。

既存のアプリケーションを編集する場合は、次のクライアント秘密鍵オプションを使用できます。

クライアント秘密鍵を表示するには、を選択します。
クライアント秘密鍵を非表示にするには、を選択します。
を選択すると、クライアントIDまたはシークレットがクリップボードにコピーされます。
[選択] をクリックして、回転されたクライアントシークレットを表示します。
- リストから1つ以上のローテーション済みのクライアントシークレットを選択し、「削除」をクリックして削除してください。
新規クライアント・シークレットを生成するには、を選択します。クライアント秘密鍵が漏えいしたと思われる場合は、このオプションを使用します。クライアント秘密鍵を再生成した場合は、アプリケーションのすべての OAuth クライアントにあるクライアント秘密鍵を更新する必要があります。
- 「現在のシークレットを保持する」のチェックボックスを選択すると、現在のクライアントシークレットがローテーション対象のクライアントシークレットのリストに追加されます。
- 「現在のシークレットを保持する」チェックボックスがオンになっている場合は、クライアントシークレットの説明と有効期限（ブラウザのローカル時間）を選択してください。有効期限が選択されていない場合、アプリケーション設定で設定されたテナントの「ローテーションされたシークレットの有効期間」が適用されます。
- 更新されたクライアントシークレットはハッシュ化されており、もはや平文で復元することはできませんが、指定された有効期限までは引き続き使用可能です。
- 確認後、クライアントシークレットは直ちに更新されます。新しいクライアントシークレットが画面に表示されます。

JWTの設定を行います。

表 2. JWTの設定
フィールド	説明
JWKS URI	依拠当事者が JSON Web Key Set (JWKS) 形式で公開鍵を公開する URI。この URI は、JWT 署名の検証または暗号化に使用されます。システムは、到達不能または応答しない JWKS URI を拒否できます。 JWKS のサイズが大きすぎる場合も、システムは JWKS URL を拒否できます。依拠当事者が JWKS URI を公開しない場合は、X509 証明書の形式で公開鍵をシステムに追加できます。「証明書の管理」を参照してください。パブリック証明書に関連付けられる「フレンドリー名」は、JWT の鍵 ID (kid) ヘッダーの値です。
許可された署名検証鍵 (Allowed signature verification keys)	クライアント・アサーション JWT の検証に使用できる署名検証鍵 ID。このオプションは、秘密鍵 JWT クライアント認証方式が選択されている場合にのみ表示されます。
JWTベアラーによるユーザー識別： JWTベアラーのグラントタイプでのみ利用可能です。	この構成は、当該 JWT ベアラー・トークンに関連付けられているユーザーを識別するための JWT ベアラー・サブジェクト (sub) の解釈をシステムに通知します。「the」は、`ID`所有格の「the（～の）」、定冠詞の「the`Username`」、または「the」そのもの`External ID`になる場合があります。
JWTベアラーのデフォルトのIDソース JWTベアラーグラントタイプでのみ利用可能です。	JWTにレルムが指定されていない場合、デフォルトでは、subで識別されるユーザーが所属するIDソースのレルムが使用されます。この`JWT bearer user identification` オプションが有効`User ID`になっている場合、この設定は適用されません。

Request オブジェクトの設定を行います。

表 3. オブジェクト設定の取得
フィールド	説明
請求オブジェクト・パラメーターのみ	すべての請求パラメーターを請求オブジェクトに取り組めなければなりません。
署名アルゴリズム	要求オブジェクトが署名されることを検査が予期するアルゴリズム。以下のハッシュ・アルゴリズムから選択して、署名を検証します。 RS256 RS384 RS512 PS256 PS384 PS512 ES256 ES384 ES512
有効期限請求が必要	リクエストオブジェクトに「expiry`'exp'` 」プロパティが含まれていることを必須とする。
有効期間 (秒)	要求オブジェクトが有効である最大時間 (秒単位)。これは、リクエストオブジェクト内の有効期限`'exp'` から「not-before`'nbf'` 」タイムスタンプを差し引くことで算出されます。
請求URI	要求オブジェクトが含まれているリソースのURL。許可要求時には、ここに登録された請求URIのみが許可されます。

アクセス・トークンおよびリフレッシュ・トークンが盗まれた場合の無許可アクセスの時間を制限するために、これらのトークンの有効期限を構成します。

アクセス・トークンは、保護リソースへのアクセスを許可するために使用されます。アクセス・トークンの有効期限が切れると、許可は取り消されます。

表4. トークンの設定
フィールド	説明
アクセス・トークン存続時間 (秒)	アクセス・トークンの有効期限が切れるまでの時間の長さを秒単位で設定します。アクセス・トークンの有効期限を設定して、クライアント・アプリケーションが暗号漏えいしたときに、盗まれたトークンを使用して攻撃者がリソースにアクセスできる時間を制限します。指定できるのは正の整数のみです。デフォルト値は `7200` 秒です。許可される最小値は `1` 秒で、最大値は `2147483647` 秒です。
アクセス・トークンの形式	アクセス・トークンのフォーマットを指定します。以下のオプションを使用できます。デフォルト JWT
対象者	トークンの受信者とするターゲットを指定します。これらの値は、JWT形式のトークンのクレームaud およびイントロスペクション・ペイロード内に、単一の文字列または文字列の配列として記載されています。
リフレッシュ・トークンの生成	クライアントアプリケーションが、 OpenID Connect IDプロバイダーの認証サーバーから新しいアクセストークンを取得するために、リフレッシュトークンを要求および使用できるかどうかを示します。前のアクセス・トークンが期限切れになった場合にのみ、新規アクセス・トークンを取得する必要があります「暗黙的」が選択した唯一の付与タイプである場合、このオプションは関係ありません。
リフレッシュ・トークン存続時間 (秒)	リフレッシュ・トークンの有効期限が切れるまでの時間の長さを秒単位で設定します。この設定は、ユーザーが再認証を必要とする頻度を決定します。リフレッシュトークンの有効期限を設定し、一定時間が経過した後に Verify ユーザーがシングルサインオン操作を再度実行するようにします。このオプションは、「リフレッシュ・トークンの生成」を有効にした場合にのみ表示されます。リフレッシュ・トークンは、保護リソースへのアクセスを継続するための新規アクセス・トークンを取得するために使用されます。指定できるのは正の整数のみです。デフォルト値は `604800` 秒です。許可される最小値は `1` 秒で、最大値は `2147483647` 秒です。

ID トークン・シグニチャーおよび暗号化オプションを指定します。依拠当事者は、署名を使用して、トークンに含まれているユーザー要求の保全性と認証性、およびトークンに署名した OpenID Connect ID プロバイダーを検証します。トークンは、リライング・パーティーのみが復号できるように暗号化することができます。

表5. 署名と暗号化のオプション
フィールド	説明
署名アルゴリズム	Verifyが ID トークンに署名するために使用するアルゴリズム。このアルゴリズムは、依拠当事者がVerifyに登録したアルゴリズムと一致している必要があります。以下のハッシュ・アルゴリズムから選択して、署名を検証します。 RS256 PS256 ES256 RS384 PS384 ES384 RS512 PS512 ES512 注: ES256 署名アルゴリズムが選択されている場合、証明書は P-256 を指定した ECDSA でなければなりません。 ES384 署名アルゴリズムが選択されている場合、証明書は P-384 を指定した ECDSA でなければなりません。 ES512 署名アルゴリズムが選択されている場合、証明書は P-521を指定した ECDSA でなければなりません。
署名証明書	このオプションは、RS、ES、または PS 署名アルゴリズムのいずれかを選択した場合にのみ表示されます。この証明書を使用して、シングル・サインオン時に ID トークンに署名します。セキュリティ > 証明書 > 個人証明書「デフォルトの選択」とは、で設定したデフォルトの個人証明書を指します。
暗号化アルゴリズム	コンテンツ暗号鍵 (CEK) の値を暗号化または決定するために使用される暗号アルゴリズム。以下のアルゴリズムがサポートされています。 RSA-OAEP RSA-OAEP-256
コンテンツ・アルゴリズム	暗号化テキストおよび認証タグを生成するために、プレーン・テキストで認証済み暗号化を実行するために使用されるコンテンツ暗号化アルゴリズム。以下のアルゴリズムがサポートされています。 A128GCM A192GCM A256GCM
暗号鍵	暗号化に使用する鍵の証明書ラベルまたは鍵 ID。

「所有権証明」の設定を行います。詳細については、「所有権の証明（ DPoP ）」をご覧ください。

表6. 所有権証明の設定
フィールド	説明
証明書にバインドされたアクセス・トークン	生成されたトークンが証明書にバインドされているかどうかを示します。証明書ベースのアクセストークンに関する詳細については、「OpenID Connectの相互 TLS クライアント認証と証明書ベースのアクセストークン」を参照してください。
DPoP バインド・アクセス・トークンの適用	トークンリクエストにおいて、 DPoP ヘッダーが必要かどうかを示します。
DPoP JWT の JTI を検証する	DPoP のJWTに含まれるJTIが、シングルユースとして検証済みであるかどうかを示します。
DPoP JWT の署名アルゴリズム	DPoP のJWTに対する期待される署名アルゴリズム。以下のアルゴリズムから選択してください： RS256 RS384 RS512 PS256 PS384 PS512 ES256 ES384 ES512

JWTで保護された認証応答モード（JARM）の設定オプションを指定します。信頼側は、この署名を使用して、JWTレスポンスに含まれるトークンの完全性と真正性を検証します。 JWTは暗号化することも可能であり、その場合、信頼先のみが復号できるようになります。

表7. JWTによる認証レスポンスモード
フィールド	説明
署名アルゴリズム	VerifyがJWTレスポンスの署名に使用するアルゴリズム。アルゴリズムは、信頼当事者がVerifyに登録したものと一致している必要があります。以下のハッシュアルゴリズムから選択してください： RS256 PS256 ES256 RS384 PS384 ES384 RS512 PS512 ES512 注: ES256 署名アルゴリズムが選択されている場合、証明書は P-256 を指定した ECDSA でなければなりません。 ES384 署名アルゴリズムが選択されている場合、証明書は P-384 を指定した ECDSA でなければなりません。 ES512 署名アルゴリズムが選択されている場合、証明書は P-521を指定した ECDSA でなければなりません。
署名証明書	このオプションは、RS、ES、または PS 署名アルゴリズムのいずれかを選択した場合にのみ表示されます。シングルサインオン時に、この証明書を使用してJWTレスポンスに署名してください。セキュリティ > 証明書 > 個人証明書「デフォルトの選択」とは、設定したデフォルトの個人証明書を指します。
暗号化アルゴリズム	コンテンツ暗号鍵 (CEK) の値を暗号化または決定するために使用される暗号アルゴリズム。以下のアルゴリズムがサポートされています： RSA-OAEP RSA-OAPE-256
コンテンツ・アルゴリズム	暗号化テキストおよび認証タグを生成するために、プレーン・テキストで認証済み暗号化を実行するために使用されるコンテンツ暗号化アルゴリズム。以下のアルゴリズムがサポートされています。 A128GCM A192GCM A256GCM
暗号鍵	暗号化に使用する鍵の証明書ラベルまたは鍵 ID。

トークン交換の設定を行います。

表8. トークン交換
フィールド	説明
サブジェクト・トークン	対象トークンのトークンタイプ。これは、トークンの発行を依頼されている当事者の身元を表すものです。
アクター・トークン	アクター・トークンのトークン型。これは、発行されたトークンのアクセス権が委譲される相手の身元を表す。
要求されたトークン	トークン交換の一環として生成をリクエストできるトークンの種類。トランザクショントークン：この使い捨てのセキュリティトークンには、特定のトランザクション、アクション、リソース、またはリクエストの詳細に関するコンテキスト情報が含まれており、その特定の操作に対してきめ細かな権限管理を実現します。トークンを選択すると、「トランザクションコンテキスト」タイルが表示され、そこからCELx式を使用してコンテキストを設定できます。詳細については、「トランザクショントークン」を参照してください。注：トランザクショントークンはリクエスト可能な機能です。 VDEV-186514: 「AIエージェントのセキュリティ確保」。この機能をご希望の場合は、 IBM の営業担当者、または IBM の担当者までご連絡いただき、本機能の有効化をご希望であることをお伝えください。権限をお持ちの場合は、機能番号を明記してサポートチケットを作成することも可能です。 IBM Verify 無料体験版をご利用のお客様は、サポートチケットを作成することはできません。
クライアント・グループ	OpenID Connectのクライアントグループ一覧。このクライアントによって生成されたトークンは、同一グループ内でのトークン交換において、対象トークンとして使用できます。このリストが空の場合、どのクライアントも、このクライアントから生成されたトークンをトークン交換のサブジェクト・トークンとして使用できます。
アクタートークンの入力を要求	トークン交換リクエストの一部として、アクター・トークンを必須とする。このアクションは、委任シナリオを適用し、なりすましシナリオを無効にします。
トランザクションのコンテキスト	「トランザクションコンテキスト」フィールドは、「要求されたトークン」が「トランザクショントークン」に設定されている場合にのみ表示されます。このフィールドは、他のトークンタイプには適用されません。詳細については、「トランザクショントークン」を参照してください。

デバイスのフロー設定を構成します。

表9. デバイスのフロー
フィールド	説明
デバイス・フローの QR コードを生成	ユーザーコードとともにQRコードが生成されるかどうかを示します。

各エンドポイントの要求と応答のマッピングを構成します。
1. 許可エンドポイントの要求と応答のマッピングを構成します。
  - 要求マッピングは、同意要求、許可コンテキスト、およびインテント ID に使用できます。これらの各パラメータに関する詳細については、「 OpenID ：同意リクエストのConnectリクエストマッピング」、「 OpenID ：承認コンテキストのConnectリクエストマッピング」、および「 OpenID ：Open BankingインテントIDのConnectリクエストマッピング」を参照してください。
  - 応答マッピングにより、パラメーターとヘッダーを応答に追加できます。 OpenID のリクエストとレスポンスのマッピングを参照してください。
2. トークン・エンドポイントの応答マッピングを構成します。
  - 応答マッピングにより、パラメーターとヘッダーを応答に追加できます。 OpenID のリクエストとレスポンスのマッピングを参照してください。
3. イントロスペクト・マッピングを構成して、イントロスペクト・エンドポイントから返される属性を追加および変更します。
  OpenID を参照してください。Connect のイントロスペクト、ID トークン、およびユーザー情報のマッピングについて説明しています。
4. ユーザー情報および ID トークン属性マッピングを構成して、userinfo エンドポイントおよび ID トークンから返される属性を追加および変更します。
  OpenID を参照してください。Connect のイントロスペクト、ID トークン、およびユーザー情報のマッピングについて説明しています。
ユーザーがアプリケーションにアクセスする方法を決定するIDプロバイダーとポリシーを選択してください。
1. このアプリケーションへのサインインに使用できるIDプロバイダーを選択してください。
  
  デフォルトの設定では、テナントに対して設定されているすべてのエンタープライズIDプロバイダーからのアクセスが許可されます。アプリケーションへのサインインに使用できるIDプロバイダーを制限するには、「サポートされている特定のIDプロバイダーを選択する」を選択してください。サインインを許可するIDプロバイダーのチェックボックスを選択してください。
2. ユーザーがアプリケーションにアクセスする方法を決定するポリシーを選択します。
  割り当てられているデフォルトのアクセスポリシーを引き続き使用できます。あるいは、チェックボックスのチェックを外し、[ ] をクリックして、あらかじめ定義されたアクセスポリシーのリストから選択することもできます。詳細については、「アクセスポリシー」を参照してください。アクセスポリシーを選択したら、各グラントタイプのチェックボックスをオンにして、そのアクセスポリシーを適用するように設定します。
ユーザーの同意を求めるかどうかを選択します。
ユーザー同意の要求を OpenID Connect アプリケーションに追加できます。デフォルトの同意を要求が選択されたままの場合、スコープおよびその他のトランザクション情報に明示的に同意するように求めるプロンプトがユーザーに出されます。同意を求めないが選択されている場合、同意は収集されませんが、許可要求は成功します。「未承認の同意のみを求める」が選択されている場合、ユーザーには、まだ同意が得られていない事項についてのみ、同意を求めるプロンプトが表示されます。
カスタム・スコープを制限します。
カスタム・スコープは、サポートされる OIDC/OAuth 付与フローで OIDC/OAuth クライアントによって要求できます。デフォルトの設定である「カスタム・スコープの制限」が有効になっている場合、フローの終わりにクライアントに付与されるスコープは、このセクションで指定されるスコープに制限されます。「カスタム・スコープの制限」が無効になっている場合、フローが完了すると、要求されるすべてのカスタム・スコープが付与されます。
注：標準スコープ openid, profile, email, phone, および address は制限できません。
1. 「カスタムスコープを制限する」チェックボックスがオンになっていることを確認してください。
2. 付与するカスタム・スコープの名前と説明を入力します。
  スコープ名は、依拠当事者/クライアントによって要求される OAuth2/OIDC スコープを指します。説明は、スコープの分かりやすい説明です。
  
  もう 1 組のスコープ・フィールドが表示されます。
3. 付与するカスタム・スコープごとに、前のステップを繰り返します。
認証の詳細を制限する
OIDC/ OAuth クライアントは、サポートされているOIDC/ OAuth グラントフローにおいて、認証の詳細情報を要求することができます。「承認詳細の制限」が有効になっている場合、フローの終了時に付与される承認詳細は、このセクションで指定された承認詳細に限定されます。「承認の詳細を制限する」が無効になっている場合、フローが完了すると、要求されたすべての承認の詳細が承認されます。
1. 「権限の制限」のチェックボックスがオンになっていることを確認してください。
2. 「不明な認証情報を無視する」が有効になっているか確認してください。
3. 付与したい承認詳細タイプの名前を入力するか、選択してください。認証詳細のJSONに含まれるプロパティに基づいてリクエストをフィルタリングするための、追加のカスタムルールを編集および定義できます。たとえば、認証の詳細タイプが resource_access であり、そこにプロパティ location が含まれている場合、そのリクエストは、場所が日本である場合にのみ許可されます。 requestContext.ad.location == 'Japan'その場合、ルールは次のようになります：。
4. 「追加」をクリックし、権限を付与したい各権限詳細タイプについて、前の手順を繰り返します。
API 資格をサインオン・トークンに付与します。
「API アクセスを制限する (Restrict API access)」は、新規アプリケーションのデフォルトの設定です。アプリケーションにはサインオン・トークン資格がありません。 API アクセスのための資格を付与するには、以下の手順を実行します。
1. 編集アイコンを選択します。
  「API クライアントの編集」ウィザードが開始されます。
2. サインオン・トークンに付与するユーザー許可と非ユーザー許可を選択します。
  [ユーザートークンのデフォルトの権限 ] チェックボックスをオンにするか、 [API アクセスを制限する] チェックボックスをオフにすると、ユーザートークンに対して一連のデフォルトの権限が付与されます。「デフォルトのサインオントークン API の権限」を参照してください。
3. 「保存」を選択します。
「保存」を選択します。

次の手順

信頼先に対し、と信頼先の間 Verify で OpenID Connectのサインオン設定を完了するために必要な情報を Verify 提供してください。ユーザー・インターフェースで提供されている説明を参照してください。
構成済みアプリケーションへのアクセスを許可するユーザーまたはグループの資格を追加します。「アプリケーションの権限の管理（管理者またはアプリケーション所有者による）」を参照してください。
ユーザーに対するセキュリティー管理を強化するために、ユーザーが構成済みアプリケーションにサインオンする際に、2 要素認証を実施します。「認証要素の設定」を参照してください。
このアプリケーションに API クライアントを追加します。 OpenID Connectの管理および OpenID Connect for Open BankingアプリケーションのAPIアクセスに関する説明を参照してください。
このアプリケーションのプライバシー目的と EULA を構成します。「 OpenID Connect」をご覧ください。