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

[Justin Richer]

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 <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 <jricher at mit.edu <mailto:jricher at mit.edu>>
> Date: Thursday, July 30, 2015 at 3:50 PM
> To: Luiz Omori <luiz.omori at dm.duke.edu <mailto:luiz.omori at dm.duke.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
> 
> 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 <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 <http://mailman.mit.edu/mailman/listinfo/mitreid-connect>

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