Table of Contents
サービスオーナーコンソールを用いてサービスの設定をおこなうことができます。ここでは、各設定項目について説明します。
なお、Authlete 1.x 系の共用サーバー（api.authlete.com）用のサービスオーナーコンソール（so.authlete.com）には存在しない項目も含まれます。
サービスを識別するための名前です。サービスオーナーコンソールのサービス一覧表示や、デベロッパーコンソールのログイン画面などで用いられます。また、ダイレクト認可エンドポイントが表示する認可画面でも用いられます。
ダイレクト認可エンドポイントの商用利用は非推奨なので、デベロッパーコンソールを第三者に開放するという運用を行わない限り、ここで設定したサービス名が商用環境で用いられることはありません。
【重要】 サービスの技術的な識別子です。このサービスが発行する ID トークン に含まれる iss クレームの値として用いられます。また、このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイント（OpenID Connect Discovery 1.0, 4. Obtaining OpenID Provider Configuration Information ）を実装する場合、そのエンドポイントからの応答に含まれる issuer プロパティーの値として用いられます。
サービス作成時のデフォルト値は「https://authlete.com」となっていますが、商用利用時は必ず値を変更してください。https:// で始まり、クエリー部やフラグメント部を含まない URL としてください。
特に、ディスカバリーエンドポイントを公開する場合、そのエンドポイントは「{トークン発行者識別子}/.well-known/openid-configuration」という URL でアクセスできる必要があるので、トークン発行者識別子の値を決める際は注意してください。詳細は、OpenID Connect Discovery 1.0, 4. Obtaining OpenID Provider Configuration Information を参照してください。
サービスに関する説明です。ダイレクト認可エンドポイントの認可画面で用いられています。
ダイレクト認可エンドポイントの商用利用は非推奨なので、ここで設定した説明が商用環境で用いられることはなく、仕様上も設定しなくても問題はありません。
一人のクライアントアプリケーション開発者が登録できるアプリケーション数の上限です。デフォルト値は、無制限を意味する 0 となっています。
開発者認証コールバックエンドポイントを実装し、その情報をサービスに登録すると、デベロッパーコンソールに「サービス API キー & サービス API シークレット」以外のログイン ID & パスワードでログインすることができるようになります。このようにして、一つのサービスに対して複数のクライアントアプリケーション開発者を認めているとき、それぞれの開発者が最大いくつまでクライアントアプリを登録できるようにするのかを制御するのがこの設定項目です。
「不特定多数の外部開発者にクライアントアプリケーションを自由に登録させる」というサービスを構築しない限り、この設定項目について気にする必要はありません。
Authlete が割り当てた数値のクライアント ID に加えて、別の任意の文字列をクライアント ID として利用したい場合、この項目を有効にします。サービス側でこの設定項目を有効にしておかないと、デベロッパーコンソールに存在する同名の設定項目を有効にしても、Client ID 別名機能は動きません。
「既存のシステムを Authlete に移行するにあたり、既存のクライアント ID を引き続き利用したい」という要件があれば、この Client ID 別名機能を用いて実現することができます。そのような要件がない場合は、この機能を無効のままにしておいてかまいません。
ダイレクト認可エンドポイントが表示する認可画面内のユーザー認証や、ダイレクトトークンエンドポイントにおけるリソースオーナー・パスワード・クレデンシャルズフロー時のユーザー認証において、そのユーザー認証を委譲する先の情報を、「認証コールバックエンドポイント」、「認証コールバック API キー」、「認証コールバック API シークレット」に設定します。
認証コールバックエンドポイントはお客様が実装する Web API で、その要求仕様は、authlete-java-common ライブラリに含まれる AuthenticationCallbackRequest クラスと AuthenticationCallbackResponse クラスのJavaDoc に記載されています。
認証コールバック API キーと認証コールバック API シークレットは、もし設定されていれば、Authlete が認証コールバックエンドポイントを呼ぶ際に、Basic 認証のユーザー ID とパスワードとして用いられます。
ダイレクト系エンドポイント群の商用利用は非推奨ですので、商用環境ではユーザー認証コールバックに関する設定は不要です。
ダイレクト認可エンドポイントが表示する認可画面における、外部 SNS を用いたユーザー認証に関する設定項目です。
この機能は deprecated 扱いになっており、また、ダイレクト認可エンドポイントの商用利用が非推奨であることから、商用環境ではこの項目の設定は不要です。
認可エンドポイントにおけるユーザー認証でサポートする認証コンテキスト群です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる acr_values_supported プロパティーの値として用いられます。
クライアントアプリケーションは、認可サーバーが認可リクエストを処理する際に満たしてほしい認証コンテキストを指定することができます。具体的には、acr_values というリクエストパラメーター（OpenID Connect Core 1.0, 3.1.2.1. Authentication Request ）もしくは claims リクエストパラメーター内の acr クレーム（OpenID Connect Core 1.0, 5.5. Requesting Claims using the “claims” Request Parameter ）を用いたり、自身の default_acr_values メタデータ（OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata ）の値として事前に設定しておくなどして、認証コンテキストを指定します。
上記のような方法でクライアントアプリケーションが認証コンテキストを指定してきても、この設定項目に列挙されていない値は、Authlete 側で意図的にドロップされます。例えば、認可リクエストが「acr_values=my_acr」というリクエストパラメーターを含んでいたとしても、この設定項目に my_acr が含まれていなければ、Authlete の /api/auth/authorization API からの応答に含まれる acrs プロパティーに my_acr が含まれることはありません。
認可リクエストにより指定された認証コンテキストを尊重して適切な動作をおこなう認可サーバーを実装する予定がない場合、この設定項目は未設定のままでかまいません。
参考までに、英国オーブンバンキング では、認証コンテキストとして少なくとも urn:openbanking:psd2:sca と urn:openbaning:psd2:ca の二つを定義しています。
【参考】認証コンテキストクラス
デベロッパーコンソールにログインする際の開発者認証を委譲する先の情報を、「開発者認証コールバックエンドポイント」、「開発者認証コールバック API キー」、「開発者認証コールバック API シークレット」に設定します。
デベロッパーコンソールには「サービス API キー & サービス API シークレット」でログインできますが、それ以外のログイン ID & パスワードで開発者にログインさせたい場合、開発者認証コールバックに関する設定が必要となります。
開発者認証コールバックエンドポイントはお客様が実装する Web API で、その要求仕様は、authlete-java-common ライブラリに含まれる DeveloperAuthenticationCallbackRequest クラスと DeveloperAuthenticationCallbackResponse クラスのJavaDoc に記載されています。
開発者認証コールバック API キーと開発者認証コールバック API シークレットは、もし設定されていれば、Authlete が開発者認証コールバックエンドポイントを呼ぶ際に、Basic 認証のユーザー ID とパスワードとして用いられます。
デベロッパーコンソールのログイン画面における、外部 SNS を用いた開発者認証に関する設定項目です。
この機能は deprecated 扱いになっており、また、実装も完了していないので、実際には使用することはできません。
【重要】 認可サーバーがサポートする認可種別です。RFC 6749 で定義されているアクセストークン発行フローのどれをサポートするかを設定します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる grant_types_supported プロパティーの値として用いられます。
クライアントアプリケーションは、ここで有効になっているフローのみを用いることができます。無効になっているものは、使用してもエラーになります。
AUTHORIZATION_CODE は、認可エンドポイントで認可コードの発行を受け、それをトークンエンドポイントでアクセストークンと交換するフローです。詳細は RFC 6749, 4.1. Authorization Code Grant で定義されています。最も一般的なフローです。
IMPLICIT は、認可エンドポイントから直接アクセストークンの発行を受けるフローです。詳細は RFC 6749, 4.2. Implicit Grant で定義されています。Web ブラウザ内で動く JavaScript アプリケーションに直接アクセストークンを発行するなどの用途で用いられます。
PASSWORD は、トークンエンドポイントにユーザーの ID とパスワードを提示することでアクセストークンの発行を受けるフローです。詳細は RFC 6749, 4.3. Resource Owner Password Credentials Grant で定義されています。仕様書にも記載がある通り、このフローは何らかの理由で他のフローが利用できない場合のみ使用してください。明確な理由がなければ、商用環境では無効にしておいてください。
CLIENT_CREDENTIALS は、トークンエンドポイントにクライアントアプリケーションの ID とシークレットを提示することでアクセストークンの発行を受けるフローです。詳細は RFC 6749, 4.4. Client Credentials Grant で定義されています。このフローでは、どのユーザーにも紐付かないアクセストークンが発行されます。そのようなアクセストークンを発行したいという明確な理由がなければ、商用環境では無効にしておいてください。
REFRESH_TOKEN は、トークンエンドポイントでリフレッシュトークンを交換するフローです。詳細は RFC 6749, 6. Refreshing an Access Token で定義されています。この項目を無効にすると、リフレッシュトークンは発行されなくなります。
認可エンドポイントから発行するトークン群の組み合わせのうち、サポートするものを設定します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる response_types_supported プロパティーの値として用いられます。
RFC 6749 では、認可エンドポイントから発行されるトークンは、認可コードもしくはアクセストークンのどちらかでした。しかし、OAuth 2.0 Multiple Response Type Encoding Practices という追加仕様により、(a) 認可コード、(b) ID トークン、(c) アクセストークン、の任意の組み合わせで発行が可能となりました。また、何も発行しないという選択肢（none）も用意されました。
NONE 、CODE 、TOKEN 、ID_TOKEN はそれぞれ、認可リクエストの response_type パラメーターの値として単独で none、code、token、id_token を指定可能とすることを意味します。
CODE_TOKEN は、code token という組み合わせ（順不同）を response_type パラメーターの値とし指定できることを意味します。以下同様に、CODE_ID_TOKEN は code id_token、ID_TOKEN_TOKEN は id_token token、CODE_ID_TOKEN_TOKEN は code id_token token という組み合わせを指定できるようにすることを意味します。
クライアントアプリケーションは、ここで有効になっているものしか response_type リクエストパラメーターの値として利用できません。
none 以外は、明確な理由がなければ有効にしておいてください。なお、Financial-grade API （FAPI）の仕様では、更新系 API 用アクセストークンのための認可リクエストでは、response_type として code id_token もしくは code id_token token のどちらかを指定しなければならないと定められているので、CODE_ID_TOKEN と CODE_ID_TOKEN_TOKEN が両方とも無効になっている場合、FAPI 更新系 API 用の認可リクエストは必ず失敗することになってしまうので、注意してください。
【重要】 ベースとなる OAuth 2.0 および OpenID Connect に加え、追加でサポートする機能を指定します。これらの機能は、Authlete サーバー配備時に有効にされていないと、サービスオーナーコンソールで有効にしても有効にならないので注意してください。詳細については sales@support.com までお問い合わせください。
FAPI は、OpenID Foundation の Financial-grade API Working Group が定める Financial-grade API をさします。FAPI は Authlete 2.0 以降で利用可能です。実際の仕様については、Read-Only API Security Profile 、Read and Write API Security Profile を参照してください。
OPEN_BANKING は、英国の Open Banking Implementation Entity が定める Open Banking のセキュリティープロファイルに適合する動作をするかどうかを指定するものです。この機能は、FAPI が有効になっていることが前提となります。Authlete 社は、Open Banking セキュリティープロファイルの公式コンフォーマンステストスイートをパスした数少ないプラットフォームベンダーのうちの一社です（参考：Open Banking Security Profile Conformance ）。
「省略する」を選択すると、認可サーバーがクライアントアプリケーションに返すエラー応答に error_description レスポンスパラメーターが含まれなくなります。
error_description は RFC 6749 で定義されているオプショナルの標準レスポンスパラメーターですが、その内容は各認可サーバーの実装に依存します。Authlete はエラーの説明を error_description レスポンスパラメーターに設定します。その説明は汎用的な場合もありますし、Authlete 固有の場合もありますが、いずれにしても、Authlete 固有の結果コードが説明の先頭に埋め込まれます。この error_description をクライアントプリケーションに見せないようにしたい場合は「省略する」を選択してください。
商用環境において、裏で Authlete が動いていることを完全に隠蔽したい場合は、「省略する」を選択してください。ただし、その場合、クライアントアプリケーションに返されるエラー情報は、「error=invalid_request」のように非常にそっけないものになるので、クライアントアプリケーション開発者が問題の原因を特定するまでにかなり時間を使うことになるので注意してください。
「省略する」を選択すると、認可サーバーがクライアントアプリケーションに返すエラー応答に error_uri レスポンスパラメーターが含まれなくなります。
error_uri は RFC 6749 で定義されているオプショナルの標準レスポンスパラメーターですが、その内容は各認可サーバーの実装に依存します。Authlete はエラーの説明のリストを含むページをさす URI を error_uri レスポンスパラメーターに設定します。当該 URI は Authlete のウェブサイト上のページをさします。この error_uri をクライアントアプリケーションに見せないようにしたい場合は「省略する」を選択してください。
商用環境において、裏で Authlete が動いていることを完全に隠蔽したい場合は、「省略する」を選択してください。
認可エンドポイントの URL です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる authorization_endpoint プロパティーの値として用いられます。
OpenID Connect Discovery 1.0 の仕様では、authorization_endpoint プロパティーは REQUIRED となっているので、当該仕様に完全準拠したい場合は、この項目に値を設定してください。
【無効化推奨】 ダイレクト認可エンドポイントとは、Authlete サーバー上に直接実装された認可エンドポイントの簡易実装です。/api/auth/authorization/direct/{サービスAPIキー} という URL でアクセスできます。このダイレクト認可エンドポイントを有効にするかどうかを決めるのがこの設定項目です。
Authlete のアーキテクチャーは、お客様自身が認可エンドポイントを実装することを想定しています。しかし、その実装にはそれなりに手間がかかります。その実装をしないと Authlete を試せないというのも問題なので、実験やデモンストレーションを主目的として用意されたのが、ダイレクト認可エンドポイントです。
サービス作成時のデフォルトは有効となっていますが、商用環境では無効にしてください。
認可画面の表示言語として指定可能な値を、具体的には、認可リクエストの ui_locales パラメーターの値として指定可能な値を、言語タグ （RFC 5646 ）形式で列挙します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる ui_locales_supported プロパティーの値として用いられます。
クライアントアプリケーションは、希望する認可画面の表示言語を、ui_locales リクエストパラメーターに指定することができます。ただし、その指定を尊重して認可画面の表示言語を切り替えるかどうかは、認可サーバーの実装依存であり、ui_locales を完全に無視しても仕様違反ではありません。一般的には、ui_locales リクエストパラメーターは認識しないが、認可リクエストに含まれる Accept-Language HTTP ヘッダーは認識する、という認可サーバーの実装が多いと思われます。
認可リクエストに含まれる ui_locales の値は、Authlete の /api/auth/authorization API からの応答に uiLocales という名前で含まれます。ただし、この設定項目に含まれていない言語は、uiLocales には含まれません。例えば、認可リクエストに「ui_locales=ja」というリクエストパラメーターが含まれていても、この設定項目に ja が含まれていなければ、/api/auth/authorization API からの応答の uiLocales プロパティーに ja が含まれることはありません。
認可エンドポイントの実装において ui_locales リクエストパラメーターを無視するのであれば、この設定項目は空のままでかまいません。
認可画面の表示タイプとして指定可能な値を、具体的には、認可リクエストの display リクエストパラメーターの値として指定可能な値を設定します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる display_values_supported プロパティーの値として用いられます。
PAGE はデフォルト値で、ユーザーエージェントの表示領域を全て使って表示をおこなうことを要求する値です。この値が有効であれば、display=page を認可リクエストに含めることができます。Authlete の実装上、この値を無効にすると、明示的に display リクエストパラメーターを含んでいない認可リクエストは全て失敗するようになるので、無効にしないでください。
POPUP は、ポップアップ形式で表示をおこなうことを要求する値です。この値が有効であれば、display=popup を認可リクエストに含めることができます。
TOUCH はタッチスクリーンに最適化した形式で表示をおこなうことを要求する値です。この値が有効であれば、display=touch を認可リクエストに含めることができます。
WAP はフィーチャーフォンようの表示をおこなうことを要求する値です。この値が有効であれば、display=wap を認可リクエストに含めることができます。
クライアントアプリケーションは、希望する認可画面の表示タイプを、display リクエストパラメーターに指定することができます。ただし、その指定を尊重して認可画面の表示タイプを切り替えるかどうかは、認可サーバーの実装依存であり、display を完全に無視しても仕様違反ではありません。
この設定項目でサポートされていない値を display リクエストパラメーターに指定すると、認可サーバーはエラー応答を返します。
認可リクエストに含まれる display の値は、Authlete の /api/auth/authorization API からの応答に display という名前で含まれます。認可リクエストに display が含まれていない場合、/api/auth/authorization API からの応答の display の値はデフォルト値の PAGE になります。
特に理由がなければ全て有効にしておいてください。
【有効化推奨】 認可コードフローの認可リクエストにおいて、code_challenge リクエストパラメーターを必須として要求するかいなかを設定する項目です。
「要求する」を選択すると、code_challenge リクエストパラメーターを含まない認可コードフローによる認可リクエストは全て拒否されるようになります。
「要求しない」を選択すると、code_challenge は必須にはなりませんが、その場合でも、認可リクエストに code_challenge が含まれていれば、仕様通りに処理されます。結果として、code_challenge を含んだ認可リクエストに対応するトークンリクエストは、必ず code_verifier リクエストパラメーターを含まなければなりません。
code_challenge は RFC 7636 （Proof Key for Code Exchange by OAuth Public Clients）で定義されています。この仕様は、認可コード横取り攻撃への対抗策として策定された仕様です。スマートフォンアプリに認可コードフローを使用させる場合、セキュリティー上 code_challenge は必須級のリクエストパラメーターとなります。
「要求する」を選択することにより、セキュリティーは高まります。ただし、かわりに、クライアントアプリケーション側にも手間が発生するので、その点はご留意ください。
「PKCE に対応していない既存のクライアントアプリケーションをサポートしなければならない」というような理由がないのであれば、特に、新しくサービスを立ち上げて新しくクライアントアプリケーションを開発するのであれば、商用環境では「要求する」を選択することをお勧めします。
【参考】PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと
トークンエンドポイントの URL です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる token_endpoint プロパティーの値として用いられます。
トークンエンドポイントにおいて、JWT 系のクライアント認証を用いる場合（トークンリクエストに client_assertion={JWT} という形のリクエストパラメーターを含む場合）、その JWT の aud の値がトークンエンドポイントの URL である必要があります。ですので、クライアント認証方式として CLIENT_SECRET_JWT や PRIVATE_KEY_JWT をサポートする場合、この項目には正しい値を設定してください。
【無効化推奨】 ダイレクトトークンエンドポイントとは、Authlete サーバー上に直接実装されたトークンエンドポイントの実装です。/api/auth/token/direct/{サービスAPIキー} という URL でアクセスできます。このダイレクトトークンエンドポイントを有効にするかどうかを決めるのがこの設定項目です。
Authlete のアーキテクチャーは、お客様自身がトークンエンドポイントを実装することを想定しています。しかし、その実装にはそれなりに手間がかかります。その実装をしないと Authlete を試せないというのも問題なので、実験やデモンストレーションを主目的として用意されたのが、ダイレクトトークンエンドポイントです。
サービス作成時のデフォルトは有効となっていますが、商用環境では無効にしてください。
【重要】 トークンエンドポイントにおいてサポートするクライアント認証方式を設定します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる token_endpoint_auth_methods_supported プロパティーの値として用いられます。
クライアントタイプ（RFC 6749, 2.1. Client Types ）が CONFIDENTIAL であるクライアントアプリケーションが一つでも存在する場合は、少なくとも一つは、NONE 以外のクライアント認証方式をサポートする必要があります。
NONE は、クライアント認証を伴わないトークンリクエストを許可するための設定です。クライアントタイプが PUBLIC であるクライアントアプリケーションが一つでも存在する場合は NONE を有効にしておいてください。
CLIENT_SECRET_BASIC は、Basic 認証の仕様に従い、クライアント ID とクライアントシークレットを Authorization ヘッダーに埋め込む形のクライアント認証方式をさします。この方式は RFC 6749 で言及されています。RFC 6749 では、認可サーバーは必ずこのクライアント認証方式をサポートしなければならないとされています。
CLIENT_SECRET_POST は、クライアント ID とクライアントシークレットをリクエストボディーに埋め込む形のクライアント認証方式をさします。この方式も、CLIENT_SECRET_BASIC 同様に RFC 6749 で言及されています。セキュリティー的には CLIENT_SECRET_BASIC のほうが良いとされているので、CLIENT_SECRET_BASIC は有効にするが CLIENT_SECRET_POST は無効にする、という運用方針を選択することもありえます。
CLIENT_SECRET_JWT は、RFC 7523 で定義されている JWT 系クライアント認証方式で、JWT の署名に共有鍵系のアルゴリズムを用いる形式をさします。詳細は OpenID Connect Core 1.0, 9. Client Authentication を参照してください。
PRIVATE_KEY_JWT は、RFC 7523 で定義されている JWT 系クライアント認証方式で、JWT の署名に非対称鍵系のアルゴリズムを用いる形式をさします。詳細は OpenID Connect Core 1.0, 9. Client Authentication を参照してください。
CLIENT_SECRET_JWT と PRIVATE_KEY_JWT は以前から項目として存在していましたが、Authlete 1.x 系では Authlete 側の実装が存在しなかったため、これらの認証方式をサポートする場合はお客様が独自実装するしかありませんでした。しかし、Authlete 2.x 系では Authlete 側に実装が存在するので、お客様が独自実装する必要はありません。
TLS_CLIENT_AUTH はクライアント証明書を用いたクライアント認証方式で、詳細は OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens の 2.1. PKI Mutual TLS OAuth Client Authentication Method で説明されています。このクライアント認証方式をサポートするためには、フロントの認可サーバーのトークンエンドポイントの実装において、トークンリクエストの中からクライアント証明書を抜き出し、それを Authlete の /api/auth/token API の clientCertificate リクエストパラメーターの値として設定する、という実装が必要となります。
SELF_SIGNED_TLS_CLIENT_AUTH は自己署名クライアント証明書を用いたクライアント認証方式で、詳細は OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens の 2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method で説明されています。このクライアント認証方式をサポートするためには、フロントの認可サーバーのトークンエンドポイントの実装において、トークンリクエストの中からクライアント証明書を抜き出し、それを Authlete の /api/auth/token API の clientCertificate リクエストパラメーターの値として設定する、という実装が必要となります。
Financial-grade API 仕様では、Read-Only API 用のトークンリクエストで用いることが許されているクライアント認証方式は次の 4 つです。1. TLS_CLIENT_AUTH 2. SELF_SIGNED_TLS_CLIENT_AUTH 3. CLIENT_SECRET_JWT 4. PRIVATE_KEY_JWT
また、Read-Write API 用のトークンリクエストで用いることが許されているクライアント認証方式は次の 3 つです。1. TLS_CLIENT_AUTH 2. SELF_SIGNED_TLS_CLIENT_AUTH 3. PRIVATE_KEY_JWT
ですので、FAPI をサポートしたい場合、NONE、CLIENT_SECRET_BASIC、CLIENT_SECRET_POST 以外のクライアント認証方式をサポートする必要があります。
「有効」を選択すると、クライアント認証方式として TLS_CLIENT_AUTH が用いられた場合に、当該リクエストで用いられたクライアント証明書が、事前に登録しておいたルート証明書群から到達可能であるかどうかの検証を Authlete サーバー側で実施するようになります。
「無効」を選択した場合、Authlete 側で上記の検証をおこなわないので、認可サーバーの実装側で検証をおこなってください。
ルート証明書群の登録は、「相互 TLS を利用したクライアント認証において用いる信頼されたルート証明書群」という設定項目でおこないます。
前出の設定項目「相互 TLS を利用したクライアント認証における PKI 証明書チェーン検証の有効化」が有効である場合、TLS_CLIENT_AUTH で用いられたクライアント証明書が、この設定項目を通じて登録されたルート証明書群のいずれかから到達可能であるかどうかの検証がおこなわれます。
トークン取消エンドポイント（RFC 7009 ）の URL です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる revocation_endpoint プロパティーの値として用いられます。
トークン取消エンドポイントの実装は、仕様上は必須ではありません。
Authlete の /api/auth/revocation API は、RFC 7009 に準拠するトークン取消エンドポイントをお客様が実装する際に利用する API となります。/api/auth/revocation API 自体は RFC 7009 とは別物です。
【無効化推奨】 ダイレクトトークン取消エンドポイントとは、Authlete サーバー上に直接実装されたトークン取消エンドポイントの実装です。/api/auth/revocation/direct/{サービスAPIキー} という URL でアクセスできます。このダイレクト取消トークンエンドポイントを有効にするかどうかを決めるのがこの設定項目です。
サービス作成時のデフォルトは有効となっていますが、商用環境では無効にしてください。
イントロスペクションエンドポイント（RFC 7662 ）の URL です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる introspection_endpoint プロパティーの値として用いられます。
イントロスペクションエンドポイントの実装は、仕様上は必須ではありません。
Authlete の /api/auth/introspection/standard API は、RFC 7662 に準拠するイントロスペクションエンドポイントをお客様が実装する際に利用する API となります。/api/auth/introspection/standard API 自体は RFC 7662 とは別物です。
なお、Authlete の /api/auth/introspection API は、Authlete 独自仕様のイントロスペクション API です。標準仕様（RFC 7662）とは異なり、/api/auth/introspection API はアクセストークンに関する情報を返すだけでなく、アクセストークンの検証や RFC 6750 に準拠するエラーメッセージの生成などもおこないます。また、アクセストークンに紐付けられた任意のキー・バリューペア（Authlete 独自機能）の情報も返します。そのため、通常、リソースサーバーの Web API の実装は Authlete 独自のイントロスペクション API（/api/auth/introspection）を用いてアクセストークンの情報を取得することになります。
【参考】アクセストークン検証の委譲
【無効化推奨】 ダイレクトイントロスペクションエンドポイントとは、Authlete サーバー上に直接実装されたイントロスペクションエンドポイント（RFC 7662 ）の実装です。/api/auth/introspection/standard/direct という URL でアクセスできます。このダイレクトイントロスペクションエンドポイントを有効にするかどうかを決めるのがこの設定項目です。
サービス作成時のデフォルトは有効となっていますが、商用環境では無効にしてください。
アクセストークンのタイプを指定します。ここで設定された値は、アクセストークン発行時に認可サーバーから返される token_type レスポンスパラメーターの値として用いられます。
リソースサーバーの API 群が RFC 6750 で定義されている方法でアクセストークンを受け取るのであれば、Bearer と入力してください。
一般的には、明確な理由がない限り、Web API 実装は RFC 6750 に従います。
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens の 3. Mutual TLS Client Certificate Bound Access Tokens で定義されている、証明書に紐付いたアクセストークンをサポートするかどうかの設定です。この設定項目を「サポートする」にすると、Authlete の /api/service/configuration API を用いて実装したディスカバリーエンドポイントは、その応答に「“tls_client_certificate_bound_access_tokens”:true」を含めるようになります。
この機能を有効にすると、トークンリクエストの際に用いられたクライアント証明書の情報がアクセストークンに紐付けられます。クライアントアプリケーションは、そのアクセストークンを使って Web API にアクセスするときは、トークンリクエストの際に用いたものと同じクライアント証明書を使ってアクセスしないといけません。そうしないと、アクセスは拒否されます。
アクセストークンをクライアント証明書に紐付けておくと、アクセストークンが漏洩してしまったとしても、簡単には悪用されなくなります。というのは、アクセストークンが手元にあったとしても、そのアクセストークンが発行された際に用いられたクライアント証明書も同時に手元にない限り、Web API アクセスを成功させることができないからです。
この機能を用いる場合、トークンエンドポイントの実装および各 Web API の実装は、リクエストの中からクライアント証明書を抜き出し、Authlete の API を呼び出す際に clientCertificate リクエストパラメーターの値として渡す必要があります。トークンエンドポイントの実装が呼び出す /api/auth/token API、Web API の実装が呼び出す /api/auth/introspection API にそれぞれ clientCertificate リクエストパラメーターが存在します。
アクセストークンをクライアント証明書に紐付けると、セキュリティーは高まります。しかし、かわりに、認可サーバー、リソースサーバー、クライアントアプリケーションにおいて追加の実装作業が発生するので、その点はご留意ください。
なお、サービス側でこの設定項目を「サポートする」としていても、クライアントアプリケーションの「TLS クライアント証明書を紐付けたアクセストークンの使用」という設定項目を「使用する」にしておかないと、当該クライアントに対して発行されるアクセストークンは、クライアント証明書に紐付けられません。
Financial-grade API では、Read-Write API 用の認可コード・アクセストークン・リフレッシュトークンはクライアント証明書に紐付いている必要があります。そのため、FAPI の Read and Write API Security Profile をサポートするためには、本設定を「サポートする」にしてください。
アクセストークンの有効期間秒数を秒単位で指定します。この値は、アクセストークン発行時にアクセストークンと共に返される expires_in レスポンスパラメーターの値を計算する際にも用いられます。
アクセストークン有効期間の長さをどれくらいにすべきかは、それぞれのサービスの特性によります。1 時間、1 日、1 年、100 年など、様々です。
ここで設定された値は当該サービスが発行するアクセストークン全てに適用されますが、/api/auth/token/update API の accessTokenExpiresAt リクエストパラメーターを用いて、個別に有効期限を変更することは可能です。また、手動でアクセストークンを生成するための /api/auth/token/create API には accessTokenDuration というオプショナルパラメーターがあり、これを指定することで個別に有効期間秒数を指定することができます。
同一のサブジェクトとクライアントアプリケーションの組に対して、同時に最大で一つのアクセストークンの存在しか許さないか（単一化）、それとも、複数のアクセストークンの発行を許可するか、を指定する設定項目です。どちらを選択するかはサービスの方針に基づいて決定してください。なお、特に正解があるわけではありません。
「有効」を選択すると、同時に最大で一つのアクセストークンの存在しか許さなくなるので、新しいアクセストークンを発行するとき、同じサブジェクトとクライアントアプリケーションの組に関連づけられた既存のアクセストークンは無効になります。
ただし、クライアントクレデンシャルズフローで発行されるアクセストークンはエンドユーザーのサブジェクトには関連付けられないので、クライアントクレデンシャルズフローで新しいアクセストークンを発行しても、既存のアクセストークンは無効にはなりません。
リフレッシュトークンの有効期間の秒数を秒単位で指定します。
新しいアクセストークンを得るために使用されたリフレッシュトークンを、使用後も有効のままとするか、もしくは使用と同時に無効化して新しいリフレッシュトークンを発行するか、を指定する設定項目です。どちらを選択するかはサービスの方針に基づいて決定してください。なお、特に正解があるわけではありません。
リフレッシュトークンを継続使用する場合、いつかはリフレッシュトークンが有効切れになるので、そのタイミングで再度認可処理が必要となります。
一方、リフレッシュトークンを継続使用しない場合、リフレッシュトークンを使うたびに新しいリフレッシュトークンが再発行されるので、「リフレッシュトークンが期限切れになる前にリフレッシュトークンを用いてアクセストークンを更新する」という処理を続けている間は、認可処理が再び必要とされることはありません。
【重要】 サービスでサポートするスコープ群を列挙します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる scopes_supported プロパティーの値として用いられます。
ここで列挙されている値のみが、認可リクエストの scope パラメーターの値として使用可能です。ここに列挙されていないスコープが scope パラメーターに含まれていても、Authlete は黙って無視します。逆に言うと、エラーとはしません。エラーとしない理由は、OpenID Connect Core 1.0, 3.1.2.1. Authentication Request 内にある scope パラメーターの説明に「Scope values used that are not understood by an implementation SHOULD be ignored.」（未知の scope 値は無視すべき）と書かれているためです。
各スコープ毎に、スコープ名、デフォルト設定（真偽値）、説明、属性、といった設定項目があります。
スコープ名は、scope パラメーターの値として用いる文字列です。仕様により、スコープ名に用いることができる文字は「スペース、ダブルクォート、バックスラッシュを除く、表示可能な ASCII 文字」のみです。
デフォルト設定は、認可リクエストに scope パラメーターが含まれていない場合に参照されます。scope パラメーターが含まれていない場合、デフォルト設定が真となっているスコープ群が指定されたものとして処理がおこなわれます。
説明は、仕様上必要はありませんが、Authlete はデータとして管理しています。なお、OpenID Connect Core 1.0 で定義されている標準スコープ（openid、profile、email、address、phone、offline_access）については、説明を変更することはできません。
属性は、任意のキー・バリュー群であり、自由に設定することができます。scope に任意のキー・バリューを紐付けることができるというのは、Authlete の独自機能です。
scope の属性のうち次のものは Authlete が特別に解釈するのでご留意ください。
| 属性名 | 属性値 | 説明 |
|---|---|---|
| fapi | r | Financial-grade API Read-Only を意味します。この属性を持つスコープを一つ以上含む認可リクエストは、Financial-grade API における「Read-Only API 用のアクセストークンを要求する認可リクエスト」とみなされ、Financial-grade API - Part 1: Read-Only API Security Profileの制約条件を満たしているかどうかを Authlete がチェックするようになります。例えば、認可コードフローによる認可リクエストであれば、リクエストに code_challenge と code_challenge_method=S256 が含まれているかどうかのチェックが行われるようになります。 |
| fapi | rw | Financial-grade API Read-Write を意味します。この属性を持つスコープを一つ以上含む認可リクエストは、Financial-grade API における「Read-Write API 用のアクセストークンを要求する認可リクエスト」とみなされ、Financial-grade API - Part 2: Read and Write API Security Profileの制約条件を満たしているかどうかを Authlete がチェックするようになります。例えば、認可リクエストに request もしくは request_uri が含まれているかどうかのチェックが行われるようになります。認可リエクスト全体で fapi=r と fapi=rw が混在する場合、fapi=rw のほうが優先され、当該認可リクエストは「Read-Write API 用のアクセストークンを要求する認可リクエスト」とみなされます。 |
サービス作成時、OpenID Connect Core 1.0 で定義される標準スコープ群が初期値として設定されます。
| スコープ名 | 説明 |
|---|---|
| openid | 最も重要なスコープです。認可リクエストにこのスコープが含まれていないと、そのリクエストは OpenID Connect のリクエストとは認識されません。OpenID Connect が機能しなくなってしまうので、余程の明確な理由がない限り、このスコープは削除しないでください。詳細は 3.1.2.1. Authentication Request を参照してください。 |
| profile | ID トークンにユーザーのプロフィールに関するクレーム群を埋め込むことを要求するスコープです。詳細は 5.4. Requesting Claims using Scope Values を参照してください。 |
| ID トークンにユーザーの電子メールに関するクレーム群を埋め込むことを要求するスコープです。詳細は 5.4. Requesting Claims using Scope Values を参照してください。 | |
| address | ID トークンにユーザーの住所に関するクレーム群を埋め込むことを要求するスコープです。詳細は 5.4. Requesting Claims using Scope Values を参照してください。 |
| phone | ID トークンにユーザーの電話番号に関するクレーム群を埋め込むことを要求するスコープです。詳細は 5.4. Requesting Claims using Scope Values を参照してください。 |
| offline_access | 「ユーザーがログインしていないくてもユーザー情報エンドポイントにアクセスすることが可能なアクセストークン」と交換可能なリフレッシュトークンの発行を要求するためのスコープです。詳細は 11. Offline Access を参照してください。 |
スコープ群をどれくらいの権限粒度で定義していくかは自由であり、特に正解はありません。
「サービスの要件に基づいてスコープを定義していったら、あまりに細分化して収拾がつかなくなりそう」という場合、スコープに基づく権限細分化ではなく、「アクセストークン毎に紐付ける情報を変化させる」というアプローチのほうがよいかもしれません。Authlete には、アクセストークンに任意のキー・バリューペアを紐付けるという独自機能があるので、その機能の活用を検討してみてください（参考：アクセストークンと任意データ ）。
ID トークンの有効期間を秒単位で指定します。ここで設定された値は、ID トークンの exp クレームの値を計算する際に使用されます。
サポートするクレーム種別を選択します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる claim_types_supported プロパティーの値として用いられます。
NORMAL は、このサービス自身が直接クレーム値を提供する形式です。サービス作成時の初期設定ではこの項目だけが有効になっています。
AGGREGATED は、クレーム値の提供者は別であるものの、それらの値をこのサービスが収集してクライアントに返す形式です。
DISTRIBUTED は、クレーム値の提供者が別にいて、このサービスからはその提供者へのポインターのみを返す形式です。
クレーム種別の詳細は OpenID Connect Core 1.0, 5.6. Claim Types を参照してください。
注意：AGGREGATED と DISTRIBUTED をサポートしたい場合は、5.6.2. Aggregated and Distributed Claims に記述されているフォーマットで情報を用意し、Authlete の /api/auth/authorization/issue API に渡す必要があります。Authlete 自体は AGGREGATED と DISTRIBUTED を直接的にサポートはしていません。
クレーム値の言語を指定するために指定可能な値を、具体的には、認可リクエストの claims_locales パラメーターの値として指定可能な値を、言語タグ （RFC 5646 ）形式で列挙します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる claims_locales_supported プロパティーの値として用いられます。
クライアントアプリケーションは、ID トークンに埋め込むクレームの値について、希望する言語があれば、claims_locales リクエストパラメーターで指定することができます。例えば、claims_locales=ja をリクエストに含めることで、ID トークンに埋め込まれる family_name の値を日本語で返してほしいことをサーバーに伝えることができます。詳細は OpenID Connect Core 1.0, 5.2. Claims Languages and Scripts を参照してください。
しかしながら、その指定を尊重して ID トークンに埋め込むクレーム群の値の言語を切り替えるかどうかは、認可サーバーの実装依存であり、claims_locales を完全に無視しても仕様違反ではありません。
認可リクエストに含まれる claims_locales の値は、Authlete の /api/auth/authorization API からの応答に claimsLocales という名前で含まれます。ただし、この設定項目に含まれていない言語は、claimsLocales には含まれません。例えば、認可リクエストに「claims_locales=ja」というリクエストパラメーターが含まれていても、この設定項目に ja が含まれていなければ、/api/auth/authorization API からの応答の claimsLocales に ja が含まれることはありません。
認可エンドポイントの実装において claims_locales リクエストパラメーターを無視するのであれば、この設定項目は空のままでかまいません。
サポートするクレームを列挙します。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる claims_supported プロパティーの値として用いられます。
ここで「サポートする」とは、このサービスが当該クレームの情報を直接または間接的に提供することが可能である、という意味になります。
サービス作成時、OpenID Connect Core 1.0, 5.1. Standard Claims で定義される 20 個の標準クレーム群が初期値として設定されます。
認可リクエストにより要求されたクレーム群の名前は、Authlete の /api/auth/authorization API からの応答に claims という名前で含まれます。ただし、この設定項目に含まれていないクレームは、claims には含まれません。例えば、認可リクエストの scope パラメーターに email と phone が含まれていても（それらは本来 email, email_verified, phone_number, phone_number_verified という 4 つのクレーム群へと展開される）、この設定項目に email_verified と phone_number_verified が含まれていない場合、/api/auth/authorization API からの応答の claims に email_verified と phone_number_verified が含まれることはありません。
【参考】クレーム
サービスの JWK セットドキュメント（RFC 7517 ）の URL です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる jwks_uri プロパティーの値として用いられます。
「JWK セットの内容」という設定項目で JWK セットの内容が Authlete に登録されていない場合、必要に応じて Authlete はこの設定項目に指定された URI から JWK セットを取得しようと試みます。ただし、非対称鍵系アルゴリズムの秘密鍵を取得するために外部の JWK セットを取得しにいくことはありません。そのため、非対称鍵系アルゴリズムの秘密鍵を必要とする処理がおこなわれるのであれば、例えば非対称鍵系アルゴリズムで ID トークンに署名をするのであれば、その秘密鍵は「JWK セットの内容」で 登録されている必要があります。
ID トークン の署名、ユーザー情報エンドポイント のレスポンスへの署名、リクエストオブジェクト の暗号化、認可レスポンスへの署名（JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) ）、において、非対称鍵系アルゴリズムをサポートしたい場合、（JWK セットをオフラインでクライアントアプリケーション開発者に渡すという運用をしない限り）JWK セットエンドポイントの実装が必要になります。
Authlete の /api/service/jwks/get API は、JWK セットエンドポイントをお客様が実装する際に利用する API となります。
【無効化推奨】 ダイレクト JWK セットエンドポイントとは、Authlete サーバー上に直接実装された JWK セットエンドポイント（RFC 7517 ）の実装です。/api/service/jwks/get/direct/{サービスAPIキー} という URL でアクセスできます。このダイレクト JWK セットエンドポイントを有効にするかどうかを決めるのがこの設定項目です。
サービス作成時のデフォルトは有効となっていますが、商用環境では無効にしてください。
サービスの JWK セットドキュメント（RFC 7517 ）の内容です。
ID トークン の署名、ユーザー情報エンドポイント のレスポンスへの署名、リクエストオブジェクト の暗号化、認可レスポンスへの署名（JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) ）、において、非対称鍵系アルゴリズムをサポートしたい場合、JWK セットドキュメントの登録は必須となります。サポートしたいアルゴリズム群に対応する公開鍵・秘密鍵の組を含めておく必要があります。
JWS（RFC 7515 ）の alg に指定可能なアルゴリズムは、JWA（RFC 7518 ）の「3.1. “alg” (Algorithm) Header Parameter Values for JWS 」に列挙されています。それらのうち、RS、PS、ES ではじまるアルゴリズムが非対称鍵系アルゴリズムです。
JWE（RFC 7516 ）の alg に指定可能なアルゴリズムは、JWA（RFC 7518 ）の「4.1. “alg” (Algorithm) Header Parameter Values for JWE 」に列挙されています。それらのうち、RSA、ECDH ではじまるアルゴリズムが非対称鍵系アルゴリズムです。
JWK や JWK セットを作成するオンラインサービスとして mkjwk.org というものがありますので、参考にしてみてください。
ID トークンの署名に使う JWK（RFC 7517 ）を特定するためのキー ID です。
署名に使うアルゴリズムが非対称鍵系の場合、登録された JWK セットの中から当該アルゴリズムの秘密鍵をあらわす JWK を探し出て使うことになります。JWK を探した結果、条件を満たす JWK が一つだけであれば、何も問題ありません。一方、複数存在する場合、Authlete サーバーがどの JWK を選ぶべきか判断できるよう、使うべき JWK のキー ID をこの設定項目を通じて指定しておく必要があります。
条件を満たす JWK が複数存在しているにもかかわらず、この設定項目が空の場合、それでも Authlete は JWK を一つ選択しようと試みます。しかし、選択できないときもあります（複数存在するがいずれの JWK もキー ID を持っていない場合など）。この場合、Authlete サーバーは ID トークンの生成に失敗します。
ユーザー情報エンドポイント からのレスポンスの署名に使う JWK を特定するためのキー ID です。
署名に使うアルゴリズムが非対称鍵系の場合、登録された JWK セットの中から当該アルゴリズムの秘密鍵をあらわす JWK を探し出て使うことになります。JWK を探した結果、条件を満たす JWK が一つだけであれば、何も問題ありません。一方、複数存在する場合、Authlete サーバーがどの JWK を選ぶべきか判断できるよう、使うべき JWK のキー ID をこの設定項目を通じて指定しておく必要があります。
条件を満たす JWK が複数存在しているにもかかわらず、この設定項目が空の場合、それでも Authlete は JWK を一つ選択しようと試みます。しかし、選択できないときもあります（複数存在するがいずれの JWK もキー ID を持っていない場合など）。この場合、Authlete サーバーはユーザー情報エンドポイントからのレスポンスの生成に失敗します。
認可レスポンスの署名（JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) ）に使う JWK を特定するためのキー ID です。
署名に使うアルゴリズムが非対称鍵系の場合、登録された JWK セットの中から当該アルゴリズムの秘密鍵をあらわす JWK を探し出て使うことになります。JWK を探した結果、条件を満たす JWK が一つだけであれば、何も問題ありません。一方、複数存在する場合、Authlete サーバーがどの JWK を選ぶべきか判断できるよう、使うべき JWK のキー ID をこの設定項目を通じて指定しておく必要があります。
条件を満たす JWK が複数存在しているにもかかわらず、この設定項目が空の場合、それでも Authlete は JWK を一つ選択しようと試みます。しかし、選択できないときもあります（複数存在するがいずれの JWK もキー ID を持っていない場合など）。この場合、Authlete サーバーは認可レスポンスを JWT として生成することに失敗します。結果的に、RFC 6749 で定義されている、これまで通りのエラーレスポンスが生成されます。
ユーザー情報エンドポイント（OpenID Connect Core 1.0, 5.3. UserInfo Endpoint
）の URL です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる userinfo_endpoint プロパティーの値として用いられます。
ユーザー情報エンドポイントの実装は、仕様上は必須ではありません。
Authlete の /api/auth/userinfo API および /api/auth/userinfo/issue API は、仕様に準拠するユーザー情報エンドポイントをお客様が実装する際に利用する API となります。/api/auth/userinfo API 自体はユーザー情報エンドポイントではありません。
【無効化推奨】 ダイレクトユーザー情報エンドポイントとは、Authlete サーバー上に直接実装されたユーザー情報エンドポイントの実装です。このダイレクト JWK セットエンドポイントを有効にするかどうかを決めるのがこの設定項目です。
サービス作成時のデフォルトは有効となっていますが、商用環境では無効にしてください。
注意：ダイレクトユーザー情報エンドポイントは、まだ実装されていないので、この設定項目の値がいずれであっても、利用できません。
クライアントアプリケーションを動的に登録するためのエンドポイント（OpenID Connect Dynamic Client Registration 1.0 ）の URI です。このサービスが Authlete の /api/service/configuration API を用いてディスカバリーエンドポイントを実装する場合、そのエンドポイントからの応答に含まれる registration_endpoint プロパティーの値として用いられます。
このエンドポイントの実装は、仕様上は必須ではありません。
OpenID Connect Dynamic Client Registration の仕様に準拠するエンドポイントの実装に利用できる Authlete API は、現在のところ提供されていません。ただし、Authlete 独自の API である /api/service/create API を用いてクライアントアプリケーションを動的に登録することは可能です。
このサービスが提供するデータを利用する際の要件を記述した文書の 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 プロパティーの値として用いられます。