Avalados por :
Understanding Token Exchange and Client Credentials: A Detailed Comparison
- Creado 01/03/2024
- Modificado 01/03/2024
- 8 Vistas
0
Cargando...
You heard about token exchange and would you like to have a closer look into why it is useful and how it works?
In this blog post we create a simple example scenario and verify the difference between token exchange and client credentials.
0. Introduction
1. Token Exchange Scenario
2. Native Code Sample
3. Client Credentials Scenario
Appendix 1: Token Exchange Scenario Sample
Appendix 2: Client Credentials Scenario Sample
Next blog post : using destination
Next blog post : multitenancy example
The example scenario
We have a user-centric frontend-application that calls a backend-application via HTTP:
Both apps are protected with OAuth and are bound to an instance of XSUAA.
The frontent-app uses an approuter to handle the user-login (means to fetch a JWT token for the user). All endpoints require a JWT token.
Below diagram shows the token flow in detail:
1)
The end user opens the main app entry point which is the approuter URL.
Approuter handles the communication with XSUAA, to present a login screen.
After entering correct credentials, a JWT token is issued.
This token is specifically for the user and for the frontend application.
2)
Approuter forwards the call and the token to the core server app.
The server app validates and accepts the token.
The server app wants to call the backend endpoint which requires a JWT token as well.
However, the existing user-token is not valid for the backend.
Reason: it was issued by different instance of XSUAA.
As such, a new JWT token needs to be fetched.
This is done via token exchange.
3)
The existing token is sent to the XSUAA instance and is used to issue a new token.
4)
This new token (blue) can now be sent to the backend endpoint.
5)
The backend endpoint validates the incoming token with its own instance of XSUAA
Note:
The RFC 7523 specifies the token exchange flow. Quote: "This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication."
Grant
We need another detailed look.
The token exchange mechanism doesn’t solve the problem of the 2 different XSUAA instances.
A token issued from XSUAA1 will never be accepted by XSUAA2
In addition, both applications define their own scopes and require that they are contained in the tokens. But XSUAA1 doesn't even know about XSUAA2, so how could it add any foreign scope?
The mechanism to solve these hurdles is the grant statement.
The backend-XSUAA grants its scope to the frontend-XSUAA.
See below diagram:
Note:
The terms in the diagram are not precise, but I hope that makes it more readable.
We can see that the backend-XSUAA defines a scope called backendscope .
This scope is granted to the frontend-XSUAA - which in fact is the OAuth client with name frontendxsapp . (this is the value of property
In this blog post we create a simple example scenario and verify the difference between token exchange and client credentials.
Quicklinks:
Quick Guide
Sample Code
Content
0. Introduction
1. Token Exchange Scenario
2. Native Code Sample
3. Client Credentials Scenario
Appendix 1: Token Exchange Scenario Sample
Appendix 2: Client Credentials Scenario Sample
Next blog post : using destination
Next blog post : multitenancy example
Introduction
The example scenario
We have a user-centric frontend-application that calls a backend-application via HTTP:
Both apps are protected with OAuth and are bound to an instance of XSUAA.
The frontent-app uses an approuter to handle the user-login (means to fetch a JWT token for the user). All endpoints require a JWT token.
Below diagram shows the token flow in detail:
1)
The end user opens the main app entry point which is the approuter URL.
Approuter handles the communication with XSUAA, to present a login screen.
After entering correct credentials, a JWT token is issued.
This token is specifically for the user and for the frontend application.
2)
Approuter forwards the call and the token to the core server app.
The server app validates and accepts the token.
The server app wants to call the backend endpoint which requires a JWT token as well.
However, the existing user-token is not valid for the backend.
Reason: it was issued by different instance of XSUAA.
As such, a new JWT token needs to be fetched.
This is done via token exchange.
3)
The existing token is sent to the XSUAA instance and is used to issue a new token.
4)
This new token (blue) can now be sent to the backend endpoint.
5)
The backend endpoint validates the incoming token with its own instance of XSUAA
Note:
The RFC 7523 specifies the token exchange flow. Quote: "This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication."
Grant
We need another detailed look.
The token exchange mechanism doesn’t solve the problem of the 2 different XSUAA instances.
A token issued from XSUAA1 will never be accepted by XSUAA2
In addition, both applications define their own scopes and require that they are contained in the tokens. But XSUAA1 doesn't even know about XSUAA2, so how could it add any foreign scope?
The mechanism to solve these hurdles is the grant statement.
The backend-XSUAA grants its scope to the frontend-XSUAA.
See below diagram:
Note:
The terms in the diagram are not precise, but I hope that makes it more readable.
We can see that the backend-XSUAA defines a scope called backendscope .
This scope is granted to the frontend-XSUAA - which in fact is the OAuth client with name frontendxsapp . (this is the value of property
Pedro Pascal
Se unió el 07/03/2018
Facebook
Twitter
Pinterest
Telegram
Linkedin
Whatsapp
Sin respuestas
No hay respuestas para mostrar
Se el primero en responder
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
Hola ¿Puedo ayudarte?