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

mike at gluu.org mike at gluu.org
Fri Sep 13 15:51:51 UTC 2013


It seems like you would at least want to know that the token was 
active. For example in 
http://tools.ietf.org/html/draft-richer-oauth-introspection-04 -

2.2.  Introspection Response

    The server responds with a JSON object [RFC4627] in "application/
    json" format with the following top-level members.  Specific
    implementations MAY extend this structure with their own service-
    specific pieces of information.

    active  REQUIRED.  Boolean indicator of whether or not the presented
       token is currently active.




On 2013-09-13 09:28, Justin Richer wrote:
> 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 [2]
>> 
>> 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 [1]
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab [1]
> 
> 
> 
> Links:
> ------
> [1] http://lists.openid.net/mailman/listinfo/openid-specs-ab
> [2] http://tools.ietf.org/html/draft-richer-oauth-introspection


More information about the Openid-specs-ab mailing list