I'm trying to come up with an authentication/authorization system for what seems like a really simple scenario, but as far as I can tell it's virtually unsupported.

There are two parties, total; myself and someone else ("other"). I'm running a bunch of services with HTTP APIs that are reachable over the public Internet, and "other" wants to use them from their own systems. There are no browsers, no interactive sessions, no people at screens and keyboards to interact with anything, just two computers talking to each other. These are requirements and cannot be changed. Here's an illustration:

Authentication flow

I don't want each of my services to have to implement whatever mechanism is used to establish and validate "other"s identity; I want each service to use a standard mechanism (like a short-lived bearer JWT) and have something else (an authentication service? I hope that name is accurate) do the work of validating "other"s identity and translating it to that standard. This seems like widespread standard practice and I assume is not controversial or a problem.

Ideally, I would like to use an off-the-shelf hosted product for the authentication service, so I don't need to build it myself or worry about how to administer accounts, but as far as I can tell this is literally unsupported by the providers I've looked at (Okta, AWS Cognito, and Auth0) and may be entirely incompatible with OAuth 2.0 itself. There are no browsers and no interactive users, so grant types based on redirecting back and forth and user approval are right out, so I think that leaves password and client_credentials as the options. client_credentials can't actually authenticate other parties in any of these services; you have to add a trusted application that is treated as internal, which is not acceptable. password allows you to supply a user name and password, but in all of these services you still have to include the client credentials. Since these providers all work the same way, and it sounds like that is consistent with the OAuth 2.0 spec, I'm not sure if there's a solution for this that doesn't involve building my own authentication.

Is there a proper name for what I'm trying to do that would help me find solutions? Has anyone heard of any hosted products that solve this problem? As a fallback, is there some tricky way of using OAuth2 to do this?

  • See here. It is not the same, but looks similar. – mentallurg Dec 19 '20 at 5:00
  • Couldn't you use an API (shared secret) key sent with a HTTP header or as a query string parameter? – aventurin Dec 19 '20 at 16:47
  • It can't be a single secret shared among all "other" parties, we have to know the identity of who is communicating with us. – qid Dec 19 '20 at 18:46

OAuth 2 can solve your problem with its Client Credentials Grant (aka service-to-service or machine-to-machine flow).

As noted in the OAuth 2 specification the clients must be confidential, i.e. registered with some secret - exactly how this is done depends on the Authentication Service.

Perhaps Microsoft's workflow makes it clearer - the first half is the registration step (just need to be done once for each client).

Microsoft Client Credential Grant

For details see https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow. Here's a table is to help sync up terminology differences...

Your Terminology Microsoft Diagram OAuth 2 Terminology
External Application Web Server Client
My Code Web API Client

Here are some alternative Authentication Services below but they assume you already did the registration:

  • Keycloak. Also see this example. Keycloak is an open source Authentication Service developed by RedHat that you can host yourself.
  • Google.
  • It seems like this should work per the OAuth2 spec itself, but every provider I've looked at so far ties Client Credentials to an internal application, not an external party so you lose the ability to administrate properly. – qid Dec 19 '20 at 15:33
  • Both those links refer to an "application", and the Google docs explicitly say "your application"--but I'm interacting with a separate company or person, not an application, and certainly not my own. – qid Dec 19 '20 at 15:39
  • Updated my answer with Microsoft's client credentials flow that is a little clearer as it includes the registration phase. – HTLee Dec 20 '20 at 2:20
  • I'll have to investigate Microsoft further. Okta provides very poor administration for "applications", which are the only thing that can use client credentials grants; you can't add any additional facts or claims like an email address, and you might not be able to even control their permissions to custom scopes, so even if the grant works, their product's implementation makes it unusable. – qid Dec 20 '20 at 2:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.