I need to secure access to an API that will be consumed by untrusted 3rd party service. My current investigations have lead me to using grant_type=“client_credentials” however this flow seems to be only for Machine to Machine (MTM) connections where the client is trusted.
I can understand why: If I use this flow, with HS256, then I can see an obvious security flaw: the JWT is signed using a shared symmetric key. This means there is nothing stopping the 3rd party generating and signing their own JWT tokens using this key and circumventing the authentication server entirely. If I use RS256 however, this flaw doesn’t exist as the untrusted party only has access to the public key, so they can’t create their own signed JWTs.
My main question is: Is this the correct way to go for my use case, or is there a different OAuth flow I should be using here?
Yes I’ve been through those guides. I’ve set up an API as a 3rd party application in Auth0 by using the management API and setting “is_first_party”: false, however this appears to behave exactly the same as the first party apps I’d already created. By this I mean, I can request a token from the token endpoint using a client id & secret and also that I can access resources secured with both HS256 and RS256 (I’d expect HS256 to be not supported for 3rd parties based on reasoning in my original post).
From your documentation it states:
“Third-party applications cannot skip user consent when consuming APIs. Because anyone can create an application, requiring a final user to provide consent improves security.”
This seems wrong on two accounts, firstly, for MTM communications, there should not be any user interaction involved, so user consent cannot be a prerequisitie, and secondly, it doesn’t appear to be true because as I mentioned, the 3rd party app I created in Auth0 can authenticate in exactly the same method as the first party one.
I expect there’s something I’m missing here, please can you explain the interactions involved in a 3rd party machine to machine authentication journey in a bit more detail? To be clear, I’m talking about a 3rd party back end system that has no UI that needs to connect to our API.
The main OAuth 2.0 specification covers four grant types and these can be split in two groups depending if there’s an end-user involved or not:
implicit, authorization code and resource owner password credentials for the cases where the client applications will access the resources on behalf of an end-user.
client credentials for the case where the client application access the resources under the control of the application itself or resources owned by end-users, but for which access has been granted directly to the application.
From your last sentence in the most recent reply:
I’m talking about a 3rd party back end system that has no UI that needs to connect to our API.
it seems your scenario falls within the client credentials grant scenario given you mention it’s a back-end system and in neither of your messages you make a specific reference to the existence of end-users.
If the above assumption is right then you would likely have the following setup:
register your custom API in the APIs section of your dashboard; you could either configure the API to use HS256 or RS256. The difference with HS256 would be that the API would have to know the shared secret, but from your description the API is within your control so that would lead to the issue you mentioned.
register a third-party client application configured solely for the client credentials; given that the toggle for first party or not is not surfaced in the dashboard you would at least need to call the Management API once to set that to be a third-party application.
allow the configured third-party client application to request access tokens for your custom API; this could be done in the Machine to Machine Applications section of the custom API settings.
Having completed the above the untrusted third-party entity would be provided with the client credentials that would allow them to perform a client credentials grant associated with the custom API (audience parameter). The result of executing this grant would be an access token which at this time makes use of the JWT format, but that is merely because that’s the only format we currently support to be issued (more formats can be supported in the future).
That access token (using the JWT format) will be signed in accordance with either the tenant private key (RS256) or the custom API signing secret (HS256) and neither of these would be accessible to the third-party entity.
The third-party entity would then call your API with the JWT access token and the API would validate it accordingly. In conclusion, you’ll make use of third-party applications, but it’s one that will only make use of client credentials grant so some of the documentation does not apply (for example, the consent part is for end-user flows performed by a third-party application which is not in scope of this scenario).