はじめに

本記事では、OpenID プロバイダー (OP) もしくは認可サーバー (AS) が、Authlete API を用いて JWK セットを公開する手順を説明します。

JWK セットの公開

リライングパーティ (RP) は、OP から取得した ID トークンの署名の検証や、OP に提示する Request Object の暗号化に際し、OP の公開鍵を必要とします。この公開鍵を OP が RP に JWK として提供する方法のひとつが、OpenID Connect Discovery 1.0 です。また OAuth 2.0 においても、AS からクライアントへの提供方法が、RFC 8414 - OAuth 2.0 Authorization Server Metadata に規定されています。

同仕様をサポートする OP/AS では、以下の実装が必須となります。

• サーバーメタデータへの jwks_uri (JWK セットエンドポイントの URI) の設定
• JWK セット EP を通じた JWK セット (複数の JWK のセット) の公開

Authlete を利用した実装

サーバーメタデータへの jwks_uri の設定

「JWK セットの内容」と「JWK セットエンドポイントの URI」を Authlete のサービスに登録すると、Authlete は自動的に jwks_uri を含むサーバーメタデータを生成します。これらの登録手順については、Authlete サービスの JWK セット設定 を参照してください。

JWK セットエンドポイントを通じた JWK セットの公開

OP/AS における JWK セットエンドポイントの実装にあたっては、Authlete の Get JWK Set API をバックエンドとして利用できます。

実装例

ここでは、「JWK セットの内容」として ES256 の鍵を含む JWK セットが、「JWK セットエンドポイントの URI」として https://as.example.com/jwks が、あらかじめ Authlete のサービスに設定されているものとします。

OpenID Connect Discovery 1.0 を実装した RP、または RFC 8414 を実装したクライアントは、これらの仕様に基づき、まず OP/AS のサーバーメタデータを発見・取得します。次に、そのメタデータに含まれる jwks_uri が示す JWK セットエンドポイントに対してリクエストを送信します。

このリクエストを受け付けた OP/AS は、JWK セットエンドポイントの処理として、バックエンドで Authlete の Get JWK Set API を呼び出します。
以下は、OP/AS から Authlete API を呼び出す際の cURL の例です。

curl -v {Authlete API}/api/{Service ID}/service/jwks/get?pretty=true \
     -H 'Authorization: Bearer {Service Access Token}'

JWK セットが適切に登録されている場合、Authlete はサービスに登録されている JWK セットを JSON 形式で返します。

{
  "keys": [
    {
      "kty": "EC",
      "use": "sig",
      "crv": "P-256",
      "kid": "1",
      "x": "DQ5ADe7viHfsrnrTy4oXrguWgSbuk-qLGR6bhWSg-gw",
      "y": "HeW4HeETjzyJbmf3FgoLWUtCHzgfRB8-gVYn4lt6XbA",
      "alg": "ES256"
    }
  ]
}

OP/AS は、この JSON を JWK セットエンドポイントのレスポンスとして RP またはクライアントに返します。

キャッシュの活用

JWK セットの更新間隔や頻度によっては、JWK セットをキャッシュする仕組みを RP/クライアントや OP/AS に実装することで、Authlete API の呼び出し回数を間接的または直接的に抑制できます。これにより、レイテンシーの低減が期待できます。 キーローテーションの方針や期間を考慮したうえで、適切なキャッシュ戦略の実装を検討してください。

関連記事

• OpenID Connect Discovery メタデータの公開