title: OAuth 2 separate authentication from authorization for server-server API calls
body: <p><strong>Context</strong></p>
  <p>I'm attempting to design an access control solution for our company product(s) that has the following three properties:</p>
  <ul>
  <li>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!)</li>
  <li>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.</li>
  <li>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.</li>
  </ul>
  <p>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.</p>
  <p>The message flow then becomes:</p>
  <ul>
  <li>Customer obtains identity token from their IdP (up to them how).</li>
  <li>Customer presents identity token to our gateway service, receives access token for product(s), assuming they are authorised.</li>
  <li>Customer presents access token to product(s) to obtain service.</li>
  </ul>
  <p>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..</p>
  <p>I also have expectations of supporting protocol / token translation at a later stage (eg: SAML assertions -&gt; OIDC tokens), or customers with proprietary identity provider mechanisms, and integrating our own IdP (AzureAD) for staff access.</p>
  <p><strong>So what's the problem?</strong></p>
  <p>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) <strong>when there is no end-user</strong>, and it's not part of the design where there are users (all the diagrams have a single authorization server doing both tasks).</p>
  <p>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.</p>
  <p>Have I got this all wrong (is OIDC/OAuth the wrong approach)?</p>
  <p>Should we translate access tokens from customers to other access tokens in the gateway (because they cannot create id_tokens)?</p>
  <p>I am aware of draft standards for token exchange (<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-14" rel="nofollow noreferrer">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-14</a>), would this help?</p>