Adding claims from the request when using client credentials

Help
, ,
1

I’m new to Auth0 so I apologize in advance if the question is too basic.
I’m trying to setup a service-to-service authentication using client-credentials-grant. Following the tutorial, I was able to get a token from /oauth/token but I need to add custom claims to the JWT before it gets signed. I created a hook to do that but I can’t figure out how to pass additional data in the payload of POST /oauth/token so that I can pick it up from the hook function.

The idea would be for the client to pass user roles (similar to the use of SAML assertions) in the request from the token so that they can be included before the signature.
Where can I add the additional data in a block like the one below?

{
    	"client_id":"xxxxxxxx",
    	"client_secret":"xxxxxxxxxxxxxxxxxxxxxx",
    	"audience":"https://myapp.com/api/public",
    	"grant_type":"client_credentials",
}
2

In general sending something controllable from the client and then proceed to include that information in an issued token warrants at least some further reflection because you’re letting the client exercise a significant level of control and in most situations this may actually be a security issue. In your particular situation, given the client has to perform client authentication and assuming that you will perform some validation on the data being sent from the client then you could argue it is acceptable and technically you should be able to do so because at this time any additional information/parameter in the request body will be surfaced at the hook in the context.body object.

Having said that, I would still question if this custom implementation could not be handled better by relying on the definition of scopes at the API level, authorizing the client application to those scopes and then letting the default behavior take care of the logic of including in the token only the scopes requested by the client application through the scope parameter.

3

Thank you @jmangelo, I managed to get it to work based on your feedback. Just to give some background: we already use Auth0 as our centralized mechanism for authentication in our front-end and we are implementing a B2B integration with a trusted partner. The partner’s application will be client facing and they will authenticate the end user using their own internal implementation which may vary from installation to installation. When we receive an API call from the partner’s application on behalf of an end user, we need the details of the user for audit trails, e-mails, etc.

4

Thank you @jmangelo, I managed to get it to work based on your feedback. Just to give some background: we already use Auth0 as our centralized mechanism for authentication in our front-end and we are implementing a B2B integration with a trusted partner. The partner’s application will be client facing and they will authenticate the end user using their own internal implementation which may vary from installation to installation. When we receive an API call from the partner’s application on behalf of an end user, we need the details of the user for audit trails, e-mails, etc.

5

Yes, given the dynamic nature of that information scopes would not apply. Having said that, due to the dynamic nature of that same information you may also require a lot of client credentials exchanges so I would still have some reservations. For example if the client application can be trusted to provide the right info on the exchange it could also be trusted to provide the right info alongside a regular client credential token directly to the API and that would reduce the number of exchanges.