¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Understanding Token Exchange and Client Credentials: A Detailed Comparison

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 19 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.

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
Pinterest
Telegram
Linkedin
Whatsapp

Sin respuestas

No hay respuestas para mostrar 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! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?