OIDC extension not releasing refresh token

[Wessel, Keith]

Thanks very much, Henri. It was, in fact, the lack of the offline_access scope which, in hindsight, makes a lot of sense for refresh tokens.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Henri Mikkonen
Sent: Tuesday, September 8, 2020 7:12 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: OIDC extension not releasing refresh token


> On 4 Sep 2020, at 20.04, Wessel, Keith <kwessel at illinois.edu> wrote:
> 
> I'm helping the IdP operator from another of our campuses integrate with a mobile app that's already working with our IdP. When the client hits the other IdP's token endpoint, it gets back an access token and an ID token, but it gets not refresh token. It gets a refresh token from our IdP, just not from the other campus's IdP.
> 
> The only difference between our integration and theirs is that, for us, the client dynamically registered while it was manually added to the IdP on the other campus.
> 
> We've check the IdP configuration, and we aren't explicitly disabling refresh tokens per profile configuration predicate. I'm at a loss as to why else the refresh token wouldn't be included.

If the refresh tokens are enabled in the profile configuration (as you say), then I’d check the following two things:

Is ‘offline_access’ included in the list of scopes for the RP metadata (the space-delimited list of strings on the JSON metadata for this RP)

Is ‘offline_access’ scope requested by the RP during the login sequence? (scope -parameter in the request for the /idp/profile/oidc/authorize -endpoint)

> The dynamic client registration against our IdP only has a response type of "code" set. Just for the heck of it, I had the other campus's IdP operator add id_token and token to the list of response types in the manually registered client metadata. This caused other errors from the IdP:
> 
> Profile Action ValidateResponseType: The response type id_token token is not registered for this RP

Umm, the value “id_token token” in that log-line refers to the value being requested by the RP. So, it sounds like they added “id_token token” to the RP configuration, not to the RP metadata on the IdP?

Anyway, you don’t need to add id_token or token response types in order to get the refresh tokens. ‘code’ is needed, as refresh tokens are possible only with authorization code and hybrid flows.

BR,
Henri.
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net