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

John Bradley ve7jtb at ve7jtb.com
Fri Sep 13 16:57:34 UTC 2013

Many people use short lived JWT access tokens and long lived refresh tokens.   

The design of OAuth 2 was intended to allow RS to not be required to introspect tokens though they can if they want to.

In some use cases the RS cannot introspect tokens due to security zone issues.  

Token introspection is optional in OAuth.
On 2013-09-13, at 8:51 AM, mike at gluu.org wrote:

> 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130913/8153e45a/attachment.p7s>

More information about the Openid-specs-ab mailing list