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, 2020 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, 2020 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, 2020 at 18:46
  • Old post but if you don't want to use client credentials, there is another option namely mutual TLS, which authenticates clients using only publicly available information i.e. Client's X509 certificate without any trusted system sharing secrets. But your application server still needs information on what scopes can be allowed for which clients. Sep 16, 2021 at 6:45

1 Answer 1


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, 2020 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, 2020 at 15:39
  • Updated my answer with Microsoft's client credentials flow that is a little clearer as it includes the registration phase.
    – HTKLee
    Dec 20, 2020 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, 2020 at 2:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .