Token exchange
FoxIDs supporta due scenari differenti di token exchange: token exchange nello stesso ambiente e token exchange tramite trust verso IdP/OP esterni.
Nello stesso ambiente e possibile eseguire token exchange di access token in una applicazione web o API/risorsa verso un'altra risorsa.
Tramite trust esterna e possibile eseguire token exchange di access token esterni e token SAML 2.0 verso access token interni.
Samples
Il token exchange e implementato nei seguenti sample:
- AspNetCoreOidcAuthCodeAllUpPartiesSample, mostra token exchange da access token ad access token all'interno del backend di un sito web
- AspNetCoreSamlSample, mostra token exchange da token SAML 2.0 ad access token
- AspNetCoreApi1Sample, mostra token exchange da access token ad access token all'interno di un'API
Puoi testare il token exchange con il sample online web app (documentazione sample) facendo clic su
Log ine autenticandoti con un IdP facoltativo. Poi fai clic suCall API1 which call API2oppureToken Exchange + Call Api2per chiamare un'API usando token exchange.
Consulta la configurazione del sample in FoxIDs Control: https://control.foxids.com/test-corp
Ottieni accesso in lettura con l'utentereader@foxids.come la passwordgEh#V6kSw
Configurazione della registrazione applicativa
E possibile configurare se il token exchange e consentito sulla registrazione applicativa OAuth 2.0 o sul client OpenID Connect. Allo stesso modo, e possibile configurare se il client credentials grant deve essere consentito.
Per impostazione predefinita sia client credentials grant sia token exchange sono consentiti sulle registrazioni applicative OAuth 2.0 e sui client OpenID Connect.
Per impostazione predefinita il client viene aggiunto come attore del token exchange; questo comportamento puo essere disabilitato.
Token exchange nello stesso ambiente
E possibile eseguire token exchange di un access token emesso per una risorsa e ottenere cosi un access token per un'altra risorsa nell'ambiente.
Un client di registrazione applicativa viene configurato per gestire il token exchange e per autorizzare tramite whitelist per quali risorse nell'ambiente e consentito eseguire token exchange.
Access Token verso Access Token in applicazione web
Un'applicazione web esegue token exchange da JWT access token a JWT access token' nello stesso ambiente.
In questo scenario, un client OpenID Connect ha ottenuto un access token dopo l'autenticazione dell'utente.
Il client potrebbe anche essere un client OAuth 2.0 che usa client credentials grant.
L'ambiente include due risorse e il client OpenID Connect e autorizzato a chiamare direttamente sia la prima sia la seconda risorsa. Per ottenere least privileges, il client OpenID Connect riceve solo un access token per la prima risorsa dopo l'autenticazione dell'utente. Successivamente ottiene un access token per la seconda risorsa quando necessario.
Il primo access token viene emesso con uno scope/audience per il client OpenID Connect e il client e quindi autorizzato a scambiare l'access token con un access token' valido per la seconda risorsa.
Il client OpenID Connect e configurato con un secret come credenziali client, usate sia nella comunicazione OpenID Connect sia nel token exchange.
Durante la sequenza di token exchange, le trasformazioni e le limitazioni dei claim vengono eseguite sulla registrazione applicativa OpenID Connect.
Il client OpenID Connect effettua una chiamata di token exchange a FoxIDs autenticando il client e passando l'access token, mentre richiede (con uno scope) un access token' per la seconda risorsa. In caso di successo, il client della risorsa riceve un access token' e puo quindi chiamare la seconda risorsa con quell'access token'.
Sample token exchange POST request to the token endpoint:
POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded
client_id=aspnet_oidc_allup_sample
&client_secret=IxIruKswG4sQxzOrKlXR58strgZtoyZPG18J3FhzEXI
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=accVkjcJyb4...UC5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
Sample token exchange JSON response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"access_token":"eyJhGcjlc...nNjb3IIWvmDCM",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type":"Bearer",
"expires_in":600
}
Sample JWT access token' body:
{
"sub": "2f18c344-1204-4629-b992-215913b85c2b",
"auth_time": "1699955593",
"amr": "pwd",
"email": "test1@foxids.com",
"role": ["role1","role2"],
"name": "Test 1 user",
"act": "{\"sub\":\"c_aspnet_oidc_allup_sample\"}",
"scope": "aspnetcore_api2_sample:some_2_access",
"client_id": "aspnet_oidc_allup_sample",
"nbf": 1699955534,
"exp": 1699956194,
"iat": 1699955594,
"iss": "https://foxids.com/test-corp/-/",
"aud": "aspnetcore_api2_sample"
}
Access Token verso Access Token in API
Un'API esegue token exchange da JWT access token a JWT access token' nello stesso ambiente.
In questo scenario, un client OpenID Connect ha ottenuto un access token dopo l'autenticazione dell'utente.
Il client potrebbe anche essere un client OAuth 2.0 che usa client credentials grant.
L'ambiente include due risorse e il client OpenID Connect e autorizzato a chiamare direttamente la prima risorsa. Il client OpenID Connect NON e autorizzato a chiamare direttamente la seconda risorsa. Sulla prima risorsa e configurato un client che consente di scambiare access token con audience client/risorsa in un access token' valido per la seconda risorsa.
Il client seguente sulla prima risorsa e configurato con un certificato come credenziale client.
Durante la sequenza di token exchange, le trasformazioni e le limitazioni dei claim vengono eseguite sulla registrazione applicativa.
Il client OpenID Connect chiama la prima risorsa con l'access token ottenuto. Il client della risorsa effettua una chiamata di token exchange a FoxIDs autenticando il client e passando l'access token mentre richiede (con uno scope) un access token' per la seconda risorsa. In caso di successo, il client della risorsa riceve un access token' e puo quindi chiamare la seconda risorsa con quell'access token'.
Sample token exchange POST request to the token endpoint:
POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiI...kyX3NhbXBsZS
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=accVkjcJyb4...C5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
Sample token exchange JSON response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"access_token":"eyJhGcRwczov...nNjb3BlIjoi",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type":"Bearer",
"expires_in":600
}
Sample JWT access token' body:
{
"sub": "2f18c344-1204-4629-b992-215913b85c2b",
"auth_time": "1699955841",
"amr": "pwd",
"act": "{\"sub\":\"c_aspnetcore_api1_sample\"}",
"scope": "aspnetcore_api2_sample:some_2_access",
"client_id": "aspnetcore_api1_sample",
"nbf": 1699955786,
"exp": 1699956446,
"iat": 1699955846,
"iss": "https://foxids.com/test-corp/-/",
"aud": "aspnetcore_api2_sample"
}
Token exchange tramite trust
Tramite trust esterna verso IdP/OP e possibile eseguire token exchange di un access token oppure di un token SAML 2.0 emesso da una parte esterna (o da un altro ambiente FoxIDs) e ottenere cosi un access token per una risorsa nell'ambiente.
Viene configurata una trust di metodo di autenticazione e viene configurato un client di registrazione applicativa per consentire il token exchange sulla base di una o piu trust di metodo di autenticazione. Il client di registrazione applicativa mette inoltre in whitelist le risorse nell'ambiente per cui e consentito eseguire token exchange.
E possibile configurare se la trust del metodo di autenticazione deve essere consentita per token exchange e autenticazione utente. Per impostazione predefinita entrambe sono consentite su trust di metodo di autenticazione OAuth 2.0, OpenID Connect e SAML 2.0.
Access Token verso Access Token tramite trust
Token exchange da JWT access token esterno a JWT access token interno tramite trust esterna.
In questo scenario, un client OpenID Connect si fida di un OpenID Provider (OP) / Identity Provider (IdP) esterno e ha ottenuto un access token dopo l'autenticazione dell'utente.
Il client potrebbe anche essere un client OAuth 2.0 che usa client credentials grant per ottenere l'access token esterno.
Esiste una risorsa nell'ambiente, ma il client OpenID Connect definito esternamente NON e autorizzato a chiamare direttamente la risorsa.
Prima viene configurato un metodo di autenticazione OAuth 2.0 oppure OpenID Connect per fidarsi dell'OpenID Provider (OP) / Identity Provider (IdP) esterno e l'SP issuer viene configurato in modo da corrispondere all'audience del client OpenID Connect esterno.
L'esempio seguente di trust esterna e una trust verso un altro ambiente FoxIDs.
Poi viene configurato un client di registrazione applicativa OAuth 2.0 per accettare access token esterni tramite la trust del metodo di autenticazione. E possibile avere una o piu trust di metodo di autenticazione.
Il client seguente e configurato con un secret come credenziale client.
Diventa quindi possibile eseguire token exchange di un access token esterno in un access token interno valido per la risorsa.
Durante la sequenza di token exchange, sia le trasformazioni sia le limitazioni dei claim vengono eseguite prima sul metodo di autenticazione e poi sulla registrazione applicativa.
L'applicazione backend client OpenID Connect effettua una chiamata di token exchange a FoxIDs. Autentica il client OAuth 2.0 interno e passa l'access token esterno mentre richiede (con uno scope) un access token per la risorsa. In caso di successo, l'applicazione backend client OpenID Connect riceve un access token e puo quindi chiamare la risorsa.
Sample token exchange POST request to the token endpoint:
POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded
client_id=some_external_id
&client_secret=goOxwj8Kz...wUC-3CGs
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=accVkjcJyb4...UC5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
Sample token exchange JSON response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"access_token":"eyJhGcjlc...nNjb3IIWvmDCM",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type":"Bearer",
"expires_in":600
}
SAML 2.0 verso Access Token tramite trust
Token exchange da token SAML 2.0 esterno a JWT access token interno tramite trust esterna.
In questo scenario, un'applicazione SAML 2.0 si fida di un Identity Provider (IdP) esterno e ha ottenuto un token SAML 2.0 dopo l'autenticazione dell'utente.
Esiste una risorsa nell'ambiente, ma l'applicazione SAML 2.0 definita esternamente NON e autorizzata a chiamare direttamente la risorsa.
Prima viene configurato un metodo di autenticazione SAML 2.0 per fidarsi dell'Identity Provider (IdP) e l'SP issuer viene configurato in modo da corrispondere all'audience dell'applicazione SAML 2.0 esterna.
L'esempio seguente di trust esterna e una trust verso una registrazione applicativa SAML 2.0 di FoxIDs.
Poi viene configurato un client di registrazione applicativa OAuth 2.0 per accettare token SAML 2.0 esterni tramite la trust del metodo di autenticazione. E possibile avere una o piu trust di metodo di autenticazione.
Il client seguente e configurato con un certificato come credenziale client.
Diventa quindi possibile eseguire token exchange di un token SAML 2.0 esterno in un access token interno valido per la risorsa.
Durante la sequenza di token exchange, sia le trasformazioni sia le limitazioni dei claim vengono eseguite prima sul metodo di autenticazione e poi sulla registrazione applicativa.
L'applicazione backend SAML 2.0 effettua una chiamata di token exchange a FoxIDs. Autentica il client OAuth 2.0 interno e passa il token SAML 2.0 esterno mentre richiede (con uno scope) un access token per la risorsa. In caso di successo, l'applicazione backend SAML 2.0 riceve un access token e puo quindi chiamare la risorsa.
Sample token exchange POST request to the token endpoint:
POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiI...kyX3NhbXBsZS
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=%3Csaml%3AAssertion%20xmlns%3Asaml...%3AAssertion%3E%0A
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2
Sample token exchange JSON response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"access_token":"eyJhGcRwczov...nNjb3BlIjoi",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type":"Bearer",
"expires_in":600
}