Table of Contents
このページでは、認可サーバー向けにAuthleteサービスを設定するためのすべてのサービス設定を説明します。これらの設定は、Authlete管理コンソール または Authlete API を通じて簡単に管理できます。
このサービスの名前。最大100文字のUnicode文字を使用できます。
このサービスの説明。最大200文字のUnicode文字を使用できます。
OpenIDプロバイダーとしてこのサービスの識別子です。Authleteはこれを、このサービスが発行するIDトークンのissクレームの値として使用します。また、認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイント（OpenID Connect Discovery 1.0, 4. プロバイダー構成情報の取得）を実装する場合、Authleteはこれをディスカバリーエンドポイントからの応答に含まれるissuerプロパティの値として使用します。
デフォルト値はhttps://authlete.comです。本番環境ではこの値を変更してください。この値はhttps://で始まり、クエリ部分とフラグメント部分を含まないURLでなければなりません。
ディスカバリーエンドポイントのURLは {トークン発行者識別子}/.well-known/openid-configurationでなければならないため、サービスがディスカバリーエンドポイントを公開している場合、トークン発行者識別子の値を決定する際に注意してください。詳細については、OpenID Connect Discovery 1.0, 4. プロバイダー構成情報の取得 を参照してください。
このサービスがサポートするカスタムクライアントメタデータの名前。一部の名前（例: client_name）は予約済みであり、サポートされていません。
このサービスの属性。任意のキーと値のペアをサービスに関連付けることができます。これらの属性は、AuthleteのいくつかのAPIの応答に埋め込まれます（例: /api/auth/introspectionAPI）。ほとんどの場合、属性はserviceAttributesの値として埋め込まれますが、応答にserviceが含まれる場合は、serviceJSONオブジェクトのattributesの値として埋め込まれます。
これらの属性は暗号化され、Authleteのデータベースに保存されます。
このセクションでは、use_service権限を持つサービスアクセストークンを生成できます。これらのトークンは、サービスおよびそのクライアントの管理に必要な権限を付与し、認可サーバーを実装するために必要なすべての主要なエンドポイントを呼び出すことを可能にします。このアクセストークンを、サービスIDとクラスタURLと一緒に使用して、認可サーバーを実装します。
このサービスがサポートするグラントタイプ。この設定項目は、RFC 6749で定義されているフローのうち、どれがサポートされるかを示します。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるgrant_types_supportedプロパティの値として使用されます。
クライアントアプリケーションは、この設定で有効にされたフローのみを使用できます。サポートされていないフローを使用するとエラーが発生します。
AUTHORIZATION_CODE は、認可エンドポイントで認可コードを発行し、トークンエンドポイントでアクセストークンと交換するフローです。詳細はRFC 6749, 4.1. 認可コードグラントに記載されています。これは最も一般的なフローです。
IMPLICIT は、認可エンドポイントで直接アクセストークンを発行するフローです。詳細はRFC 6749, 4.2. インプリシットグラントに記載されています。このフローは、たとえば、Webブラウザで実行されるJavaScriptアプリケーションにアクセストークンを直接発行するために使用されます。
PASSWORD は、ユーザーの資格情報（IDとパスワード）をトークンエンドポイントに提示してアクセストークンを発行するフローです。詳細はRFC 6749, 4.3. リソースオーナーパスワード資格情報グラントに記載されています。仕様では、他のフローが利用できない理由がある場合のみこのフローを使用するよう推奨しています。明確な理由がない場合は、本番環境でこのフローを無効にしてください。
CLIENT_CREDENTIALS は、クライアントアプリケーションの資格情報（クライアントIDとクライアントシークレット）をトークンエンドポイントに提示してアクセストークンを発行するフローです。詳細はRFC 6749, 4.4. クライアント資格情報グラントに記載されています。このフローで発行されるアクセストークンは、ユーザーと関連付けられていません。このようなアクセストークンを発行する明確な理由がない場合は、本番環境でこのフローを無効にしてください。
REFRESH_TOKEN は、トークンエンドポイントにリフレッシュトークンを提示して新しいアクセストークンを取得するフローです。詳細はRFC 6749, 6. アクセストークンのリフレッシュに記載されています。このフローを無効にすると、リフレッシュトークンは発行されません。
[参考] OAuth 2.0の全フローの図と動画
CIBA (TBD)
DEVICE_CODE (TBD)
TOKEN_EXCHANGE (TBD)
JWT_BEARER (TBD)
PRE_AUTHORIZED_CODE (TBD)
認可エンドポイントから発行されるトークンの組み合わせのサポート。もし認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値は、エンドポイントからの応答に含まれるresponse_types_supportedプロパティの値として使用されます。
RFC 6749では、認可エンドポイントで一度に発行できるのは認可コードまたはアクセストークンのみですが、OAuth 2.0 Multiple Response Type Encoding Practicesという追加仕様により、認可コード、アクセストークン、IDトークンの任意の組み合わせを発行できるようになりました。また、何も発行しないオプション（none）も追加されました。
NONE、CODE、TOKEN、ID_TOKENは、それぞれresponse_typeパラメーターに「none」、「code」、「token」、「id_token」を独立して指定できることを意味します。
CODE_TOKENは「code」と「token」の組み合わせ（順不同）を指定できることを意味します。同様に、CODE_ID_TOKENは「code」と「id_token」の組み合わせを、ID_TOKEN_TOKENは「id_token」と「token」の組み合わせを、CODE_ID_TOKEN_TOKENは「code」、「id_token」、「token」の組み合わせを指定できます。
ここで無効にされた組み合わせは、クライアントアプリケーションによってresponse_typeリクエストパラメーターとして使用することはできません。
特に明確な理由がない限り、すべての組み合わせを有効のままにしておくことをお勧めします（「none」を有効または無効にするかは任意です）。
[参考] Diagrams of All The OpenID Connect Flows
この設定を有効にすると、認可サーバーからのエラー応答にerror_descriptionレスポンスパラメーターが含まれます。
error_descriptionはRFC 6749で定義された標準のレスポンスパラメーターですが、その内容は各認可サーバーの実装によって異なります。エラーが発生した場合、Authleteはerror_descriptionレスポンスパラメーターにエラー説明を設定します。説明の内容は一般的なものまたはAuthlete固有のもののいずれかです。いずれの場合も、Authlete固有の結果コードが含まれます。
本番環境で情報を隠したい場合は、この設定を無効にしてください。ただし、その場合、クライアントアプリケーションに返されるエラー情報は非常にシンプルなもの（例: “error=invalid_request"のみ）となり、クライアントアプリケーション開発者がエラー原因を特定するのに時間がかかる可能性があります。
この設定を有効にすると、認可サーバーからのエラー応答にerror_uriレスポンスパラメーターが含まれます。
error_uriはRFC 6749で定義された標準のレスポンスパラメーターですが、その内容は各認可サーバーの実装によって異なります。エラーが発生した場合、Authleteはerror_uriレスポンスパラメーターにURIを設定します。このURIは、エラーの説明が記載されたページを指します。このページはAuthleteのウェブサイト上にあります。本番環境で情報を隠したい場合は、この設定を無効にしてください。
認可エンドポイントのURL。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるauthorization_endpointプロパティの値として使用されます。
OpenID Connect Discovery 1.0では、authorization_endpointプロパティが必須とされています。そのため、仕様に完全に準拠したい場合、この設定項目に適切な値を設定してください。
[推奨] この設定項目は、認可コードフローにおいてcode_challengeリクエストパラメーターを必須のパラメーターとするかどうかを決定します。
有効にすると、code_challengeリクエストパラメーターを含まない認可コードフローの認可リクエストはすべて拒否されます。
無効にすると、code_challengeリクエストパラメーターはオプションとなりますが、それでも認可リクエストにこのリクエストパラメーターが含まれている場合、仕様で定義されているように処理されます。その結果、対応するトークンリクエストには、code_verifierリクエストパラメーターを含める必要があります。
code_challengeはRFC 7636（Proof Key for Code Exchange by OAuth Public Clients）で定義されています。この仕様は、認可コードの傍受攻撃への対策です。スマートフォンアプリケーションが認可コードフローを使用する場合、セキュリティ上の観点からcode_challengeリクエストパラメーターはほぼ必須です。
この設定を有効にすると、システムはより安全になります。ただし、クライアントアプリケーション開発者には追加の作業が必要になります。
“既存の PKCE をサポートしないクライアントサポートする必要がある” といった特別の理由がない限り、特に新しいサービスを構築し、新しいクライアントアプリケーションを開発する場合、本番環境では「必須」を選択することを推奨します。
(TBD)
[参考] Proof Key for Code Exchange (RFC 7636)
認可レスポンスJWTの有効期間（秒単位）。
金融グレードAPI: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)では、response_modeリクエストパラメーターに以下の新しい値を定義しています:
query.jwtfragment.jwtform_post.jwtjwtこれらの値のいずれかがレスポンスモードとして指定されると、認可エンドポイントからのレスポンスパラメーターはJWTにパックされます。この値は、JWTのexpクレームの値を計算するために使用されます。最大値は999999999999999秒（約3170万年）です。
issレスポンスパラメーターを抑制を有効にすると、認可サーバーは認可応答にissレスポンスパラメーターを含めません。
「OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response」は、特定の種類のミックスアップ攻撃に対する対策として、新しい認可応答パラメーターであるissを定義しています。
仕様では、JARM（JWT Secured Authorization Response Mode）が使用されない限り、issレスポンスパラメーターを常に認可応答に含める必要があるとされています。
この設定項目を切り替えることで、クライアントアプリケーションの開発者はミックスアップ攻撃とissレスポンスパラメーターの効果を試すことができます。
特別な理由がない限り、本番環境ではissレスポンスパラメーターを抑制を有効にしないでください。
ホストコンポーネントがループバックを示す場合に、リダイレクションURIのポート番号コンポーネントを可変にできるかどうかを示すフラグ。
Variableを選択すると、認可リクエストで指定されたリダイレクトURIのホスト名がループバックを示す場合（具体的には、ホストコンポーネントがlocalhost、127.0.0.1、または::1である場合）、指定されたリダイレクションURIが事前登録されたURIと比較される際にポート番号コンポーネントが無視されます。この動作はRFC 8252 OAuth 2.0 for Native Appsの7.3. ループバックインターフェイスリダイレクションに記載されています。
RFC 6749の3.1.2.3. 動的構成では次のように述べられています:
“If the client registration included the full redirection URI, the authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986] Section 6.2.1.”
また、OpenID Connect Core 1.0の3.1.2.1. 認証リクエストにおけるredirect_uriの記述では次のように述べられています:
“This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).”
これらの「単純な文字列比較」の要件は、このフラグによって優先されます。すなわち、RFC 6749およびOpenID Connect Core 1.0で記載されている条件が満たされている場合でも、このフラグが有効であればループバックリダイレクションURIのポート番号コンポーネントを可変にすることができます。
RFC 8252の8.3. Loopback Redirect Considerationsでは次のように述べられています:
“While redirect URIs using
localhost(i.e.,http://localhost:{port}/{path}) function similarly to loopback IP redirects described in Section 7.3, the use oflocalhostis NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather thanlocalhostavoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user’s device.”
ただし、Authleteではlocalhostの場合にもポート番号コンポーネントを可変にすることができます。localhostを使用するか、リテラルのループバックIPアドレス（IPv4の場合は127.0.0.1、IPv6の場合は::1）を使用するかはクライアントアプリケーション次第です。
RFC 8252のセクション7.3および8.3では、ループバックリダイレクションURIにはhttpスキームが使用されるとされていますが、Authleteではhttpsスキームの場合にもポート番号コンポーネントを可変にすることを許可しています。
なお、FAPI 1.0 Part 1 セクション7.5. ネイティブアプリでは次のように明記されています:
“shall not support Loopback Interface Redirection”
そのため、このフラグをVariableに選択しても、FAPIのコンテキストではループバックリダイレクションURIのポート番号コンポーネントを可変にすることはできません。
認可サーバーの認可ページでサポートされる表示言語のリスト。技術的には、認可エンドポイントがui_localesパラメーターの値として認識する言語タグのリストです（OpenID Connect Core 1.0, 3.1.2.1. 認証リクエストを参照）。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるui_locales_supportedプロパティの値として使用されます。
クライアントアプリケーションは、ui_localesリクエストパラメーターを使用して認可ページの表示言語を指定することができます。ただし、認可サーバーがこのリクエストパラメーターを尊重して表示言語を変更することが保証されているわけではありません。
たとえ認可サーバーがui_localesパラメーターを完全に無視しても、これは仕様違反ではありません。おそらく、ほとんどの認可サーバー実装はui_localesパラメーターを認識せず、Accept-LanguageHTTPヘッダーのみを認識します。
認可リクエストに含まれるui_localesパラメーターの値は、Authleteの/api/auth/authorizationAPIの応答でuiLocalesプロパティの値として返されます。ただし、この設定項目にリストされていない言語は、uiLocalesに含まれることはありません。たとえば、認可リクエストにui_locales=jaが含まれていても、この設定項目に「ja」がリストされていない場合、uiLocalesプロパティに「ja」は現れません。
認可エンドポイントの実装がui_localesリクエストパラメーターを無視する場合、この設定項目を空のままにしておくことができます。
認可サーバーの認可ページでサポートされる表示タイプのリスト。技術的には、認可エンドポイントがdisplayパラメーターの値として認識する有効な値のリストです（OpenID Connect Core 1.0, 3.1.2.1. 認証リクエストを参照）。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるdisplay_values_supportedプロパティの値として使用されます。
PAGE は、ユーザーエージェントの全体の描画エリアを使用するデフォルト値です。この表示タイプが有効である場合、display=pageを認可リクエストに含めることができます。この表示タイプが無効な場合、displayリクエストパラメーターを明示的に含めないすべての認可リクエストは無効なリクエストと見なされます。そのため、この表示タイプを無効にしないでください。
POPUP は、ポップアップを使用することをリクエストする値です。この表示タイプが有効である場合、display=popupを認可リクエストに含めることができます。
TOUCH は、タッチデバイスに適したページをリクエストする値です。この表示タイプが有効である場合、display=touchを認可リクエストに含めることができます。
WAP は、フィーチャーフォンに適したページをリクエストする値です。この表示タイプが有効である場合、display=wapを認可リクエストに含めることができます。
クライアントアプリケーションは、displayリクエストパラメーターを使用して認可ページの表示タイプを指定することができます。ただし、認可サーバーがこのリクエストパラメーターを尊重して表示タイプを変更することが保証されているわけではありません。認可サーバーがdisplayパラメーターを完全に無視しても、仕様違反ではありません。
この設定項目でチェックされていない値をdisplayリクエストパラメーターとして使用すると、認可サーバーはエラーを返します。
認可リクエストに含まれるdisplayパラメーターの値は、Authleteの/api/auth/authorizationAPIの応答でdisplayプロパティの値として返されます。認可リクエストにdisplayパラメーターが含まれない場合、/api/auth/authorizationAPIの応答でのdisplayプロパティの値はデフォルト値のPAGEになります。
特に理由がない限り、すべての表示タイプを有効にしておくことをお勧めします。
認可エンドポイントでユーザー認証に使用される認証コンテキストクラス参照のリスト。認可サーバーAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるacr_values_supportedプロパティの値として使用されます。
クライアントアプリケーションは、認可リクエストを処理する際に満たされるべき認証コンテキストを指定できます。認証コンテキストを指定する方法には次の3つがあります:
acr_valuesリクエストパラメーター (OpenID Connect Core 1.0, 3.1.2.1. 認証リクエスト)claimsリクエストパラメーター内のacrクレーム (OpenID Connect Core 1.0, 5.5. “claims"リクエストパラメーターを使用したクレームのリクエスト)default_acr_valuesメタデータ (OpenID Connect Dynamic Client Registration 1.0, 2. クライアントメタデータ)これらの方法で指定された認証コンテキストがAuthleteにより処理されますが、この設定項目にリストされていない値はドロップされます。たとえば、認可リクエストにacr_values=my_acrが含まれていても、この設定項目にmy_acrが含まれていない場合、my_acrはAuthleteの/api/auth/authorizationAPIの応答でacrsプロパティに含まれません。
認可サーバーが指定された認証コンテキストの値を参照し、それに応じて動作を変更する予定がない場合、この設定項目を空のままにしておくことができます。
イギリスのUK Open Bankingでは、少なくとも次の2つの認証コンテキストを定義しています:
urn:openbanking:psd2:scaurn:openbanking:psd2:ca必須にするが選択されている場合、このサービスへのすべての認可リクエストは、requestまたはrequest_uriパラメーターを使用してリクエストオブジェクトを必ず指定する必要があります。
必須にするが選択され、かつリクエストオブジェクト処理でJAR互換性を有効にするが選択されている場合、このサービスは、サーバーメタデータのrequire_signed_request_objectがtrueであるかのように動作します。JAR（JWT Secured Authorization Request）に関する詳細は、その仕様を参照してください。
JAR互換性を有効にするが選択されている場合、リクエストオブジェクトはJAR（JWT Secured Authorization Request）で定義されているルールに基づいて処理されます。選択されていない場合は、後方互換性のためにOpenID Connect Core 1.0で定義されているルールに基づいて処理されます。
JARルールとOIDC Core 1.0ルールの違いは以下の通りです:
response_typeが含まれていても、response_typeパラメーターをリクエストオブジェクト外部に必ず指定する必要があります。一方で、JARルールが適用される場合、リクエストオブジェクト外部にresponse_typeパラメーターを指定する必要はありません。ただし、代わりに、リクエストオブジェクト内にresponse_typeを常に含めることをJARが要求します。scopeパラメーターをリクエストオブジェクト外部に必ず指定する必要があります。一方で、JARルールが適用される場合、リクエストオブジェクト外部にscopeを指定する必要はありません。ただし、リクエストオブジェクト内にscopeが含まれている必要があります。この設定は、FAPI 1.0 ID2から1.0 Finalへの移行をスムーズに行い、ライブシステムを破壊しないようにするために設計されています。必須にするが無効の場合、認可リクエストがFAPI-Part2リクエストとみなされる場合でも、認可リクエストで使用されるリクエストオブジェクト内のnbfクレームはオプションとして扱われます。
最終版の金融グレードAPI（FAPI）は2021年1月に承認されました。パート2ではリクエストオブジェクトの有効期間に関する新しい要件が導入されました: それには
nbfクレームが含まれている必要があり、その有効期間（exp - nbf）は60分を超えてはなりません。認可リクエストがFAPI-Part2リクエストとして扱われる場合、そのリクエストオブジェクトにはnbfクレームが含まれていなければならず、そうでない場合、認可サーバーはそれを拒否します。この設定により、必要に応じて後方互換性が提供されます。
authorization_detailsの各要素内のtypeフィールドのサポートされる値。詳細は OAuth 2.0 Rich Authorization Requests で定義されています。
必須にするが選択されている場合、フロントチャネル経由でリクエストオブジェクトを渡す際に暗号化が必須となります。
このプロパティの設定は、OAuth 2.0 Pushed Authorization Requestsで定義されたプッシュ型認可リクエストエンドポイントでのリクエストオブジェクト処理には影響しません。このプロパティが必須にするに設定されている場合でも、暗号化されていないリクエストオブジェクトはエンドポイントで受け入れられます。
なお、必須にするが選択されていない場合でも、クライアントのリクエストオブジェクト フロントチャネルにおける暗号化が必須にするに設定されている場合、リクエストオブジェクトの暗号化は必須です。
必須にするが選択されている場合、暗号化されたリクエストオブジェクトのJWE algは、リクエストオブジェクトを送信したクライアントのrequest_object_encryption_algクライアントメタデータと一致する必要があります。
必須にするが選択されていない場合でも、クライアントのリクエストオブジェクト 暗号化アルゴリズムマッチが必須にするに設定されている場合、この一致は必須です。
必須にするが選択されている場合、暗号化されたリクエストオブジェクトのJWE encは、リクエストオブジェクトを送信したクライアントのrequest_object_encryption_encクライアントメタデータと一致する必要があります。
必須にするが選択されていない場合でも、クライアントのリクエストオブジェクト 暗号化アルゴリズムマッチが必須にするに設定されている場合、この一致は必須です。
必須にするが選択されている場合、Authleteはリクエストオブジェクトのaudクレームがこのサービスの発行者識別子と一致しているかを確認し、それらが異なる場合にエラーを発生させます。一方、必須にするが選択されていない場合、Authleteはaudクレームの値を確認しません。
OpenID Connect Core 1.0およびRFC 9101では、audクレームはサーバーの発行者識別子と一致または含むべきであるとされています。この記述を必須要件として扱いたい場合、必須にするを選択してください。
official conformance suite のカテゴリによっては、ここで必須にするを選択する必要があります。
トークンエンドポイントのURL。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるtoken_endpointプロパティの値として使用されます。
JWTベースのクライアント認証方式がトークンエンドポイントで使用されている場合（トークンリクエストにclient_assertion={JWT}が含まれる場合）、JWTのaudクレームの値はトークンエンドポイントのURLである必要があります。そのため、トークンエンドポイントがCLIENT_SECRET_JWTおよびPRIVATE_KEY_JWTをサポートしている場合、正しい値を設定してください。
トークンエンドポイントでサポートされるクライアント認証方式。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるtoken_endpoint_auth_methods_supportedプロパティの値として使用されます。
クライアントタイプが「機密性あり」（RFC 6749, セクション2.1）であるクライアントアプリケーションが存在する場合、NONE以外の少なくとも1つのクライアント認証方式がサポートされていなければなりません。
TLSベースのクライアント認証方式をサポートするには、フロントエンド認可サーバーのトークンエンドポイント実装がトークンリクエストからクライアント証明書を抽出し、Authleteの/api/auth/tokenAPIのclientCertificateリクエストパラメーターとして渡す必要があります。
ATTEST_JWT_CLIENT_AUTH
(TBD)
offline_accessを必須にするが選択されている場合、openidスコープはリフレッシュトークンフローで発行される新しいアクセストークンから削除されます。ただし、提示されたリフレッシュトークンがoffline_accessスコープを含んでいる場合は例外です。
許可するが選択されている場合、パブリッククライアント(RFC 6749, Section 2.1)からのclient_idリクエストパラメーターを含まないトークンリクエストを許可します。この場合、トークンリクエストがclient_idリクエストパラメーターを含まない場合、トークンエンドポイントは認可コードまたはリフレッシュトークンの値からクライアントを特定しようとします。
ただし、通常の場合、認可サーバーはこのような動作を行うべきではありません。そのため、特別な理由がない限り、許可するを選択しないでください。
Requireが選択されている場合、サービスは、クライアント識別子を含まないグラントタイプurn:ietf:params:oauth:grant-type:jwt-bearer、トークンリクエストを拒否します。
RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grantsには次のように記載されています:
“JWT認可グラントは、クライアント認証または識別の有無にかかわらず使用できます。”
技術的に、この文脈での**“identification”**とは、トークンリクエストにリクエストを行ったクライアントの識別子が含まれていないことを意味します。
RFC 7523はこれを許容していますが、識別できないクライアント（APIコーラー）がトークンリクエストを行うことを許可するのはリスクがあります。ただし、識別されていないクライアントによるトークンリクエストが必要であり、何らかの方法で運用の安全性が確保できる場合、このスイッチをオフにすることができます。
スキップするが選択されている場合、Authleteは、JWTが暗号化されていると検出した際に入力アサーションの残りの検証ステップをスキップします。この場合、認可サーバーの実装は、暗号化されたJWTを認可グラントとして使用する場合に独自に検証する必要があります。
スキップするが選択されていない場合、サービスは、グラントタイプurn:ietf:params:oauth:grant-type:jwt-bearer (RFC 7523)を使用する暗号化されたJWTを認可グラントとして含むトークンリクエストを拒否します。
Authleteが実行する検証プロセスの詳細については、AuthleteのウェブサイトにあるJWT Authorization Grantを参照してください。
スキップするが選択されている場合、Authleteは、JWTが署名されていないと検出した際に入力アサーションの残りの検証ステップをスキップします。
スキップするが選択されていない場合、サービスは、グラントタイプurn:ietf:params:oauth:grant-type:jwt-bearer (RFC 7523)を使用する署名されていないJWTを認可グラントとして含むトークンリクエストを拒否します。
Authleteが実行する検証プロセスの詳細については、AuthleteのウェブサイトにあるJWT Authorization Grantを参照してください。
RFC 7009で定義されているトークン取り消しエンドポイントのURL。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるrevocation_endpointプロパティの値として使用されます。
トークン取り消しエンドポイントの実装は必須ではありません。
Authleteの/api/auth/revocationAPIは、RFC 7009に準拠したトークン取り消しエンドポイントを実装するための支援APIです。このAPI自体はRFC 7009の実装ではありません。
RFC 7662で定義されているトークンインスペクションエンドポイントのURL。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるintrospection_endpointプロパティの値として使用されます。
トークンインスペクションエンドポイントの実装は必須ではありません。
Authleteの/api/auth/introspection/standardAPIは、RFC 7662に準拠したトークンインスペクションエンドポイントを実装するための支援APIです。このAPI自体はRFC 7662の実装ではありません。
Authleteの/api/auth/introspectionAPIは、Authlete固有のカスタムインスペクションAPIです。このAPIは、アクセス元トークンに関する情報を返すだけでなく、アクセス元トークンを検証し、必要に応じてRFC 6750に準拠したエラーメッセージを生成します。また、このAPIはアクセス元トークンに関連付けられた任意のキーと値のペアに関する情報も返します（Authleteのカスタム機能）。そのため、通常の場合、リソースサーバー上のWeb API実装は、Authlete固有のインスペクションAPIを使用します。
Require PARが選択されている場合、PARを使用しない認可リクエストはAuthleteによって拒否されます。
プッシュ型認可リクエストエンドポイントのURL。クライアントアプリケーションは、このエンドポイントで認可リクエストを事前登録し、その後、登録された認可リクエストを表すrequest_uriを取得できます。このrequest_uriを認可リクエストに含めることができます。技術的な詳細は OAuth 2.0 Pushed Authorization Requests で定義されています。
このプロパティの値は、ディスカバリーエンドポイントの応答に含まれるpushed_authorization_request_endpointメタデータの値として使用されます。
プッシュ型認可リクエストエンドポイントから発行されたrequest_uriのデフォルトの有効期間（秒単位）。値が0の場合、Authleteサーバーで設定されたデフォルト値が使用されます。
プッシュ型認可リクエストエンドポイントに登録される認可リクエストに有効期限情報が含まれている場合（例: expクレームの値として）、その情報が考慮されます。指定された有効期限とデフォルト値のうち、小さい方の値が選択され、登録された認可リクエストの有効期間として使用されます。
仕様 OAuth 2.0 Pushed Authorization Requests は次のように述べています: “The request URI lifetime is at the discretion of the AS.”
そのため、ここで説明されている動作はAuthleteの実装固有のものです。
OpenID Connect Core 1.0, 5.3. UserInfo Endpointで定義されているユーザー情報エンドポイントのURL。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるuserinfo_endpointプロパティの値として使用されます。
ユーザー情報エンドポイントの実装は必須ではありません。
Authleteの/api/auth/userinfoAPIおよび/api/auth/userinfo/issueAPIは、ユーザー情報エンドポイントを実装するための支援APIです。AuthleteのAPI自体はユーザー情報エンドポイントではありません。
このサービスがOpenID Federation 1.0をサポートしているかどうかを示すフラグ。
ただし、このサービスをホストしているAuthleteサーバーでOpenID Federation 1.0の機能が有効になっていない場合、このプロパティの設定に関わらず、関連機能を使用することはできません。
このサービスがサポートするクライアント登録タイプ。このプロパティは、OpenID Federation 1.0で定義されているclient_registration_types_supportedサーバーメタデータに対応します。
明示的がチェックされている場合、登録エンドポイントを適切に設定する必要があります。
フェデレーションクライアント登録エンドポイントのURI。このプロパティは、OpenID Connect Federation 1.0で定義されているfederation_registration_endpointサーバーメタデータに対応します。
認可サーバーがクライアント登録タイプ明示的をサポートしていると宣言する場合、このプロパティは空であってはなりません。
このサービスを運営している組織を表す人間が読める形式の名前。このプロパティは、OpenID Connect Federation 1.0で定義されているorganization_nameサーバーメタデータに対応します。
このプロパティが空でない場合、organization_nameプロパティは、このサービスの自己署名エンティティステートメントに含まれます。
このサービスのエンティティステートメントを発行できる権限の識別子。このプロパティは、自己署名エンティティステートメント内のauthority_hintsプロパティに対応します。識別子の形式は、httpsまたはhttpスキームのURLです。
OpenID Federation 1.0に参加しているOpenIDプロバイダーは、1つ以上の上位権限を持っていると予想されます。上位権限を持たない信頼アンカーのみが上位権限を持ちません。
自己署名エンティティステートメント内のauthority_hintsプロパティは必須であるため、この設定を空のままにすると、構成エンドポイント（/.well-known/openid-federation）は有効なエンティティステートメントを生成できなくなります。そのため、OpenID Connect Federation 1.0を機能させるには、このプロパティを適切に設定する必要があります。
エンティティ設定の有効期間（秒単位）。
OpenID Connect Federationに参加しているOpenIDプロバイダーは、エンティティ構成を/.well-known/openid-federationまたはそのバリエーションの場所（例: /.well-known/openid-federation{path_part_of_issuer}）で公開する必要があります。エンティティ構成はJWTの一種です。このプロパティは、JWTの有効期間を秒単位で指定します。
このプロパティの値が0の場合、Authleteサーバーで設定されたデフォルト値がエンティティ構成の有効期間として使用されます。
このサービスが依存する信頼チェーンの解決時に参照される信頼アンカー。このプロパティが空の場合、クライアント登録の試みは、登録タイプが自動であれ明示的であれ、失敗します。そのため、OpenID Connect Federation 1.0を機能させるには、このプロパティを適切に設定する必要があります。
各信頼アンカーにはエンティティIDとJWKセットがあります。エンティティIDの形式は、httpsまたはhttpスキームのURLです。JWKセットは、このサービスが信頼アンカーによって発行されたエンティティステートメントの署名を検証するために使用する公開鍵を含む必要があります。
OpenID Connect Federation 1.0仕様では、信頼アンカーのJWKセットを取得する方法については定義していません。これは仕様の対象外とされています。
サポートするが選択されている場合、このサービスは動的クライアント登録プロトコルAPIへのアクセスを許可します。
このプロトコルをサポートするには、登録エンドポイントURIと登録管理エンドポイントのベースURIの両方を提供する必要があります。
サポートするが選択されていない場合、このサービスでは登録APIは利用できませんが、通常のクライアント管理APIは引き続き利用可能です。
詳細については、OpenID Connect Dynamic Registration 1.0を参照してください。
このスイッチは、認可サーバーの動的クライアント登録/構成エンドポイントがクライアントメタデータ内のscopeパラメーターを認識するかどうかを示します。
有効にするが選択されている場合、Authleteの/api/client/registrationAPIおよび/api/client/registration/updateAPIは、scopeパラメーターの値を使用して、クライアントアプリケーションがリクエスト可能なスコープの範囲を制限します。この制限は、指定されたスコープをリクエスト可能なスコープ（ClientExtension.isRequestableScopesEnabled()参照）として登録することによって実現されます。AuthleteのAPIは、動的クライアント登録/構成エンドポイントからの応答を表すresponseContentレスポンスパラメーターにscopeパラメーターを埋め込みます。
スイッチがオフの場合、AuthleteのAPIはクライアントメタデータ内のscopeパラメーターを無視し、responseContentにscopeパラメーターを埋め込みません。この動作は以前のAuthleteバージョンとの後方互換性があります。この場合、リクエスト可能なスコープの範囲に制限は課されず、クライアントアプリケーションは認可サーバーがサポートする任意のスコープをリクエストできます。
技術的な詳細については、RFC 7591 OAuth 2.0 Dynamic Client Registration Protocolを参照してください。
DCR（動的クライアント登録）リクエストには、RFC 7591で定義されたsoftware_idクライアントメタデータが含まれる場合があります。このクライアントメタデータは、他のクライアントメタデータとともにAuthleteのデータベースに保存されます。
許可するが選択されている場合、Authleteはsoftware_idの重複チェックを行いません。
許可するが選択されていない場合、AuthleteはDCRリクエストに含まれるsoftware_idクライアントメタデータの値がデータベースに既に存在しているかをチェックし、存在している場合はDCRリクエストを拒否します。
クライアントアプリケーションを動的に登録するためのエンドポイントのURL（OpenID Connect Dynamic Client Registration 1.0）。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるregistration_endpointプロパティの値として使用されます。
登録エンドポイントの実装は必須ではありません。
現在、AuthleteはOpenID Connect Dynamic Client Registration 1.0に準拠するAPIを直接提供していません。ただし、/api/service/createAPIを使用してクライアントを動的に登録できます。
このサービスのクライアント登録エンドポイントのURL。ASCII文字のみ使用可能。最大200文字。このURLはhttps://で始まる必要があります。
この値は、このサービスのOpenIDプロバイダーメタデータ内のregistration_endpointプロパティの値として使用されます。
詳細については、OpenID Connect Dynamic Registration 1.0を参照してください。
/api/client/registrationAPIのエラー発生時の挙動を切り替えるためのフラグ。Return Unauthorizedが選択されている場合、適切な場合にUNAUTHORIZEDをactionレスポンスパラメーターの値として使用します。Return Unauthorizedが選択されていない場合、このAPIは決してUNAUTHORIZEDを使用しません。
UNAUTHORIZED列挙値は、初期実装のClientRegistrationResponse.Action列挙型 (JavaDoc)には存在していませんでした。そのため、クライアント構成エンドポイントの実装は、RFC 7592の要件を厳密に遵守できませんでした。
後方互換性を保つため（動作中のシステムを壊さないため）、このフラグがOFFの場合、APIはUNAUTHORIZEDアクションを使用しません。
既存のクライアント構成エンドポイントの実装が、401 Unauthorized関連の要件を遵守するために実行すべき手順は次のとおりです:
UNAUTHORIZEDアクションを処理できるようにします。RFC 7592では、登録アクセストークンが無効であるかクライアントが存在しない（または無効である）場合、クライアント構成エンドポイントは401 Unauthorizedを返す必要があるとされています。
このプロパティは、Grant Management for OAuth 2.0で定義されたgrant_management_action_requiredサーバーメタデータに対応します。グラント管理アクションパラメーターを必須にするが選択されている場合、すべての認可リクエストおよび認可リクエストとして機能するリクエスト（例: CIBAバックチャネル認証リクエスト）は、grant_management_actionリクエストパラメーターを必ず含める必要があります。
グラント管理パラメーターを必須にするを選択すると、仕様が公開クライアントに対してグラント管理を利用することを許可していないため、公開クライアントからのすべての認可リクエストは拒否されます。
グラント管理エンドポイントのURL。このプロパティは、Grant Management for OAuth 2.0で定義されたgrant_management_endpointサーバーメタデータに対応します。このプロパティが設定されている場合、queryおよびrevokeが、ディスカバリードキュメント (OIDC Discovery)で公開されるgrant_management_actions_supportedサーバーメタデータに追加されます（デフォルトセットであるcreate、replace、mergeに加えて）。
OAuth 2.0のためのグラント管理は、Authlete 2.3からサポートされています。グラント管理エンドポイントは、Authleteの/api/gmAPIを使用して実装できます。
デバイス認証エンドポイントのURL。このプロパティは、OAuth 2.0デバイス認証フロー（Device Flow）で定義されているdevice_authorization_endpointメタデータに対応します。この値はASCII文字のみで構成され、長さは200文字以下でなければなりません。また、スキーム部分はhttpsで始まる必要があります。
このプロパティは、ディスカバリーエンドポイントの応答でdevice_authorization_endpointとして使用されます。また、JWTベースのクライアント認証方式（client_secret_jwtまたはprivate_key_jwt）が使用される場合、クライアントアサーション（client_assertion）内のaudクレームはこのプロパティの値と比較されます。
検証URI。このプロパティは、デバイス認証エンドポイントの応答でverification_uriパラメーターの値として使用されます。この値はASCII文字のみで構成され、長さは200文字以下でなければなりません。また、スキーム部分はhttpsで始まる必要があります。
デバイスフローを使用するには、このプロパティを事前に設定する必要があります。設定されていない場合、/api/device/authorizationAPIの呼び出し時にエラーが返されます。
ユーザーコードのプレースホルダーを含む検証URI。この値はASCII文字のみで構成され、長さは200文字以下でなければなりません。また、スキーム部分はhttpsで始まる必要があります。
このプロパティが設定され、その値に固定文字列USER_CODE（例: https://example.com/verification?user_code=USER_CODE）が含まれている場合、デバイス認証エンドポイントの応答でverification_uri_completeパラメーターの値を生成するために使用されます。Authleteは固定文字列を実際のユーザーコードに置き換えます。このプロパティが設定されていないか、または固定文字列が含まれていない場合、デバイス認証エンドポイントの応答にverification_uri_completeパラメーターは含まれません。
デバイス検証コード（device_code）およびエンドユーザー検証コード（user_code）の有効期間（秒単位）。この値は、デバイス認証エンドポイントの応答でexpires_inパラメーターの値として使用されます。
デバイスフローを使用するには、このプロパティに正の値を設定する必要があります。設定されていない場合、/api/device/authorizationAPIの呼び出し時にエラーが返されます。
トークンエンドポイントへのポーリングリクエスト間の最小間隔（秒単位）。値は0から65,535の間である必要があります。この値は、デバイス認証エンドポイントの応答でintervalパラメーターの値として使用されます。ただし、この値が0の場合は例外です。値が0の場合、認可エンドポイントからの応答にintervalパラメーターは含まれません。
ユーザーコード（user_code）の文字セット。
BASE20が選択されている場合、ユーザーコードはBCDFGHJKLMNPQRSTVWXZ（20文字の大文字で母音を含まない文字）で構成されます（例: WDJBMJHT）。NUMERICが選択されている場合、0123456789が使用されます（例: 019450730）。このプロパティが設定されていない場合、デフォルト値としてBASE20が使用されます。
Authleteが生成するユーザーコードにはダッシュやその他の句読点が含まれない点に注意してください。
ユーザーコード（user_code）の長さ。この値は0から255の間である必要があります。
値が0の場合、BASE20文字セットを使用する場合はユーザーコードの長さは8文字になり（エントロピーは20^8）、NUMERIC文字セットを使用する場合は9文字になります（エントロピーは10^9）。このプロパティの値はユーザーコードのエントロピーに直接影響を与えます。値を低く設定しすぎると、一意性制約によるデータベースエラーが頻発する可能性があります。一方、値を高く設定しすぎると、エンドユーザーがユーザーコードを入力する意欲を削ぐ可能性があります。そのため、極端な値を設定しないことをお勧めします。
PKI証明書チェーンを検証するが選択されている場合、AuthleteサーバーはTLS_CLIENT_AUTHクライアント認証に使用されるクライアント証明書が事前に登録されたルート証明書から到達可能かどうかを確認します。
PKI証明書チェーンを検証するが選択されていない場合、Authleteサーバーはこの検証を行いません。そのため、フロントエンド認可サーバーの実装で検証を行う必要があります。
信頼できるルート証明書は、Trusted Root Certificates for Mutual TLS Authentication設定項目に登録できます。
相互TLS PKI認証でクライアント証明書チェーンを検証する際に使用される信頼できるルート証明書のリスト。上記のPKI証明書チェーンを検証する設定が有効な場合、AuthleteサーバーはTLS_CLIENT_AUTHで使用されるクライアント証明書がここに登録されたルート証明書から到達可能であるかを確認します。
このプロパティは、OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokensの「5. Metadata for Mutual TLS Endpoint Aliases」で定義されたmtls_endpoint_aliasesメタデータに対応します。
[重要] OAuth 2.0およびOpenID Connectの基本機能に加えてサポートされる追加機能。この機能がAuthleteサーバー環境で有効になっていない場合、コンソールで有効にしていても使用できません。詳細についてはsales@authlete.comにお問い合わせください。
FAPIは、OpenID FoundationのFAPIワーキンググループによって定義されたセキュリティプロファイルのセットです。
OPEN_BANKINGは、イギリスのOpen Banking Implementation Entityによって定義されたOpen Banking Security Profileを表します。この機能はFAPIの上で動作します。
(TBD)
(TBD)
バックチャネル認証エンドポイントのURL。このプロパティは、backchannel_authentication_endpointメタデータに対応します。
サポートするトークン配信モードを選択します。
バックチャネル認証エンドポイントから発行されるauth_req_idの有効期間（秒単位）。これは、バックチャネル認証エンドポイントの応答でexpires_inプロパティの値として使用されます。
クライアントアプリケーションがトークンエンドポイントにポーリングリクエストを送信する際の最小間隔（秒単位）。これは、バックチャネル認証エンドポイントの応答でintervalプロパティの値として使用されます。最大値は65,535秒です。
サポートするが選択されている場合、バックチャネル認証エンドポイントでuser_codeリクエストパラメーターがサポートされます。このプロパティは、backchannel_user_code_parameter_supportedメタデータに対応します。
必須にするが選択されている場合、バックチャネル認証リクエストが金融グレードAPI（FAPI）のリクエストと判断された場合、binding_messageリクエストパラメーターが常に必須となります。
FAPI-CIBAプロファイルでは、認可サーバーが「認証リクエスト内に一意の認可コンテキストが存在することを保証するか、認証リクエストにbinding_messageを必須とすること」を求めています（FAPI-CIBA, 5.2.2, 2）。この要件を満たす最も簡単な方法は、ここで必須にするを選択することです。
必須にするを選択しない場合でも、binding_messageリクエストパラメーターはオプションのままですが、その代わりに認可サーバーは各バックチャネル認証リクエストに一意のコンテキストを持たせるカスタムメカニズムを実装する必要があります。
このサービスから発行されるアクセストークンの種類。この設定項目の値は、認可サーバーの応答でアクセストークンとともに返されるtoken_typeレスポンスパラメーターの値として使用されます。
リソースサーバー上のWeb APIがRFC 6750で定義された方法でアクセストークンを受け取る場合、Bearer（大文字小文字を区別しない）を設定してください。
通常、Web APIの実装は特別な理由がない限り、RFC 6750に準拠しています。
アクセストークンの有効期間（秒単位）。この値は、アクセストークンとともに返されるexpires_inレスポンスパラメーターの値を計算するために使用されます。
アクセストークンの適切な有効期間は、各サービスの特性に依存します。1時間、1日、1年、さらには100年といった期間も考えられます。
この設定項目に設定された値は、このサービスによって発行されるすべてのアクセストークンに適用されます。ただし、/api/auth/token/updateAPIをaccessTokenExpiresAtリクエストパラメーターとともに呼び出すことで、アクセストークンの有効期限を個別に変更することが可能です。また、/api/auth/token/createAPI（アクセストークンを手動で作成するために使用）には、accessTokenDurationリクエストパラメーターがあり、新規に作成されるアクセストークンの期間を指定することができます。
さらに、「スコープ属性」を使用してアクセストークンの有効期間を制御するメカニズムもあります。詳細はスコープに関する説明を参照してください。
アクセストークンの署名に使用されるアルゴリズム。このプロパティが設定されている場合、このサービスが発行するアクセストークンはJWTとなります。設定されていない場合、このサービスが発行するアクセストークンはランダムな文字列となります。
アクセストークンの署名に使用されるJWK（JSON Web Key）を識別するためのキーID（このプロパティはJWTベースのアクセストークンが生成される場合にのみ使用されます）。
適用可能なJWKが1つだけであれば問題はありません。ただし、複数の候補がある場合、Authleteサーバーが正しいJWKを選択するためにキーIDを指定する必要があります。
この設定に値が設定されている場合、それはキーIDとして解釈されます。AuthleteサーバーはこのキーIDを使用して、アクセストークンの署名に使用するJWKを選択します。
複数の候補JWKが存在し、この設定が空の場合でも、Authleteサーバーは最善を尽くして1つを選択します。ただし、複数の候補JWKがあり、そのいずれにもキーIDが設定されていない場合など、Authleteサーバーが選択できない場合があります。そのような場合、アクセストークンの生成に失敗する可能性があります。
このサービスがOAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokensで定義されたクライアント証明書にバインドされたアクセストークンをサポートするかどうかを制御する設定項目です。Enableが選択されている場合、Authleteの/api/service/configurationAPIを使用して実装されたディスカバリーエンドポイントには"tls_client_certificate_bound_access_tokens":trueが含まれます。
この機能が有効な場合、トークンリクエストで使用されたクライアント証明書が、発行されたアクセストークンと関連付けられます。クライアントアプリケーションがそのアクセストークンを使用してWeb APIにアクセスする場合、トークンリクエストで使用されたのと同じクライアント証明書を使用する必要があります。そうでない場合、アクセスは拒否されます。
アクセストークンがクライアント証明書と関連付けられることで、アクセストークンが漏洩した場合でも、そのアクセストークンを悪用することが困難になります。漏洩したアクセストークンを使用してWeb APIにアクセスするには、アクセストークン発行時に使用されたクライアント証明書も必要になるためです。
この機能を使用するには、トークンエンドポイントおよびWeb APIの実装が、リクエストからクライアント証明書を抽出し、AuthleteのAPIにclientCertificateリクエストパラメーターとして渡す必要があります。/api/auth/tokenAPI（トークンエンドポイント実装が呼び出すAPI）および/api/auth/introspectionAPI（Web API実装が呼び出すAPI）には、clientCertificateリクエストパラメーターが含まれています。
このサービスがOAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokensで定義されたクライアント証明書にバインドされたアクセストークンをサポートするかどうかを制御する設定項目です。Enableが選択されている場合、Authleteの/api/service/configurationAPIを使用して実装されたディスカバリーエンドポイントには"tls_client_certificate_bound_access_tokens":trueが含まれます。
この機能が有効な場合、トークンリクエストで使用されたクライアント証明書が、発行されたアクセストークンと関連付けられます。クライアントアプリケーションがそのアクセストークンを使用してWeb APIにアクセスする場合、トークンリクエストで使用されたのと同じクライアント証明書を使用する必要があります。そうでない場合、アクセスは拒否されます。
アクセストークンがクライアント証明書と関連付けられることで、アクセストークンが漏洩した場合でも、そのアクセストークンを悪用することが困難になります。漏洩したアクセストークンを使用してWeb APIにアクセスするには、アクセストークン発行時に使用されたクライアント証明書も必要になるためです。
この機能を使用するには、トークンエンドポイントおよびWeb APIの実装が、リクエストからクライアント証明書を抽出し、AuthleteのAPIにclientCertificateリクエストパラメーターとして渡す必要があります。/api/auth/tokenAPI（トークンエンドポイント実装が呼び出すAPI）および/api/auth/introspectionAPI（Web API実装が呼び出すAPI）には、clientCertificateリクエストパラメーターが含まれています。
サブジェクト（エンドユーザー識別子）とクライアントアプリケーションの組み合わせごとに、最大1つのアクセストークンのみを許可するか、複数のアクセストークンを発行できるかを制御する設定項目。
このスイッチが有効な場合、新しいアクセストークンを発行する試みは、同じサブジェクトおよびクライアントの組み合わせに関連付けられた既存のアクセストークンを無効化します。
ただし、クライアント資格情報フローによる試みは既存のアクセストークンを無効化しません。このフローで発行されるアクセストークンは、エンドユーザーのサブジェクトと関連付けられていないためです。
また、リフレッシュトークンフローによる試みは、リフレッシュトークンに紐づけられたアクセストークンのみを無効化します。この無効化は、この設定項目の値に関係なく常に実行されます。
アクセストークンの署名に使用されるアルゴリズム。このプロパティが設定されている場合、このサービスが発行するアクセストークンはJWTとなります。設定されていない場合、このサービスが発行するアクセストークンはランダムな文字列となります。
アクセストークンの署名に使用されるJWK（JSON Web Key）を識別するためのキーID（このプロパティはJWTベースのアクセストークンが生成される場合にのみ使用されます）。
適用可能なJWKが1つだけであれば問題はありません。ただし、複数の候補がある場合、Authleteサーバーが正しいJWKを選択するためにキーIDを指定する必要があります。
この設定に値が設定されている場合、それはキーIDとして解釈されます。AuthleteサーバーはこのキーIDを使用して、アクセストークンの署名に使用するJWKを選択します。
複数の候補JWKが存在し、この設定が空の場合でも、Authleteサーバーは最善を尽くして1つを選択します。ただし、複数の候補JWKがあり、そのいずれにもキーIDが設定されていない場合など、Authleteサーバーが選択できない場合があります。そのような場合、アクセストークンの生成に失敗する可能性があります。
リフレッシュトークンの有効期間（秒単位）。
「スコープ属性」を使用してリフレッシュトークンの有効期間を制御するメカニズムがあります。詳細はスコープに関する説明を参照してください。
このフラグは、リフレッシュトークンが使用された場合に、その有効期間をリセットするかどうかを示します。ただし、トークンローテーションが有効な場合、この設定は影響を及ぼしません。
リフレッシュトークンが使用された後も有効であるか、それを無効化して新しいトークンを発行するかを制御する設定項目。
リフレッシュトークンが使用後も有効で、新しいトークンが発行されない場合、リフレッシュトークンは最終的に期限切れになります。その時点で、再度認可プロセスが必要になります。
一方、リフレッシュトークンが使用された際に無効化され、新しいトークンが発行される場合、リフレッシュトークンが期限切れになる前に新しいアクセストークンを取得し続ける限り、再度認可プロセスを行う必要はありません。
このスイッチがオンの場合、同じリフレッシュトークンを使用したリフレッシュトークンリクエストを短期間に複数回行うことができ、それらは同じ更新済みリフレッシュトークンを取得します。
スイッチがオフの場合、リフレッシュトークンリクエストごとに異なる更新済みリフレッシュトークンが発行されます。
このスイッチがオンの場合、使用されたリフレッシュトークンの残りの有効期間が、新しく発行されたトークンに引き継がれます。この設定は、トークンローテーションが有効な場合には影響を及ぼしません。
このスイッチがオンの場合、アクセストークンの有効期限が対応するリフレッシュトークンの有効期限を超えないようにします。他の設定に基づいて計算された期間に関係なく、リフレッシュトークンの有効期限を上限として適用します。
IDトークンの有効期間（秒単位）。この設定項目に設定された値は、IDトークンのexpクレームの値を計算するために使用されます。
このサービスとクライアント間の時計のずれを許容する秒数を指定します。この値は、JWTの時間関連クレーム（例: exp, iat, nbf）を検証する際に考慮されます。
リフレッシュトークンフローでIDトークン再発行機能を有効にするかどうかを制御するスイッチ。
スイッチがオンの場合、次の条件をすべて満たす場合に、/auth/tokenAPIの応答でactionパラメーターがID_TOKEN_REISSUABLEになります:
openidスコープが含まれている。ID_TOKEN_REISSUABLEを受け取った場合、トークンエンドポイントの実装は次のいずれかのアクションを取ることができます:
OKアクションと同じ手順を実行します。この場合、トークンエンドポイントは以前と同じ動作をし、IDトークンは再発行されません。/idtoken/reissueAPIを呼び出してIDトークンを再発行し、APIが新しいIDトークンとともに新しいアクセストークンおよびリフレッシュトークンを含むトークン応答を準備します。詳細についてはTokenResponseクラスのJavaDocを参照してください。
この設定により、IDトークン内のaudクレームのタイプを選択できます。以下のオプションがあります:
audクレームの形式はこれまで通りです。後方互換性が重要な場合、このオプションを選択してください。標準仕様の例ではaudクレームの形式が一貫していないため、Authleteの実装も一貫していません。たとえば、認可コードフローで発行されるIDトークンのaudクレームは配列ですが、CIBAフローで発行されるIDトークンのaudクレームは文字列です。audクレームのタイプは常に配列になります。JWT仕様(RFC 7519)の観点から見ると、この動作が一般的なケースです。セクション4.1.3では次のように記載されています:
一般的な場合、
aud値は大小区別される文字列の配列であり、それぞれがStringOrURI値を含みます。特別な場合にJWTが1つのオーディエンスを持つ場合、aud値は1つの大小区別される文字列でStringOrURI値を含むことができます。
audクレームのタイプは常に文字列になります。AuthleteのいくつかのAPI（例: /auth/authorization/issue）には、idTokenAudTypeリクエストパラメーターがあります。このリクエストパラメーターが指定され、その値がarrayまたはstringのいずれかである場合、このサービスプロパティ（Service.idTokenAudType）よりも優先されます。
このサービスがサポートするクレームのリスト。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるclaims_supportedプロパティの値として使用されます。
ここで「サポートされている」とは、このサービスがクレームの値を直接または間接的に提供できることを意味します。
サービス作成時には、OpenID Connect Core 1.0, 5.1. 標準クレームで定義されている20個の標準クレームが初期値として設定されています。
認可リクエストによってリクエストされたクレームの名前は、Authleteの/api/auth/authorizationAPIの応答でclaimsプロパティの値として含まれます。ただし、この設定項目にリストされていないクレームは、claimsに含まれることはありません。たとえば、認可リクエストのscopeパラメーターにemailやphoneが含まれていても（これらはemail_verifiedやphone_number_verifiedに展開されます）、この設定項目にemail_verifiedやphone_number_verifiedがリストされていない場合、それらはclaimsプロパティに現れません。
このサービスが認可ページでサポートするクレーム値の言語のリスト。技術的には、RFC 5646で定義された言語タグのリストであり、認可エンドポイントがclaims_localesパラメーターの値として認識します（OpenID Connect Core 1.0, 3.1.2.1. Authentication Requestを参照）。このサービスがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるclaims_locales_supportedプロパティの値として使用されます。
クライアントアプリケーションは、claims_localesリクエストパラメーターを使用してIDトークン内に埋め込まれるクレーム値の言語を指定することができます。たとえば、claims_locales=jaを認可リクエストに含めることで、クライアントアプリケーションはfamily_nameクレームの値を日本語で提供するようリクエストできます。詳細については、OpenID Connect Core 1.0, 5.2. Claims Languages and Scriptsを参照してください。
ただし、認可サーバーがこのリクエストパラメーターを尊重してクレームの言語を変更することが保証されているわけではありません。認可サーバーがclaims_localesパラメーターを完全に無視しても、これは仕様違反ではありません。
認可リクエストに含まれるclaims_localesパラメーターの値は、Authleteの/api/auth/authorizationAPIの応答でclaimsLocalesプロパティの値として返されます。ただし、この設定項目にリストされていない言語はclaimsLocalesに含まれません。たとえば、claims_locales=jaが認可リクエストに含まれていても、この設定項目にjaがリストされていない場合、claimsLocalesプロパティにjaは現れません。
このサービスがサポートするクレームタイプ。このサービスがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれるclaim_types_supportedプロパティの値として使用されます。
詳細については、OpenID Connect Core 1.0, 5.6. クレームタイプを参照してください。
注意: サービスでAGGREGATEDおよびDISTRIBUTEDをサポートする場合、5.6.2. 集約クレームと分散クレームに記載された形式で情報をフォーマットし、Authleteの/api/auth/authorization/issueAPIに渡す必要があります。Authlete自体はAGGREGATEDおよびDISTRIBUTEDを直接サポートしていません。
スイッチがオンの場合、ショートカットスコープ（例: profile）で指定されたクレームは、アクセストークンが発行されない場合にのみIDトークンに含まれます（response_typeがid_tokenの場合のみ）。スイッチがオフの場合、アクセストークンが発行されているかどうかに関係なく、クレームは常にIDトークンに含まれます。
OpenID Connect Core 1.0, 5.4の記述に厳密に従うには、スイッチをオンにしてください。Authlete 2.1以前のバージョンとの後方互換性が重要な場合は、スイッチをオフのままにしてください。
このサービスがサポートする信頼フレームワーク。OpenID Connect for Identity Assurance 1.0の11.1. 信頼フレームワークにリストされている事前定義値は次の通りです:
de_amleidas_ial_substantialeidas_ial_highnist_800_63A_ial_2nist_800_63A_ial_3jp_amljp_mpiupaここにリストされた信頼フレームワークは、ディスカバリードキュメントのtrust_frameworks_supportedメタデータの値として使用されます。詳細は7. OP Metadataを参照してください。
このサービスがサポートするID証拠のタイプ。OpenID Connect for Identity Assurance 1.0の4.1.1. 証拠にリストされている事前定義値は次の通りです:
id_documentutility_billqesここにリストされたID証拠は、ディスカバリードキュメントのevidence_supportedメタデータの値として使用されます。詳細は7. OP Metadataを参照してください。
このサービスがサポートする身分証明書の種類。OpenID Connect for Identity Assurance 1.0の11.2. Identity Documentsにリストされている事前定義値は次の通りです:
idcardpassportdriving_permitde_idcard_foreignersjp_drivers_licensejp_health_insurance_cardjp_residency_cardここにリストされたIDドキュメントタイプは、ディスカバリードキュメントのid_documents_supportedメタデータの値として使用されます。詳細は7. OP Metadataを参照してください。
このサービスがサポートするIDドキュメントの検証方法。OpenID Connect for Identity Assurance 1.0の11.3. 検証方法にリストされている事前定義値は次の通りです:
pippsrippeidurippここにリストされた検証方法は、ディスカバリードキュメントのid_documents_verification_methods_supportedメタデータの値として使用されます。詳細は7. OP Metadataを参照してください。
このサービスがサポートする検証済みクレームの名前。例としては、given_nameやfamily_nameなどがあります。OpenID Connect for Identity Assurance 1.0の3.1. ユーザーに関する追加クレームや4.2. claims要素を参照してください。
ここにリストされたクレーム名は、ディスカバリードキュメントのclaims_in_verified_claims_supportedメタデータの値として使用されます。詳細は7. OP Metadataを参照してください。
事前定義された変換クレーム。フォーマットはJSONです。このプロパティは、transformed_claims_predefinedサーバーメタデータに対応しています。このメタデータは「OpenID Connect Advanced Syntax for Claims (ASC) 1.0」で定義されています。
このサービスがサポートするドキュメントタイプ。このプロパティは、OpenID Connect for Identity Assurance 1.0の第3ドラフトで追加されたdocuments_supportedサーバーメタデータに対応しています。事前定義された値の例としては、idcardやpassportがあります。完全な事前定義値のリストについては、eKYC-IDA WGが管理するidentifiersページを参照してください。
(TBD)
(TBD)
このサービスがサポートする添付ファイルタイプ。このチェックボックスは、embeddedおよびexternalに対応しています。これらは、OpenID Connect for Identity Assurance 1.0の第3ドラフトで追加されたattachments_supportedサーバーメタデータの事前定義値です。
外部添付ファイルのダイジェスト値を計算するために使用できるサポートされるアルゴリズム。このプロパティは、OpenID Connect for Identity Assurance 1.0の第3ドラフトで追加されたdigest_algorithms_supportedサーバーメタデータに対応しています。
可能な値は、IANA（Internet Assigned Numbers Authority）のHash Algorithm Registryにリストされています。認可サーバーが外部添付をサポートしている場合、このプロパティには少なくともsha-256が含まれている必要があります。
クライアントアプリケーションは、digestAlgorithmプロパティ（digest_algorithmクライアントメタデータに対応）を設定することでダイジェストアルゴリズムを指定できます。クライアントプロパティが設定されていない場合、サービスはデフォルトとしてsha-256を使用します。
トークンを自動的に埋め込むが選択されている場合、Authleteは外部添付ファイル用のアクセストークンを生成し、それをIDトークンおよびユーザー情報応答に埋め込みます。
Authleteの/auth/authorization/issueおよび/auth/userinfo/issueAPIのclaimsリクエストパラメーターには、verified_claims（OpenID Connect for Identity Assurance 1.0で定義）が含まれている場合があります。このverified_claimsには、attachmentsというJSON配列が含まれ、その中にJSONオブジェクトが複数含まれることがあります。このattachments配列の各要素は、埋め込み添付ファイルまたは外部添付ファイルを表します。外部添付ファイルを表すJSONオブジェクトには、そのコンテンツの場所を示すurlプロパティが含まれ、オプションでそのURLにアクセスする際に使用するアクセストークンを示すaccess_tokenプロパティを含む場合があります。
トークンを自動的に埋め込むが選択されている場合、Authleteはaccess_tokenプロパティが含まれていない外部添付ファイルを表すJSONオブジェクトを検出した際にアクセストークンを生成し、それをJSONオブジェクトのaccess_tokenプロパティに埋め込みます。この場合、Authleteはexpires_inプロパティも埋め込みます。
詳細についてはOpenID Connect for Identity Assurance 1.0を参照してください。
verified_claimsの内容を検証するために使用される検証スキーマセットの選択肢。
バージョン2.3以降、Authleteは、仕様（OpenID Connect for Identity Assurance 1.0）に付属するJSONスキーマファイルに基づいてverified_claimsの内容を検証します。これらのファイルは、仕様のGitリポジトリの/schema/フォルダにあります。
通常、Authleteは仕様に準拠した正当なJSONスキーマファイルを使用します。ただし、このプロパティ（Service.verifiedClaimsValidationSchemaSet）を通じて検証スキーマセットの名前を指定することで、Authleteが異なるJSONスキーマファイルセットを使用するように設定することが可能です。
Authleteは次の検証スキーマセット名を認識します:
'standard'と同じ。'standard': 正当なJSONスキーマファイルのセット。'standard+id_document': ほとんど標準に準拠しているが、追加で'id_document'を有効な証拠名として受け入れるカスタマイズされたJSONスキーマファイルのセット。このセットは後方互換性のためのものです。なお、'id_document'は実装ドラフト4で廃止されました（参考: eKYC-IDA PR 152）。リクエストにscopeパラメーターが含まれていない場合（または与えられたスコープがすべて無効である場合）、かつサービスの事前定義デフォルトスコープセットが空である場合、認可サーバーはそのリクエストをスコープなしリクエストとみなします。このスイッチが拒否するに設定されている場合、そのようなリクエストは拒否されます。
RFC 6749セクション3.3の最後の段落は、デフォルトスコープセットが空の場合について明示的に言及していません。しかし、状態を「デフォルトスコープセットが存在するが空である」と解釈し、RFC 6749セクション3.3の要件に厳密に準拠したい場合、このスイッチを拒否するに設定してください。
拒否するスイッチがオンの場合、認可サーバーが発行するすべてのアクセストークンには少なくとも1つのスコープが含まれることが保証されます。ただし、/api/auth/token/createAPIを使用してスコープなしのアクセストークンを作成する場合は例外です。
Authlete 2.1以前のバージョンとの後方互換性が重要な場合、このスイッチをオフに設定してください。
このサービスが認識するスコープのリスト。それぞれのスコープ名は、印刷可能なASCII文字のみで構成され、スペース、二重引用符、バックスラッシュを含まない必要があります（RFC 6749, 33.3. Access Token Scopeを参照）。さらに、各スコープ名の長さは200文字を超えてはなりません。
OpenID Connectは、いくつかの標準スコープ名を定義しています。openidは最も重要なスコープです。認可エンドポイントへのリクエストにこのスコープが含まれていない場合、そのリクエストはOpenID Connectリクエストとしてみなされません（3.1.2.1. Authentication Requestを参照）。profile、email、address、およびphoneは、IDトークンに特定のクレームを含めるために使用できるスコープです（5.4. Requesting Claims using Scope Valuesを参照）。offline_accessは、OAuth 2.0リフレッシュトークンの発行をリクエストするためのスコープであり、このトークンを使用して、エンドユーザーがログインしていない（非ログイン）状態でもユーザー情報エンドポイントにアクセスできます（11. Offline Accessを参照）。
認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値は、エンドポイントからの応答に含まれる"scopes_supported"プロパティの値として使用されます。
ここにリストされている値は、認可リクエストの"scope"パラメーターの有効な値として認識されます。Authleteは、ここにリストされていない未知のスコープを無視します（これらが"scope"パラメーターに含まれていてもエラーにはなりません）。これは、OpenID Connect Core 1.0, 3.1.2.1. 認証リクエストで次のように述べられているためです:
“実装によって理解されないスコープ値は無視されるべきです（SHOULD）。”
注意: openidをリストしない場合、このサービスはOpenID Connectの機能を提供しなくなります。
各スコープには、名前、デフォルトエントリ（ブール値）、説明、属性といった設定項目があります。
"scope"パラメーターの値として使用される文字列。使用可能な文字は印刷可能なASCII文字で、スペース、二重引用符、バックスラッシュを含まない必要があります。"scope"パラメーターが認可リクエストに含まれていない場合に参照されるブールフラグ。"scope"パラメーターが欠如している場合、デフォルトエントリがtrueのスコープが、"scope"パラメーターに指定されていたかのように使用されます。openid、profile、email、address、phone、offline_access）の説明は変更できません。スコープ属性の中には、Authleteによって特別な方法で解釈されるものがあります。
| 属性名 | 属性値 | 説明 |
|---|---|---|
| fapi | r | 「金融グレードAPI リードオンリー」を意味します。この属性を持つスコープを含む認可リクエストは、リードオンリーAPI用のアクセストークンを要求するものと見なされます。その結果、Authleteは、Financial-grade API - Part 1: Read-Only API Security Profileで課された制約を満たしているかどうかを確認します。 |
| fapi | rw | 「金融グレードAPI リード・ライト」を意味します。この属性を持つスコープを含む認可リクエストは、リード・ライトAPI用のアクセストークンを要求するものと見なされます。その結果、Authleteは、Financial-grade API - Part 2: Read and Write API Security Profileで課された制約を満たしているかどうかを確認します。 |
サービス作成時には、OpenID Connect Core 1.0で定義されている標準スコープが初期値として設定されています。
| スコープ名 | 説明 |
|---|---|
| openid | 最も重要なスコープ。このスコープが含まれていない認可リクエストは、OpenID Connectリクエストとしてみなされません。 |
| profile | IDトークンにユーザーのプロファイル（“name"など）に関するクレームを含めるスコープ。 |
| IDトークンにメール関連のクレーム（“email"および"email_verified”）を含めるスコープ。 | |
| address | IDトークンに住所関連のクレーム（“address”）を含めるスコープ。 |
| phone | IDトークンに電話関連のクレーム（“phone_number"および"phone_number_verified”）を含めるスコープ。 |
| offline_access | ユーザー情報エンドポイントにログイン状態でなくてもアクセスできるようにするリフレッシュトークンを要求するスコープ。 |
スコープの粒度に関する固定ルールはなく、サービスのニーズに依存します。
細かく分けたスコープを管理するのが困難な場合、代わりにアクセストークンに追加メタデータを添付することを検討してください。Authleteでは、アクセストークンに任意のキーと値のペアを添付することが可能で、スコープ管理を簡素化します。詳細についてはExtra Propertiesを参照してください。
このスイッチがオンの場合、AuthleteはDPoP証明トークンにnonceが含まれていることを要求します。nonceが欠如している場合、Authleteサーバーはuse_dpop_nonceエラーを返し、クライアントは前回のリクエストをnonceクレームを含めて再送信する必要があります。nonceは、Authleteサーバーからのトークン応答ヘッダー内のHTTP DPoP-Nonceに含まれる場合があります。それが含まれていない場合、クライアントは自らnonceを生成する必要があります。
この設定は、証明トークン内でdpop-nonce値を再利用できる期間を制御します。適切な検証を確保するために、トークン応答ヘッダーからdpop-nonce値を保存し、指定された期間ごとにそれを更新してください。
このスイッチがオンの場合、識別子がないクライアントからのトークン交換リクエストをこのサービスは拒否します。
RFC 8693 OAuth 2.0 Token Exchangeのセクション2.1では次のように述べられています: “クライアント認証のサポート方法、および認証されていないクライアントや識別されていないクライアントを許可するかどうかは、認可サーバーの裁量に任されています。”
技術的に、この文脈での “unidentified” は、トークン交換リクエストにリクエストを行ったクライアントの識別子が含まれていないことを意味します。
RFC 8693 A.1.1には、クライアント識別子を含まないトークン交換リクエストの例が示されていますが、識別できないクライアント（APIコーラー）がトークン交換リクエストを行うことを許可するのはリスクがあります。しかし、そのようなリクエストが必要なケースもあり、安全な運用が何らかの方法で確保できる場合、このオプションをオフにすることができます。
このスイッチがオンの場合、パブリッククライアントからのトークン交換リクエストをこのサービスは拒否します。
RFC 8693 OAuth 2.0 Token Exchangeのセクション2.1では次のように述べられています: “クライアント認証のサポート方法、および認証されていないクライアントや識別されていないクライアントを許可するかどうかは、認可サーバーの裁量に任されています。”
技術的に、この文脈での**“unauthenticated”**は、トークン交換リクエストを行うクライアントがパブリッククライアントであり、トークンエンドポイントでのクライアント認証が必要でないことを意味します。
機密クライアントとパブリッククライアントの両方からのトークン交換リクエストを受け付ける場合、このオプションをオフにしてください。
このスイッチがオンの場合、トークン交換の明示的な許可を持たないクライアントからのトークン交換リクエストをこのサービスは拒否します。
管理者は、クライアントアプリケーション管理のWebコンソールの「拡張」タブで「トークン交換の明示的許可」をチェックすることで、クライアントにトークン交換リクエストを行うための明示的な許可を与えることができます。
トークン交換の詳細については、RFC 8693 OAuth 2.0 Token Exchangeを参照してください。
このスイッチがオンの場合、トークンタイプurn:ietf:params:oauth:token-type:jwtまたはurn:ietf:params:oauth:token-type:id_tokenを使用して暗号化されたJWTが入力トークンとして使用されるトークン交換リクエストをこのサービスは拒否します。
このチェックボックスがチェックされていない場合、Authleteは入力トークンが暗号化されたJWTであると検出したときに、残りの検証ステップをスキップします。この場合、認可サーバーの実装は、暗号化されたJWTを独自に検証する必要があります。
Authleteが実行するトークン交換プロセスの詳細については、RFC 8693 OAuth 2.0 Token Exchangeを参照してください。
このスイッチがオンの場合、トークンタイプurn:ietf:params:oauth:token-type:jwtまたはurn:ietf:params:oauth:token-type:id_tokenを使用して署名されていないJWTが入力トークンとして使用されるトークン交換リクエストをこのサービスは拒否します。
このチェックボックスがチェックされていない場合、Authleteは入力トークンが署名されていないJWTであると検出したときに、残りの検証ステップをスキップします。
トークン交換プロセスの詳細については、RFC 8693 OAuth 2.0 Token Exchangeを参照してください。
このサービスのJWKセットドキュメントの内容。
認可サーバーが、IDトークン、ユーザー情報エンドポイントの応答、および認可応答（JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)）の署名や、リクエストオブジェクトの暗号化に非対称アルゴリズムをサポートする場合、JWKセットを登録する必要があります。このJWKセットには、認可サーバーがサポートするアルゴリズムの公開鍵と秘密鍵のペアを含める必要があります。
署名（JWS）のアルゴリズムとして使用できるものは、JWA（RFC 7518）のセクション3.1にリストされています。この中で、名前が"RS”、“PS”、または"ES"で始まるアルゴリズムが非対称アルゴリズムです。
暗号化（JWE）のアルゴリズムとして使用できるものは、JWA（RFC 7518）のセクション4.1にリストされています。この中で、名前が"RSA"または"ECDH"で始まるアルゴリズムが非対称アルゴリズムです。
参考までに、mkjwk.orgというオンラインサービスでは、JWKやJWKセットを生成することができます。JWKに慣れていない場合は試してみてください。
このサービスのJWKセットドキュメントのURL。認可サーバーがAuthleteの/api/service/configurationAPIを使用してディスカバリーエンドポイントを実装する場合、この設定項目の値はエンドポイントからの応答に含まれる"jwks_uri"プロパティの値として使用されます。
“JWKセットの内容"設定項目が空の場合、Authleteは必要に応じてここで指定されたURIからJWKセットを取得しようとします。ただし、Authleteは非対称アルゴリズムの秘密鍵のために外部JWKセットを取得しようとはしません。そのため、非対称アルゴリズムの秘密鍵を使用するプロセス（例: 非対称アルゴリズムを使用したIDトークンの署名）には、これらの秘密鍵が"JWKセットの内容"に登録されている必要があります。
認可サーバーが、IDトークン、ユーザー情報エンドポイントの応答、および認可応答（JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)）の署名や、リクエストオブジェクトの暗号化に非対称アルゴリズムをサポートする場合、JWKセットエンドポイントを実装する必要があります（JWKセットがクライアントアプリケーション開発者にオフラインで配布されない限り）。
Authleteの/api/service/jwks/getAPIは、顧客が独自のJWKセットエンドポイントを実装するのを支援するために利用できます。
IDトークンの署名に使用されるJWKを識別するためのキーID。
IDトークン署名のアルゴリズムが非対称（例: RS256）の場合、登録済みのJWKセットからアルゴリズムの秘密鍵を表すJWKを選択する必要があります。適用可能なJWKが1つしかない場合は問題ありませんが、複数の候補がある場合、キーIDを指定してAuthleteサーバーが正しいJWKを選択できるようにする必要があります。
このプロパティが設定されていない場合でも、Authleteサーバーは最善を尽くして1つのJWKを選択します。ただし、複数の候補JWKがあり、どれもキーIDを持たない場合など、AuthleteサーバーがJWKを選択できない場合もあります。そのような場合、IDトークンの生成に失敗する可能性があります。
ユーザー情報エンドポイントの応答の署名に使用されるJWKを識別するためのキーID。
ユーザー情報エンドポイントの応答の署名アルゴリズムが非対称（例: RS256）の場合、登録済みのJWKセットからアルゴリズムの秘密鍵を表すJWKを選択する必要があります。適用可能なJWKが1つしかない場合は問題ありませんが、複数の候補がある場合、キーIDを指定してAuthleteサーバーが正しいJWKを選択できるようにする必要があります。
このプロパティが設定されていない場合でも、Authleteサーバーは最善を尽くして1つのJWKを選択します。ただし、複数の候補JWKがあり、どれもキーIDを持たない場合など、AuthleteサーバーがJWKを選択できない場合もあります。そのような場合、ユーザー情報エンドポイントの応答の生成に失敗する可能性があります。
認可応答（JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)）の署名に使用されるJWKを識別するためのキーID。
認可応答の署名アルゴリズムが非対称（例: RS256）の場合、登録済みのJWKセットからアルゴリズムの秘密鍵を表すJWKを選択する必要があります。適用可能なJWKが1つしかない場合は問題ありませんが、複数の候補がある場合、キーIDを指定してAuthleteサーバーが正しいJWKを選択できるようにする必要があります。
このプロパティが設定されていない場合でも、Authleteサーバーは最善を尽くして1つのJWKを選択します。ただし、複数の候補JWKがあり、どれもキーIDを持たない場合など、AuthleteサーバーがJWKを選択できない場合もあります。そのような場合、認可応答のJWT生成に失敗し、RFC 6749で定義された形式のエラーレスポンスが返される可能性があります。
このサービスが署名する（1）自己署名エンティティステートメントおよび（2）このサービスのJWKセットをJWT形式で返すエンドポイントからの応答（signed_jwks_uriサーバーメタデータで指定されたURI）に使用される秘密鍵を含むJWKセット。
このプロパティが空の場合、このサービスは有効な自己署名エンティティステートメントを生成できません。そのため、OpenID Connect Federation 1.0を機能させるには、このプロパティを適切に設定する必要があります。
このJWKセットは、通常のOpenID Connect操作（例: IDトークンの署名）に使用されるものとは異なります。
このサービスのJWKセットをJWT形式で返すエンドポイントのURI。このプロパティは、OpenID Connect Federation 1.0で定義されているsigned_jwks_uriサーバーメタデータに対応します。
エンドポイントから返されるJWTは、フェデレーションJWKセットフィールドで指定されたJWKセット内の秘密鍵で署名されます。そのため、このフィールドが適切に設定されていない場合、エンドポイントは有効な応答を返すことができません。
エンティティ構成および署名済みJWKセットの署名に使用されるJWKを識別するためのキーID。
エンティティ構成はJWTの一種であり、/.well-known/openid-federationまたは/.well-known/openid-federation{path_part_of_issuer}のようなバリエーションの場所で公開されます。
署名済みJWKセットもJWTの一種であり、signed_jwks_uriサーバーメタデータで指定されたURLで公開されます。
このプロパティが指定されている場合、Authleteは指定されたキーIDを持つJWKを使用してエンティティ構成および署名済みJWKセットを署名します。このプロパティが省略された場合、AuthleteがどのJWKを選択するかについて保証はありません。
検証可能なクレデンシャルに署名するために使用される秘密鍵を含む JWK セットドキュメント。
/vci/single/issue や /vci/batch/issue などの一部の Authlete API は、1つまたは複数の検証可能なクレデンシャルを発行することがあります。このプロパティの内容は、これらの API によって利用されます。
検証可能なクレデンシャルを発行する Authlete API は、署名に使用する秘密鍵のキー ID を指定できるリクエストパラメーターを認識します。例えば、/vci/single/issue API へのリクエストには、signingKeyId パラメーターを含む order オブジェクトがあり、署名に使用する秘密鍵のキー ID を指定できます。キー ID が指定されていない場合、Authlete は自動的に秘密鍵を選択します。
この credentialJwks プロパティが更新された際に、JWK セット内の JWK に kid プロパティが含まれていない場合（RFC 7517, Section 4.5）、Authlete は自動的に JWK に kid プロパティを挿入します。kid プロパティの値には、SHA-256 ハッシュアルゴリズムを使用して計算された JWK サムプリント（RFC 7638）が使用されます。
クレデンシャル発行者の JWK セットドキュメントが公開される URL。
この URL は JWT 発行者メタデータの jwks_uri プロパティの値として使用されます。このメタデータは /.well-known/jwt-issuer に公開されます。JWT 発行者メタデータの詳細については、SD-JWT ベースの検証可能なクレデンシャル（SD-JWT VC）仕様を参照してください。
HSM（ハードウェアセキュリティモジュール）のサポートを有効にするオプション。このオプションが無効な場合、HSMで管理されているキーは使用されず、/api/hsk/*APIはすべてのリクエストを拒否します。このオプションが有効でも、使用しているAuthleteサーバーの設定がHSMをサポートしていない場合、HSM関連の機能は動作しません。
注: この機能はDedicated Cloudでのみサポートされています。
HSM機能が有効でアクティブな場合に、ハードウェアセキュリティキーの詳細を表示します。
注: この機能はDedicated Cloudでのみサポートされています。
このサービスによって提供されるデータの利用方法を説明するドキュメントの URL。認可サーバーが Authlete の /api/service/configuration API を使用してディスカバリエンドポイントを実装している場合、この構成項目の値はエンドポイントからのレスポンスに含まれる “op_policy_uri” プロパティの値として使用されます。
クライアントアプリケーション開発者向けのこのサービスの利用規約の URL。認可サーバーが Authlete の /api/service/configuration API を使用してディスカバリエンドポイントを実装している場合、この構成項目の値はエンドポイントからのレスポンスに含まれる “op_tos_uri” プロパティの値として使用されます。
開発者向けのこのサービスに関するドキュメントの URL。認可サーバーが Authlete の /api/service/configuration API を使用してディスカバリエンドポイントを実装している場合、この構成項目の値はエンドポイントからのレスポンスに含まれる “service_documentation” プロパティの値として使用されます。
検証可能な資格情報に関連する機能が有効かを制御するフラグ。このフラグは、OID4VCI仕様のサポートを含みます。
資格情報オファーが有効である期間（秒単位）。ウォレットが資格情報提供リクエストで期間を指定しない場合、または0以下（<= 0）の期間を指定する場合、このデフォルト値が適用されます。
トランザクションIDが有効である期間（秒単位）。これは、資格情報リクエストまたはバッチ資格情報リクエストの結果として発行されるトランザクションIDに適用されます。このプロパティが0または負の値に設定されている場合、Authleteサーバーで設定されたデフォルト期間が適用されます。
検証可能な資格情報が有効である期間（秒単位）。この期間は、/vci/single/issueおよび/vci/batch/issueAPIなど、AuthleteのAPIによって発行される資格情報に適用されます。
値が0の場合、検証可能な資格情報は期限切れになりません。この場合、資格情報には有効期限プロパティが含まれません。たとえば、JWTベースの検証可能な資格情報にはexpクレームが含まれません（RFC 7519, Section 4.1.4を参照）。
Authleteの資格情報発行APIは、このデフォルト期間を上書きできるリクエストパラメーターもサポートしています。たとえば、/vci/single/issueAPIへのリクエストには、異なる期間を指定できるcredentialDurationパラメーターが含まれています。
識別不能なクライアントアプリケーションによる事前承認コードフローを使用したトークンリクエストを許可するかどうかを示します。
このプロパティは、OID4VCI仕様で定義されたpre-authorized_grant_anonymous_access_supportedメタデータに対応します。
資格情報ノンス（c_nonce）が有効である期間（秒単位）。
認可サーバーのトークンエンドポイントが検証可能な資格情報発行用のアクセストークンを発行する際、c_nonceもアクセストークンとともに発行されます。また、資格情報エンドポイントやバッチ資格情報エンドポイントが期限切れのc_nonceを受け取った場合、新しいc_nonceを発行します。このプロパティはこれらのc_nonceの有効期間を決定します。
このプロパティが0または負の値に設定されている場合、Authleteサーバーで設定されたデフォルト期間が適用されます。
このサービスが資格情報発行者として機能する場合、資格情報発行者が認可に依存する認可サーバーの識別子。このプロパティは、authorization-serversで定義されたauthorization_serversメタデータに対応します。
値はHTTPアクセス可能なURLである必要があります。
資格情報またはバッチ資格情報応答をJWTでエンコードするために、資格情報エンドポイントおよびバッチ資格情報エンドポイントがサポートするJWE暗号化アルゴリズム（RFC 7516）のリスト。これらのアルゴリズムは通常、コンテンツ暗号化キー（CEK）を暗号化するために使用されます。
資格情報応答をJWT（RFC 7519）でエンコードするために、資格情報エンドポイントがサポートするJWE暗号化アルゴリズム（RFC 7516）のリスト。これらのアルゴリズムは通常、コンテンツを暗号化するために使用されます。
必須にするが選択されている場合、資格情報発行者はすべての資格情報応答にTLS以外の追加暗号化を要求します。この場合、ウォレットは資格情報リクエストで暗号化キーを提供する必要があります。必須にするがオフの場合、ウォレットは暗号化キーを提供するかどうかを選択できます。
このサービスが資格情報発行者として機能する場合の資格情報発行者の識別子。このプロパティは、OID4VCI specificationで定義されたcredential_issuerメタデータに対応します。
値はhttpsスキームの有効なURLでなければならず、クエリ部分またはフラグメント部分を含んではなりません。また、Authleteはこの値をASCII文字のみ、最大200文字に制限します。
このプロパティは、認可サーバーが資格情報発行者として機能するために設定する必要があります。
このサービスが資格情報発行者として機能する場合の資格情報エンドポイントのURL。このプロパティは、OID4VCI仕様で定義されたcredential_endpointメタデータに対応します。
値はhttpsスキームの有効なURLでなければならず、フラグメント部分を含んではなりません。また、Authleteはこの値をASCII文字のみ、最大200文字に制限します。
このプロパティは、サービスが資格情報発行者として機能するために設定する必要があります。
このサービスが資格情報発行者として機能する場合のバッチ資格情報エンドポイントのURL。このプロパティは、OID4VCI仕様で定義されたbatch_credential_endpointメタデータに対応します。
値はhttpsスキームの有効なURLでなければならず、フラグメント部分を含んではなりません。また、Authleteはこの値をASCII文字のみ、最大200文字に制限します。
バッチ資格情報エンドポイントの実装は任意です。
このサービスが資格情報発行者として機能する場合の遅延資格情報エンドポイントのURL。このプロパティは、OID4VCI仕様で定義されたdeferred_credential_endpointメタデータに対応します。
値はhttpsスキームの有効なURLでなければならず、フラグメント部分を含んではなりません。また、Authleteはこの値をASCII文字のみ、最大200文字に制限します。
資格情報発行者の資格情報エンドポイントやバッチ資格情報エンドポイントがトランザクションIDを発行する場合、遅延資格情報エンドポイントを実装する必要があります。
このサービスが資格情報発行者として機能する場合、資格情報発行者がサポートする資格情報。このプロパティは、OID4VCI仕様で定義されたcredential_configurations_supportedメタデータに対応します。
値はJSONオブジェクトである必要があります。非ASCII文字を含むことができますが、Authleteはこの値を最大16,383文字に制限します。
このプロパティは、サービスが資格情報発行者として機能するために設定する必要があります。
後方互換性を維持するため、このプロパティの名前はcredentialsSupportedのままであり、credentialConfigurationsSupportedにはリネームされません。