Chapter 15. OAuth Identity and Authorization Chaining Across Domains

This client will also be the client configured in domainb for the identity provider access. Go to Clients and click Create Client.

Figure 15.2. Client that represents domainb in domaina

Create a client scope access-domainb to include the correct audience for the token when this scope is requested. An audience mapper for domainb will be added. In Client scopes, click Create client scope.

Figure 15.3. Client scope to include domainb as audience

In the Mappers tab, click Configure a new mapper and select Audience:

Figure 15.4. Client scope mapper for domainb audience

Create a confidential OpenID Connect client clienta with Standard flow, Direct access grants and Standard token exchange capability enabled.

Figure 15.5. Client for token exchange

In the tab Client scopes, assign the previous access-domainb scope as optional to clienta. Click Add client scope, select access-domainb and Add as Optional.

Figure 15.6. Add client scope as optional

Finally create a sample user in domaina with username testuser. Set a password to the account.

Normally clienta will possess an initial token issued by domaina, obtained via normal authorization flow, or just because the client is a service endpoint that receives the token as a bearer. In this example, a direct access grant for testuser is requested to get token1.

curl -s -X POST \
  --location http://localhost:8080/realms/domaina/protocol/openid-connect/token \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "client_id=clienta" \
  --data-urlencode "client_secret=XXXXXX" \
  --data-urlencode "grant_type=password" \
  --data-urlencode "username=testuser" \
  --data-urlencode "password=YYYYYY"

Now clienta can exchange the token, including scope access-domainb, and restricting the audience to http://localhost:8080/realms/domainb (issuer of domainb).

curl -s -X POST \
  --location http://localhost:8080/realms/domaina/protocol/openid-connect/token \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "client_id=clienta" \
  --data-urlencode "client_secret=XXXXXX" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
  --data-urlencode "scope=access-domainb"  \
  --data-urlencode "audience=http://localhost:8080/realms/domainb" \
  --data-urlencode "subject_token=$token1"

The resulting access token token2 will be a valid assertion for JWT Authorization Grant in domainb.

Create a Identity Provider to establish the trust relationship with domaina. In Identity providers, click the OpenID Connect v1.0 type.

Figure 15.7. Identity Provider for domaina

After creation, enable the JWT Authorization Grant option.

Create a confidential OpenID Connect client clientb with JWT Authorization Grant capability enabled. In the option Allowed Identity Providers for JWT Authorization Grant add the domaina Identity Provider.

Figure 15.8. Client for JWT authorization grant

To test the JWT Authorization Grant, the sample user created in domaina should be linked in domainb. You can just access to the account page in domainb:

The token2 obtained in Example request for Token Exchange will be a valid assertion for domainb. So, the clientb defined in domainb can send a JWT Authorization Grant with that token.

curl -s -X POST \
  --location http://localhost:8080/realms/domainb/protocol/openid-connect/token \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "client_id=clientb" \
  --data-urlencode "client_secret=ZZZZZZ" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \
  --data-urlencode "scope=profile" \
  --data-urlencode "assertion=$token2"

The response will contain a new access token issued by domainb.