Hi all,

I've followed the following on how to create a JWT as an access token rather than an opaque access token.

https://www.ibm.com/blogs/security-identity-access/oauth-jwt-access-token/

This is working well, however, when I use the refresh token to get a new token, I lose all the claims in the new JWT. Has anyone looked at this and found out a way to get the original claims in the new refreshed JWT?

I'm at v 9.0.7.1 right now, do you think with Security Verify Access 10 they will soon support native JWT for the OAuth flows? I know they support it as far as passing a JWT on the header per junction, but I don't think that would work for the Oauth flows.

Thanks,
Scott

------------------------------
Scott Reichardt
------------------------------

Hi Scott,

When the refresh token is presented, the only data available at /token is the refresh token, whatever data is associated with the grant (state_id) that this token links to, and anything you can lookup with HTTP callouts or lookup into the user directory.

If you want information that was included in the original JWT to be added to the new JWT at refresh time, you can store that data in the grant during the initial grant flow.  You can then read it out again when processing a refresh token to add it into the new JWT.

There are examples of looking up the stateId and storing and retrieving attributes from the grant in the default pre- and post- token mapping rules.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Thanks, Jon. I'm not finding in the pre or post token mapping rules where the processing of the refresh token happens in order to modify it to read out the data. Is that in one of these mapping rules?

Scott

------------------------------
Scott Reichardt
------------------------------

Original Message:
Sent: Thu June 25, 2020 04:49 AM
From: Jon Harry
Subject: OAuth JWT as access token - Refresh token question

Hi Scott,

When the refresh token is presented, the only data available at /token is the refresh token, whatever data is associated with the grant (state_id) that this token links to, and anything you can lookup with HTTP callouts or lookup into the user directory.

If you want information that was included in the original JWT to be added to the new JWT at refresh time, you can store that data in the grant during the initial grant flow.  You can then read it out again when processing a refresh token to add it into the new JWT.

There are examples of looking up the stateId and storing and retrieving attributes from the grant in the default pre- and post- token mapping rules.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------