<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 09/12/2013 11:42 PM, John Bradley
wrote:<br>
</div>
<blockquote
cite="mid:271E5C5A-1671-4EB2-8137-D2A62054FEA1@ve7jtb.com"
type="cite">
<pre wrap="">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 <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-richer-oauth-introspection">http://tools.ietf.org/html/draft-richer-oauth-introspection</a>
Introspection of access tokens is currently out of scope for Connect.
On 2013-09-12, at 1:34 PM, <a class="moz-txt-link-abbreviated" href="mailto:mike@gluu.org">mike@gluu.org</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>