[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
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 
>> 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 
>  http://lists.openid.net/mailman/listinfo/openid-specs-ab
>  http://tools.ietf.org/html/draft-richer-oauth-introspection
More information about the Openid-specs-ab