[mitreid-connect] Access Token & Scope

[Yannick Béot]

There is one last thing to note: the scope claim is not registered/standard.
Therefore, for instance, Connect2id (
http://nimbusds.com/blog/self-contained-access-tokens-in-connect2id/) and
Microsoft Azure AD (
https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/master/src/System.IdentityModel.Tokens.Jwt/ClaimTypeMapping.cs)
is apparently using the claim "scp" to store the scopes.

Perhaps the 33rd draft of JWT will standardize the scope claim...

In any case, perhaps a "Self-contained access token" checkbox in MITREid
Connect's interface makes sense. In this case, MITREid would generate an
access token with sub, user_id? and scope claims.
What do you think?

Yannick

On Mon, Jan 5, 2015 at 12:49 PM, Justin Richer <jricher at mit.edu> wrote:

> 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 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/695de249/attachment.htm