JWT Bearer Token Flow

[ylelocat]

Hi,

I need to implement an oauth 2.0 JWT Bearer Token flow such as the following:

http://help.salesforce.com/help/doc/...h_jwt_flow.htm

I imagine it is planned for a future release of Spring OAuth (I can see preparation via the spring-security-jwt module) but I could not locate a JWTBearerTokenGranter class of some sort in the current source.

Any ETA?

Thanks,

Yann Le Locat.

[ylelocat]

I think I'll just use a custom token granter using the custom-grant element of authorization-server and tap into the spring-security-jwt helper classes.

That's probably the way it was intended for this type of use case.

Yann Le Locat.

[Dave Syer]

The CloudFoundry UAA (https://github.com/cloudfoundry/uaa) has JWT tokens via an TokenEnhancer implementation, so I'd recommend going that way to start. I have some WIP for 1.1 that does it the same way.

[ylelocat]

Thanks for the link, I will check it out.

Just for information, I have created a custom JwtBearerTokenGranter with GRANT_TYPE set to jwt-bearer that utilizes the jwt helper classes and decodes/validates the JWT token (using hmac for now). I've used the custom-grant mechanism to plug it in my configuration file.

What I need though is for the iss field of the token to be the client_id but my custom token granter class is only called after the TokenEndpoint has ensured that there is a valid Authentication setup. So I ended having a basic authentication set up to get pass that but it is sort of defeating the purpose. I know I am missing something here.

Do I need to use a custom filter instead that decodes the token and sets the clientId/Authentication accordingly (via a custom Authentication object). But then what would the token granter do? Just check things like the assertion parameter although it was used in the filter? I'm getting a little mixed up here.

Basically I just want to decode/verify the token and set its client id to the current Authentication principal (although I haven't thought yet of the principal field in the token).

(This is for securing a REST API so that a token is granted when posting a valid Jwt token).

Yann Le Locat.

[Dave Syer]

I'm not sure I understand your use case then. I thought you just wanted the access token to be a JWT (issuer would be the auth server), but maybe you actually want to exchamge a JWT for an access token (hence the issuer would be the client). If that means the token endpoint needs to be secured using the incoming JWT and not basic auth, then I think what you said makes sense (i.e. it requires a custom auth filter - we could make on in the framework and that would be useful to others probably if you want to raise a JIRA ticket for a new feature), but I'm still a bit confused

[ylelocat]

Yes that's absolutely what I need to achieve.

1. Client creates a JWT token by using the relevant encryption technic and ends up with 7834rtdw8gr.43789hrd9w34.hrd9w3hr (dummy value for explanation purposes) .
2. Client sends the JWT to server /oauth/token?grant_type=jwt-bearer&&assertion=7834rtdw8gr.43789hrd9w34.hrd9w3h r
3. Custom filter validates the token and creates Authentication object that contains the iss token value as the name(/principal?).
4. JwtBearerTokenGranter generates an access token

The way I coded the responsibilities of 3 and 4:
- the jwt token is verified in 3 and it is enough to mark it as authenticated (valid secret/certificate)
- in 4 we need client id(iss) validation and role validation + access token generation.

Have I got the responsibilities right?

Yann Le Locat.

[Dave Syer]

Yes that sounds right. How does the JwtBearerTokenGranter get the client id? It should be in the AuthorizationRequest if you are doing a browser flow. That's the bit that still confuses me - you appear to be exchanging a JWT for an access token with no reference to a User anywhere. Maybe all you need to do is extract the iss field in the filter and make it into an Authentication (whose name property is the client id). Put that in the Spring Security context and it will be used by the TokenEndpoint.

[ylelocat]

Yes that's exactly it.

- filter verifies the token and builds a Jwt object, using jackson it parses the claims iss and uses it for an Authentication object that is marked as authenticated and set to the SecurityContext
- JwtBearerTokenGranter apart from being registered to be of grant_type jet-bearer in theory doesn't need to do much now, but I still make it parse the assertion parameter and still validates the Jwt token again. It's redundant I know. I'm not sure whether it should still do it in case the filter was not set up properly so as to guarantee that the Jwt token is still verified. Overkilled?

Yann Le Locat.

[Dave Syer]

How does the TokenGranter get the JWT assertion?

[ylelocat]

How does the TokenGranter get the JWT assertion?

The assertion is still an AuthorizationRequest parameter so the jwt token granter can get its value and rebuild/reverify a Jwt object from it. Is that what you meant?

Yann Le Locat.