Identity Propagation / Security Token Enrichment

[savio.a.mascarenhas]

Hello team,

I am seeking direction to how to correctly implement Identity Propagation / Security Token Enhancement as described in the attached Identity Propagation / Security Token Enrichment diagram.

The flow (in the attached diagram) is described as follows:

1. The user requests a particular functionality via browser.
2. The Browser requests that piece of information to the web application A.
3. The Web application resolves that the user is not authenticated, so it redirects the user agent to the IdP
4. The browser request the authentication page to the IdP
5. The page is returned and presented to the user.
6. The user sees the page
7. The user enters username and password
8. The Browser sends the username and password to the IdP
9. The IdP authenticates the user and grants the claim to access to A.
10. The IdP redirects a auth code to the Application A via user-agent.
11. The browser redirects the auth code to the application A
12. The application A exchanges the auth code received by an access token of the user that contains the Claim A (as per 9)
13. The IdP returns the access token with claim A (id_token_A
14. The application executes the piece of information required by the user (feature A), but,
15. to be completed, application A has to call another application (API B)
16. In order to access to API B, A needs another access token. It requests that access token to IdP sending the existing access token (id_token_a) and its own credentials (A client id, client secret, for example).
17. IdP issues the new token, that contains the claims of the previous token (user info, Claim A) plus the new Claim B in order for A to access B. New token = Claim A + Claim B
18. A calls API B with the new token.
19. B accepts the request (because it contains claim B), and realises that it requires access to API C to reply back.
20. B, then, requests another access token to the IdP, sending the previous token (A+B), and identifying itself (with B client id, client secret, for example).
21. IdP replies with the new token, that contains the claims of the previous token (user info, Claim A, Claim B) plus the new Claim C in order for B to access C. New Token = Claim A + Claim B + Claim C
22. B calls C with the new token.
23. C verifies that the token contains Claim C, and returns back the information requested (response C)
24. B receives it, and returns back to A the information requested (response B)
25. A receives it, and returns back to the browser the HMTL with the feature requested at 1
26. the user sees the information

NOTES:
■ The model described here has the characteristic of not having to grant in advance the Claim B and Claim C to the end user. This simplifies the model in the IdP to grant access to services, not having to grant claims considering all the path of the request, and just only focusing in service boundaries (just grant access to the consumer to access a provider).
■ The need of including the previous claims of the token also has the advantage of enabling the possibility to use the user claims and previous claims as part of the processing logic of the chain of services. For example, if the user claim issued in 13 (with Claim A) contains a kind of “AccountID=1234”, then that accountID can be used as part of the business logic of, for example, API C to access to the account information. This mechanism is more secure than including AccountID in the payload of the message as the “AccountID=1234” comes from a trusted source (IdP).
■ The steps where the apps verify the claims contained in the tokens SHOULD also verify the authenticity of the token, by verifying the token signature.

Please advise if steps #17 and #21 is supported in the Auth0 Platform.

Thanks.
Savio