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).