[mitreid-connect] JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

Wed Aug 5 07:33:23 EDT 2015

Who said we would trust any unsigned JWT token? It's obvious that only recognizable issuers and signed by somebody we trust, perhaps even encrypted, JWT tokens should be processed.

________________________________
From: Justin Richer <jricher at mit.edu>
Sent: Tuesday, August 4, 2015 8:02 PM
To: Luiz Omori
Cc: mitreid-connect at mit.edu
Subject: Re: [mitreid-connect] JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

We implemented what's there in order to have a way to refresh ID tokens and do some very weak session management. It was never widely used and we didn't push the implementation beyond that because there was no demand for it.

To use the assertion properly (which I still don't think you need in order to do what you're trying to do), you need to figure out not only how to process the assertions but also which assertions you trust. You really can't just take in any old assertion that's inbound and mint a token based on what's inside -- that's nuts and wildly insecure. You can only trust assertions from trusted providers with the appropriate attributes in place, and that are cryptographically protected. So there's a lot more than jus treading the mandatory fields here, unless you want a security hole the size of asia in your code.

 -- Justin

On 8/4/2015 5:07 PM, Luiz Omori wrote:
OK.

Back to the JWT Assertion grant type, why is the existing and incomplete code expecting an ID token previously generated by MitreID? Isn’t it just a matter of generating one, and a new access token, based on the information in the mandatory (for this flow) JWT token fields (e.g. sub) and request parameters (e.g. scope)?

Regards,
Luiz

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Thursday, July 30, 2015 at 5:08 PM
To: Luiz Omori <<mailto:luiz.omori at dm.duke.edu>luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "<mailto:mitreid-connect at mit.edu>mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

You don’t need to use a structure auth code in that case, since the clients aren’t generating it it can be an opaque random value.

However: in that case, your clients aren’t using the strongly recommended ‘state’ field and are susceptible to cross-site scripting attacks and session fixation attacks. Much better to use something like the OpenID Connect “third party login” function which starts the OAuth process from the client side. You basically go to a URL on the client app that says which issuer to start the process with.

 — Justin

On Jul 30, 2015, at 4:14 PM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

They are being launched straight through the redirect_url. Basically they think that they got an authorization_code and will exchange it by an access_token. I agree, we will have to re-think this scenario as it’s getting too “deviant”.

Regards,
Luiz

From: Justin Richer <<mailto:jricher at mit.edu>jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Thursday, July 30, 2015 at 4:04 PM
To: Luiz Omori <<mailto:luiz.omori at dm.duke.edu>luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

If they’re doing grant_type=code, then they’re not doing the JWT Assertion grant type. It sounds to me like you’re possibly conflating the two types. You can have different clients doing different grant types, so I don’t see what the issue would be implementing the new type. What kind of clients do you have that think they’re doing the code flow but need the assertions flow?

 — Justin

On Jul 30, 2015, at 4:00 PM, Luiz Omori <<mailto:luiz.omori at duke.edu>luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Thanks. A problem for us to implement another flow is that some external clients are doing grant_type=code for this scenario.

Regards,
Luiz

From: Justin Richer <<mailto:jricher at mit.edu>jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Thursday, July 30, 2015 at 3:50 PM
To: Luiz Omori <<mailto:luiz.omori at dm.duke.edu>luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>, "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <<mailto:mitreid-connect at mit.edu>mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

We do have an issue to support this grant type, but no immediate plans:

<https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/616>https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/616
<https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/411>https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/411

The correct way to implement this is not to coopt the Authorization Code flow but rather to implement a new handler for it specifically. What you're doing right now is very off-spec, and I wouldn't recommend it. We've got the hooks in place for supporting the assertion processing (see the above issues) but we don't yet have all the processing to do it.

We'd be happy to take a pull request to add this functionality, assuming that it didn't break any of the other grant types.

 -- Justin

On 7/30/2015 3:46 PM, Luiz Omori wrote:
Hi,

We have an use case for exchanging a JWT by an access_token, exactly how is described by JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (<http://tools.ietf.org/html/rfc7523>http://tools.ietf.org/html/rfc7523). Basically SSO for us. We did some prototyping replacing the defaultOAuth2AuthorizationCode by a class that extends it and also recognizes trusted JWTs (consumerAuthorizationCode). The parameters necessary to create an OAuthAuthentication object are coming from from the trusted JWT and application registration DB. This appears to be working as expected, the only thing is that the grant_type has to be “code” instead of "urn:ietf:params:oauth:grant-type:jwt-bearer” as defined in the RFC for this flow.

Thoughts? Any plans to support this grant type?

Regards,
Luiz

_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu<mailto: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/20150805/8982a7aa/attachment-0001.htm