OAuth 2 separate authentication from authorization for server-server API calls

Context

I'm attempting to design an access control solution for our company product(s) that has the following three properties:

customers can bring their own identity (from their IdP solution), aka we can federate with them for identity. This gives them full control of access and alleviates us of user management (a significant workload for our helpdesk right now!)
we can centrally control which products the customer can use, aka we manage authorization. This gives us peace of mind that we are not at risk of fraudulent use of products, and centralises operational workflows that are currently in isolated and expensive stove pipes.
we isolate our products from the vagaries of individual customers identity protocols, aka we operate through some form of hub or gateway that translates between customer-specific behaviour and our internal products. This ensures customers can be well supported across all products and only need interact with the gateway team, while our product teams also only have to interact with the gateway team and a single protocol implementation.

My current thinking is to support OpenID Connect (OIDC) / OAuth 2 protocols in the gateway service, with trust relationships between the customer IdP endpoint and our gateway being created out-of-band through sales / operations workflows, and trust relationships between the gateway and internal products being part of our development work in house.

The message flow then becomes:

Customer obtains identity token from their IdP (up to them how).
Customer presents identity token to our gateway service, receives access token for product(s), assuming they are authorised.
Customer presents access token to product(s) to obtain service.

NB: This is a similar design to the Gov.UK Verify identity solution, except that uses SAML assertions and a SAML federation of IdPs and RPs, and something we are familiar with as one of the IdPs involved..

I also have expectations of supporting protocol / token translation at a later stage (eg: SAML assertions -> OIDC tokens), or customers with proprietary identity provider mechanisms, and integrating our own IdP (AzureAD) for staff access.

So what's the problem?

It seems OIDC / OAuth 2 does not have existing flows that cleanly separate identity authentication and access authorisation across two systems (and indeed security boundaries) when there is no end-user, and it's not part of the design where there are users (all the diagrams have a single authorization server doing both tasks).

Most of our customers will be calling our service(s) from their back ends, there are no end-users or browsers present, so we cannot use the interactive OIDC flows that support id_tokens (or auth codes), we are left with client_credentials flow, and this only deals in access tokens.

Have I got this all wrong (is OIDC/OAuth the wrong approach)?

Should we translate access tokens from customers to other access tokens in the gateway (because they cannot create id_tokens)?

I am aware of draft standards for token exchange (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-14), would this help?

I would consider the JWT and/or SAML assertion grant types. These are designed to obtain an access token from your OAuth server using a token issued by a trusted third-party identity provider that has performed user authentication. This will result in an architecture that looks like this:

                                                                   (4) Look up prod-
                                                                      ucts           +------------+
                                                                        +----------->+            |
                                                                        |            | API/DB of  |
                                                                        |            |   products |
   +----------------+                                    +--------------+---+        |            |
   |      Some      |                                    |                  |        |            |
   |    Trusted     |            (3)JWT or SAML grant    |    Your OAuth    |        +---+--------+
   |      IDP       <--+          +--------------------->+      server      |            |
   |                |  |          |     +----------------+                  <------------+
   +---+------------+  |          |     |                +--------+------+--+     (5) Allowed products
       |               |  (1)     |     | (7) Access token        ^      |
       |             OIDC, SAML   |     | scoped for your APIs    |      | (6) Burn allowed products into
       |             or|other     |     |                         +<-----+ access token as claims
    JWT or SAML        |          |     |
(2) token intended+----+----------+-+   |                +------------------+              +----------------+
    for your OAuth|                 +<--+                |                  |              |                +<-----+
       | server   |      Some       |                    |                  |              |                |      |
       +---------->     Client      +------------------->+  Your gateway    +------------->+    Your APIs   |      ^  (11) Fine grained
                  |                 | (8) Attempt to     |                  |  (10) Attempt|                |      |  authorization using
                  |                 | access your APIs   |                  |  to access   |                +------+  claims in access
                  +-----------------+ with your access   +--+-----^---------+  APIs with   +----------------+         token
                                      token as proof of     |     |            access token
                                      authentication        |     |            that's been authorized to
                                                            +-->--+            an extent
                                                           (9) Course grained
                                                           authorization using
                                                           scope, URL & HTTP method

Between step 9 and 10, I'd probably convert the access token to a phantom token if you're not using the split token approach. This will prevent the clients from seeing stuff in your access token that is only required to be known to your own internal APIs.

Recommended topics

Hot tags