[Openid-specs-ab] Introspection Profile for OpenID Connect

[Justin Richer]

There's not a 1:1 relationship between the two tokens, especially if you 
consider that the access token might be refreshed or not expire, whereas 
the id token must expire. The ID token represents the auth event (and 
session, to an extent), whereas the access token represents delegated 
authorization to the user's profile information. You could return 
attributes about the authentication event that generated the access 
token from introspection, but it's important to remember that the access 
token isn't meant to be tightly bound to that authentication event. In 
fact, it's the entire point of OAuth to loosely bind the authentication 
to the access token and make the access token valid when the user isn't 
there anymore.

The ID token has a self-contained lifespan (expressed in the 'iat' and 
'exp' claims), and if you want to check the session validity, there's a 
different spec for that. I had proposed using introspection for session 
management a while back but it didn't catch on, so we've got Google's 
thing instead.

  -- Justin

On 09/13/2013 12:18 PM, mike at gluu.org wrote:
> Justin,
>
> Thanks for the reply.
>
> I guess if there is always a 1:1 relationship between access tokens 
> and id tokens, that works. It is a little counter-intuitive, because 
> an acr is an attribute of the authn transaction, not a user claim. So 
> it seemed to make sense to publish the acr in the JWT returned via 
> introspection on an access token.
>
> - Mike
>
>
> On 2013-09-13 11:10, Justin Richer wrote:
>> If you're talking about the ID Token (which I assume you are since
>> you're talking about using "token1" to log in), then the "acr" value
>> should be inside the ID token itself, which your app2 can parse.
>>
>> But why would the person pass the token to app2? Wouldn't app2 want
>> to start its own session with the user? I don't think you want people
>> to be able to sling ID tokens around between apps -- the 'aud' claim
>> would be wrong and it would need to be rejected anyway.
>>
>>  -- Justin
>>
>> On 09/13/2013 12:00 PM, mike at gluu.org wrote:
>>> Here is another clarification...
>>>
>>> Lets say I have two apps:
>>> 1. app1 - requires acr = http://gluu.org/authn/auth_level/1
>>> 2. app2 - requires acr = http://gluu.org/authn/auth_level/2
>>>
>>> I want SSO between two apps:
>>>
>>> 1) A Person tries to login to app1 (auth_level=1) => got token1
>>>
>>> 2) Then the Person tries to login to app2 with token1 . So app2 
>>> needs to introspect token1 to get auth_level to make sure it's 2 or 
>>> higher.
>>>
>>> Is this just out of scope of OpenID Connect ?  I thought the use of 
>>> acr was in Connect?
>>>
>>> thx,
>>>
>>> Mike
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab