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

Justin Richer jricher at mitre.org
Fri Sep 13 14:28:53 UTC 2013


To add to what John said, the basic reasoning is that the only protected 
resource defined in Connect is the UserInfo Endpoint, which is going to 
be under control of the IdP. The IdP can partition that off from the 
auth server however it wants to, and many times it's in the same box so 
you don't need structured tokens or introspection. If you want to, your 
IdP can use structured tokens, introspection, or both to connect them. 
You can also use these techniques to allow for additional protected 
resources to be tied into the auth server.

Note that this all concerns the access token. The ID Token, on the other 
hand, is defined by Connect to be a signed JWT with a clear process for 
verification by the client. Since this token isn't meant to be opaque to 
the client, and it carries the relevant information inside of it, you 
just need a JWT processor and not an introspection endpoint to important 
stuff out of it.

So you don't *need* introspection to do OIDC, just like you don't *need* 
it to do OAuth2, but you can implement it as a (quite useful) 
complementary function.

In MITREid Connect, we actually implement the introspection draft as 
well as issue signed JWTs from the server. This lets us set up the 
server to a bunch of different protected resources that have decided 
(through whatever means) to trust the auth server. It's also let us set 
up systems that are federated with each other: if you get a token, parse 
it to find its issuer. If the issuer is someone you trust (ie, it's on a 
list of URLs), do introspection on it with that issuer to make sure it's 
still valid (and to find out scopes and stuff). Most of our clients, 
RPs, and PRs parse the ID tokens and introspect the access tokens, but 
the way our server's implemented, you can actually do introspection on 
any kind of token that gets issued: access tokens, id tokens, refresh 
tokens, registration access tokens, and anything else that gets issued. 
When we eventually implement the full UMA protocol, you'll get the 
introduction steps too -- but that's not in quite yet.

  -- Justin

On 09/12/2013 11:42 PM, John Bradley wrote:
> Connect specifically allows any OAuth token type and token verification method to be used for the RS/user_info endpoint.   Typically it is controlled by the same entity that controls the AS if unstructured tokens are used.   Many people are using JWT as access tokens and those don't typically require introspection.
>
> UMA has a much more complex authorization model than OAuth so it  needs a fairly complicated introduction and introspection.   Connect can live with that if that is what the IdPwants to do.
>
> There is also a introspection draft http://tools.ietf.org/html/draft-richer-oauth-introspection
>
> Introspection of access tokens is currently out of scope for Connect.
>
>
> On 2013-09-12, at 1:34 PM, mike at gluu.org wrote:
>
>> OpenID Connect Gurus,
>>
>> I was wondering why there is no introspection endpoint defined by OpenID Connect. UMA has a profile for this. Am I missing something? How else could you get information about a bearer token?
>>
>> - Mike
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130913/25ccf154/attachment.html>


More information about the Openid-specs-ab mailing list