Receiving non JWT access and refresh token in authorization code flow

Troubleshooting
, , , ,
#1

We want to setup our WilfFly 29 elytron-oidc-client adapter with forgerock.

These steps work out well:

  1. User open link to our servers oidc endpoint
  2. User is forwarded to loginpage of OIDC Provider
  3. User logs in at provider
  4. User is sent back to us with authorization code
  5. Our server sends token request with authorization code to OIDC provider
  6. Our server receives 3 Tokens (access, refresh and id token)

From now on we get in troubles as internal validation of access and refresh token fails as they are not JWT Tokens (only one segment in them instead of 3 or 5).

How to avoid receiving those non JWT Tokens? We only need the ID Token.

Best, Jörg

#2

So we’re here on this step:

grafik
grafik843Ă—678 105 KB

#3

I don’t believe you can completely disable access tokens, as they are issued as part of the OIDC specification for auth code grants. However, you can configure your access and refresh tokens as JWTs on either the service or client level. That should allow them to work in your scenario. Additionally, you should be able to disable refresh tokens entirely, also on the service or client level.

To do this on the client level, you go into “OAuth2 Provider Overrides” in the client settings and enable “Use Client-Side Access & Refresh Tokens”. To disable refresh tokens, uncheck the “Issue Refresh Tokens” option on the same screen.

#4

Thanks for your remarks. As we work with a different client (elytron oidc client for wildfly 29 server) we’re not able to override the options on client side.

Can you tell me how to change the setup of the ForgeRock server to issue JWTs access and refresh tokens?

Thanks a bunch,
Jörg

#5

The instructions I provided are to update the configuration in ForgeRock. However, in ForgeRock, you have both a service level configuration and a client level configuration (which overrides the service level configuration for specific client definitions).

I provided the client level configuration, which should avoid changing the way tokens work for your other clients. FWIW, if you can, you may wish to issue JWT access tokens by default on the service level anyways, as that seems to be the way that everyone is going.

2 Likes
#6

thanks matthew - as we do not maintain the ForgeRock service by our selfes I didn’t get it in the first place - will forward this info. thanks again

2 Likes