That’s how we’ve implemented it, but I’ve seen others pass the JWS for the token directly using the assertion grant type. Personally I find that a little confusing, since it’s still the client making the swap, but maybe there’s something useful there anyway. It honestly feels a bit too much like WS-*, and one can hope that we’ve learned from the mistakes of the past by now.
I think the difference may be who makes the JWS. If the client is making the JWS and using it to swap for a new token, then that’s a case for using client credentials and authenticating using the JWS. If the JWS is coming from a third party and being handed to the client, and the client’s using that as-is to swap for a new token, then that’s a case of using the JWS as an assertion directly to the AS and getting a token there. But I agree that it’s confusing that there are two similar mechanisms here. — Justin > On Sep 15, 2015, at 2:09 PM, George Fletcher <gffle...@aol.com> wrote: > > Hi, > > I just want to verify my reading of RFC 7523[1] for the use case where a > client wants to get an access token for itself to use as authorization for > future API calls. This is effectively exchanging a JWS for a "short lived" > access token. > > My understanding of section 2.2 of RFC 7523, is that the > 'client_assertion_type' and 'client_assertion' replace the default [OAuth2 > (RFC 6749)] client authentication mechanism of client_id and client_secret. > > Therefore the correct way to implement this 2 legged flow is to use the > OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with the JWT > Bearer defined client_assertion_type and client_assertion. > > This would look something like (line breaks added for readability) > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=client_credentials& > client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer& > client_assertion=<encoded JWS>& > scope="myscopes" > Is there a different industry standard for this use case? I'm checking as I > find that multiple AS implementations do this differently:) > > Thanks, > George > [1] https://tools.ietf.org/html/rfc7523 <https://tools.ietf.org/html/rfc7523> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
