[mitreid-connect] Access Token & Scope

[Yannick Béot]

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 listmitreid-connect at mit.eduhttp://mailman.mit.edu/mailman/listinfo/mitreid-connect
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150105/b81b1706/attachment.htm