0

Let's say, we're using an OAuth / OpenID Connect (OIDC) flow (in a Zero-Trust situation) to secure two APIs: ServiceA and ServiceB. To implement some of the functionality of ServiceA, it depends on Service B. ServiceA is calling ServiceB on behalve of the end user.

How would we deal with tokens in this situation:

  • The end user does not need to know that ServiceA is using ServiceB (implementation hiding)
  • The end user gets a token from an IDP, that both Services trust
  • The Services are developed by two separate teams in a large corporate enviroment, with Zero Trust. That means that ServiceB doesn't (completely) trust ServiceA.
  • The end user would authenticate at the IDP and pass the token to ServiceA.
  • ServiceA verifies the token with the IDP and the IDP checks the audience.

But now the hard part:

  • ServiceA wants to call ServiceB and let ServiceB know (Zero Trust) that it is doing so on behalf of the end user.
  • ServiceA cannot use the token it got from the end user, because that has ServiceA as an audience. ServiceB will not be able to verify that token.
  • We could use the same audience for both services (since we're all one company). However, in a typical corporate environment you could have hundreds of services and you don't want to put them all in the same audience.

A similar question has been asked on https://stackoverflow.com/questions/39839881/is-it-ok-to-pass-on-oauth-access-token-between-services, but that ignores the audience in the token.

0

Self-answering, after almost a year:

Apparently there is a new OAuth flow: the On-Behalf-Of flow.

It is introduced in RFC 8693

The basic idea is that Resource Server A can ask the Identity Provider for a token for Resource Server B, using the access token that was used to access Resource Server A.

Here are some articles that describe it:

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.