[Openid-specs-ab] Introspection Profile for OpenID Connect
jricher at mitre.org
Fri Sep 13 16:58:08 UTC 2013
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
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
On 09/13/2013 12:18 PM, mike at gluu.org wrote:
> 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
>>> Is this just out of scope of OpenID Connect ? I thought the use of
>>> acr was in Connect?
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab