Introduction

This article explains the procedure for publishing a JWK Set using the Authlete API by an OpenID Provider (OP) or an Authorization Server (AS).

Publishing a JWK Set

A Relying Party (RP) requires the OP’s public keys in order to verify the signature of ID tokens obtained from the OP and to encrypt Request Objects presented to the OP. One way for an OP to provide these public keys to an RP in the form of JWKs is defined in OpenID Connect Discovery 1.0.
Similarly, in OAuth 2.0, the method by which an AS provides such information to clients is specified in RFC 8414 - OAuth 2.0 Authorization Server Metadata.

For OPs/ASs that support these specifications, the following implementations are required:

• Configuration of jwks_uri (JWK Set Endpoint URI) in the server metadata
• Publication of a JWK Set (a set of multiple JWKs) via the JWK Set EP

Implementation Using Authlete

Configuring jwks_uri in Server Metadata

When the JWK Set Content and the JWK Set Endpoint URIare registered with an Authlete service, Authlete automatically generates server metadata that includes jwks_uri.
For details on the registration procedure, refer to JWK Set Configuration for an Authlete Service.

Publishing a JWK Set via the JWK Set Endpoint

When implementing a JWK Set endpoint in an OP/AS, Authlete’s Get JWK Set API can be used as the backend.

Example Implementation

In this example, assume that a JWK Set containing an ES256 key has been configured in advance in the Authlete service as the JWK Set Content and that https://as.example.com/jwks has been configured as the JWK Set Endpoint URI.

An RP that implements OpenID Connect Discovery 1.0, or a client that implements RFC 8414, first discovers and retrieves the server metadata of the OP/AS based on these specifications. Next, it sends a request to the JWK Set endpoint indicated by the jwks_uri included in the metadata.

Upon receiving this request, the OP/AS invokes Authlete’s Get JWK Set API on the backend as part of the JWK Set endpoint processing.
Below is an example cURL command used by the OP/AS to call the Authlete API.

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

If a JWK Set has been properly registered, Authlete returns the JWK Set registered with the service in JSON format.

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

The OP/AS returns this JSON to the RP or client as the response from the JWK Set endpoint.

Using Caching

Depending on the update interval and frequency of the JWK Set, implementing a mechanism to cache the JWK Set on the RP/client side or the OP/AS side can indirectly or directly reduce the number of calls to the Authlete API. This can help reduce latency. Taking into account the key rotation policy and rotation period, consider implementing an appropriate caching strategy.

Related Articles

• Publishing OpenID Connect Discovery Metadata