With JwkSetSecretStore

This page shows how to validate signed access tokens with the StatelessAccessTokenResolver using a JwkSetSecretStore.

This procedure uses the Resource Owner Password Credentials grant type. As suggested in The OAuth 2.0 Authorization Framework, use other grant types whenever possible.

Set up AM:
1. Configure an OAuth 2.0 Authorization Provider:
  1. Select Services, and add an OAuth 2.0 Provider.
  2. Accept the default values and select Create. The service is added to the Services list.
  3. On the Core tab, select the following option:
    
    Use Client-Based Access & Refresh Tokens : on
  4. On the Advanced tab, select the following options:
    
    Client Registration Scope Allowlist : myscope
    
    OAuth2 Token Signing Algorithm : RS256
    
    Encrypt Client-Based Tokens : Deselected
2. Create an OAuth2 Client to request OAuth 2.0 access tokens:
  1. Select Applications > OAuth 2.0 > Clients, and add a client with the following values:
    
    Client ID : client-application
    
    Client secret : password
    
    Scope(s) : myscope
  2. (Optional) On the Core tab, switch to using a client secret associated with a secret label by setting a Secret Label Identifier and mapping the label to a secret.
    
    To learn more, read Create a client profile and Map and rotate secrets in the AM documentation.
  3. On the Advanced tab, select the following values:
    
    Grant Types : Resource Owner Password Credentials
    
    Response Types : code token
  4. On the Signing and Encryption tab, include the following setting:
    
    ID Token Signing Algorithm : RS256

Set up PingGateway:

Set up PingGateway for HTTPS, as described in Configure PingGateway for TLS (server-side).

Add the following route to PingGateway:

Linux
Windows

$HOME/.openig/config/routes/rs-stateless-signed.json

%appdata%\OpenIG\config\routes\rs-stateless-signed.json

{
  "name": "rs-stateless-signed",
  "condition": "${find(request.uri.path, '/rs-stateless-signed')}",
  "heap": [
    {
      "name": "SecretsProvider-1",
      "type": "SecretsProvider",
      "config": {
        "stores": [
          {
            "type": "JwkSetSecretStore",
            "config": {
              "jwkUrl": "http://am.example.com:8088/openam/oauth2/connect/jwk_uri"
            }
          }
        ]
      }
    }
  ],
  "handler": {
    "type": "Chain",
    "capture": "all",
    "config": {
      "filters": [
        {
          "name": "OAuth2ResourceServerFilter-1",
          "type": "OAuth2ResourceServerFilter",
          "config": {
            "scopes": ["myscope"],
            "requireHttps": false,
            "accessTokenResolver": {
              "type": "StatelessAccessTokenResolver",
              "config": {
                "secretsProvider": "SecretsProvider-1",
                "issuer": "http://am.example.com:8088/openam/oauth2",
                "verificationSecretId": "any.value.in.regex.format"
              }
            }
          }
        }
      ],
      "handler": {
        "type": "StaticResponseHandler",
        "config": {
          "status": 200,
          "headers": {
            "Content-Type": [ "text/html; charset=UTF-8" ]
          },
          "entity": "<html><body><h2>Decoded access_token: ${contexts.oauth2.accessToken.info}</h2></body></html>"
        }
      }
    }
  }
}

Notice the following features of the route:

The route matches requests to /rs-stateless-signed.
A SecretsProvider in the heap declares a JwkSetSecretStore to manage secrets for signed access tokens.
The JwkSetSecretStore specifies the URL to a JWK set on AM, that contains the signing keys.
The OAuth2ResourceServerFilter expects an OAuth 2.0 access token in the header of the incoming authorization request, with the scope myscope.
The StatelessAccessTokenResolver uses the SecretsProvider to verify the signature of the provided access token.
After the OAuth2ResourceServerFilter validates the access token, it creates the OAuth2Context context. You can find more information in OAuth2Context.
If there is no access token in a request, or token validation doesn’t complete successfully, the filter returns an HTTP error status to the user agent, and PingGateway doesn’t continue processing the request. This is done as specified in the RFC The OAuth 2.0 Authorization Framework: Bearer Token Usage.
The StaticResponseHandler returns the content of the access token from the context.

Test the setup for a signed access token:

Get an access token for the demo user, using the scope myscope:

$ mytoken=$(curl -s \
--user "client-application:password" \
--data "grant_type=password&username=demo&password=Ch4ng31t&scope=myscope" \
http://am.example.com:8088/openam/oauth2/access_token | jq -r ".access_token")

Display the token:
```
$ echo ${mytoken}
```
Note that the token is structured as a signed token.

Access the route by providing the token returned in the previous step:

$ curl -v \
--cacert /path/to/secrets/ig.example.com-certificate.pem \
--header "Authorization: Bearer ${mytoken}" \
https://ig.example.com:8443/rs-stateless-signed

...
    Decoded access_token: {
    sub=(usr!demo),
    cts=OAUTH2_STATELESS_GRANT,
    ...

PingGateway 2024.11

With JwkSetSecretStore