<div dir="ltr"><div><div><div>Thanks for your reply.<br></div>As you underlined, the access token does not containe neither the user id nor the scopes.<br></div>So why are you using a signed JWT and not sending just the JTI (token identifier)? What is the benefit for MITREid Connect or the resource server?<br><br></div><br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 12:32 AM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>It's a tradeoff consideration: on the
one hand, you can pack more information into the token itself and
have it be fairly self-contained (apart from revocation status),
but then you have a big token and your protected resources need to
understand this structure to get the information out. Also, unless
you're also encrypting things, you're leaking information to the
clients that carry the tokens. On the other hand, you can pack the
bare information into the token (like an identifier) and have
everything available from a network call (introspection). This
lets you have very small tokens (given the limits of entropy for
security sake) but it requires more network access from the
protected resources. You can of course cache things, and most
protected resources are going to have pretty fast access to their
authorization server in most deployments. <br>
<br>
But in the end, it's a balance and a trade-off. With MITREid
Connect, we decided to allow for both, as you've discovered. We
decided to not put scopes into the token itself in order to keep
the size down and to keep information from leaking to the client.
For the same reason, we don't put the user id in it either. That
logic is all defined in a pluggable service:<br>
<br>
<a href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/f974f9513854a72adb8bc1d38cd0dfd13fc02965/openid-connect-server/src/main/java/org/mitre/openid/connect/token/ConnectTokenEnhancer.java" target="_blank">https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/f974f9513854a72adb8bc1d38cd0dfd13fc02965/openid-connect-server/src/main/java/org/mitre/openid/connect/token/ConnectTokenEnhancer.java</a><br>
<br>
Which means that it can be overridden and replaced with local
functionality. It might make sense to have this be a configurable
option: which claims to include inside the access token. If that
would work, please file an issue on GitHub to track it, and we
would welcome a pull request to add that functionality.<br>
<br>
-- Justin<div><div class="h5"><br>
<br>
On 1/4/2015 4:47 PM, Yannick Béot wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">
<div>
<div>
<div>Hi,<br>
<br>
</div>
Access tokens generated by MITREid Connect and transmitted
to the client are JWT tokens but do not contain scopes.<br>
</div>
<div>Therefore, resource server has to call the introspect URL
to fetch the scope.<br>
</div>
<div><br>
Since MITREid is using signed JWT, the resource server can
verify the access token.<br>
</div>
<div>So why not include the scopes?<br>
</div>
<div><br>
</div>
<div>Do you declare in MITREid Connect the client application
and the resource server, the client application with no
introspection right, the resource server with introspection?<br>
</div>
<div><br>
</div>
<div>Best regards,<br>
</div>
<br>
</div>
<div>Yannick Béot<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
mitreid-connect mailing list
<a href="mailto:mitreid-connect@mit.edu" target="_blank">mitreid-connect@mit.edu</a>
<a href="http://mailman.mit.edu/mailman/listinfo/mitreid-connect" target="_blank">http://mailman.mit.edu/mailman/listinfo/mitreid-connect</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div>