[Openid-specs-ab] Refreshing ID Tokens

Torsten Lodderstedt torsten at lodderstedt.net
Sun Jul 29 21:25:05 UTC 2012

Hi Nat,

my assumption is that an app uses the code flow for initial login. 
Afterwards, it uses the refresh token during subsequent app startups to 
obtain fresh user data. I would assume it to query user info and obtain 
a new id token. So in my interpretation, the refresh token is merely a 
persistent cookie representing a long-term login.

One thing came into my mind: Since an app is typically _not_ attached to 
a web SSO session, all id tokens created based on a particular refresh 
token would contain the same data (of the intial authentication 
transaction). So the id token might only be useful during intial login 
to prevent token substitution and to check the user_id  obtained from 
user info. Fresh user data can be obtained purely based on the access token.

Is this the way you envision usage of connect for apps?


Am 29.07.2012 22:43, schrieb Nat Sakimura:
> Could you kindly elaborate the use case a bit more please?
> The rationale for not having refresh token equivalent for id_token was
> to make sure that the user is   in presence and bound to the session.
> How do you envisage the same in the context of the app in your
> usecase?
> Nat
> On Mon, Jul 30, 2012 at 4:43 AM, Torsten Lodderstedt
> <torsten at lodderstedt.net> wrote:
>> Hi all,
>> the standard spec only mentions refreshing access tokens. I'm wondering
>> whether it is possible to refresh an ID Token based on a refresh token or
>> whether this always require a request to the authorization endpoint. In my
>> opinion, using offline refresh tokens for this purpose would be a valueable
>> feature for apps.
>> regards,
>> Torsten.
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab

More information about the Openid-specs-ab mailing list