[mitreid-connect] Access Token & Scope

[Justin Richer]

There are several main benefits. The first is for a PR that doesn't use scopes, it can just check the signature and make sure it cones from the AS it expects. It can also verify the expiration and other tune attributes directly. The second is for a PR.that talks to multiple AS. The PR can check the issuer field and signature to determine which AS it wants to talk to to do introspection. 

In the end, it's a belt and suspenders approach, and one we've always designed to be pluggable. 
-- Justin

/ Sent from my phone /


-------- Original message --------
From: Yannick Béot <yannick.beot at gmail.com> 
Date:01/05/2015  3:31 AM  (GMT-05:00) 
To: Justin Richer <jricher at mit.edu> 
Cc: mitreid-connect at mit.edu 
Subject: Re: [mitreid-connect] Access Token & Scope 

Thanks for your reply.
As you underlined, the access token does not containe neither the user id nor the scopes.
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?




On Mon, Jan 5, 2015 at 12:32 AM, Justin Richer <jricher at mit.edu> wrote:
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. 

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:

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

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.

 -- Justin


On 1/4/2015 4:47 PM, Yannick Béot wrote:
Hi,

Access tokens generated by MITREid Connect and transmitted to the client are JWT tokens but do not contain scopes.
Therefore, resource server has to call the introspect URL to fetch the scope.

Since MITREid is using signed JWT, the resource server can verify the access token.
So why not include the scopes?

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?

Best regards,

Yannick Béot


_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu
http://mailman.mit.edu/mailman/listinfo/mitreid-connect


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150105/dac9d0e3/attachment-0001.htm