0

So here is what I am trying to do. I have a RESTFUl service that will be authenticated to with a bearer token. This same service uses another service that needs it's own bearer token. Initially I was planning to have my service (Call it Service A) get the bearer token and authenticate call this other service (Service B) when it needed to internally. That works fine except when I look at adding PATCH endpoints or other endpoints that will patch to endpoints on Service B. In order to do that I need the token to be passed back up to Service A so it can be used for a patch on Service B. Maybe this will explain it better:

  • Service A POSTS to endpoint /foo

    • the code called in endpoint /foo POSTS to endpoint /fee on Service B.

  • Service A PATCHS to endpoint /foo/1

    • the code called in endpoint /foo/1 PATCH to endpoint /fee/1 on Service B.

Both Service A and Service B use different oauth services and each need their respective tokens. The Service B token is needed in the PATCH call to Service B and must be passed in the header of Service A's /foo/1 PATCH yet Service A still needs it's own token.

I was thinking that Service A (My service) will still make use of the Authorization header as intended. Service A will then send the Service B token in it's /foo Response (using a different header besides Authorization). That token will then need to be collected and passed back to the Service A PATCH /foo/1. That is in-turn used to call Service B's /fee/1 PATCH.

Is this the best way to do this? It seems overly complicated.

Improve this question

1 Answer 1

Reset to default
2

The standard solution is like this:

  • Service A uses Client Credentials flow to get a token for Service B - the first time it is needed
  • Service A then caches this token for subsequent calls to Service B
  • When the Service B token expires, a 401 is received by Service A
  • Service A then uses the Client Credentials flow again, to renew the token
  • Service A then retries the API call with the new token

The Service B token is usually returned from an Authorization Server rather than from Service B itself

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

That makes perfect sense.
what if i want run service A to B in the context of user instead of client credential flow
Then use token sharing techniques so that each API receives the user identity in the access token. Each API will check for its own required scopes so you need to design scopes to enable this flow, eg 2 APIs might use the same scope if they are for the same business area.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.