The spec states that `refresh_token` SHOULD NOT be used

[meghnadubey]

The spec currently states that, refresh_token SHOULD NOT be used. I also saw that there is an old closed issue with the comment:

Instead we'll recommend using the refresh token to get a new ID token.

Is that decision final, because I do have some security concerns with using refresh_token for an id-jag and it also seems to be discouraged by RFC 8693, that states:

A refresh token will typically not be issued when the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context.

[mcguinness]

Unfortunately there isn't a great solution for RPs that use SAML for SSO and don't want to migrate over to OIDC (aka that majority of SaaS live today). They won't be able to obtain new ID-JAGs once the SSO assertion lifetime expires and would need to redirect back on front channel to IdP to get a new SAML Assertion. Its unclear if this be acceptable from a user experience perspective which is why recommendation is currently SHOULD NOT.

[meghnadubey]

Thank you for providing the background for that decision. That makes sense.

[mcguinness]

Should we consider having clients convert a SAML2 assertion to a IdP-specific refresh token with Token Exchange for client deployments that need to obtain new ID-JAGs when a Resource App's access token expires?

POST /oauth2/token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token_type=urn:ietf:params:oauth:token-type:saml2
&subject_token=PHNhbWxwOl...[base64url-encoded SAML2 Assertion]...
&requested_token_type=urn:ietf:params:oauth:token-type:refresh_token
&audience=https://acme.idp.example
&scope=openid%20offline_access
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0...

The IdP would need a way to map the SAML2 audience entityID to a OAuth2 client to ensure its the same "RP". This would provide a mechanism to slowly migrate a RP over to OIDC even though the initial SSO was SAML. SSO/AppAdmins don't need change SSO configuration but instead just link the SAML SP to a OAuth Client.

Once the client obtains the refresh token they can perform a token request and get a new id_token and access_token. This simplifies the story going forward as everything is id_tokens.