Token exchange
FoxIDs unterstützt zwei verschiedene Szenarien für Token exchange: Token exchange im selben Environment und Token exchange durch Trust zu externem IdP/OP.
Im selben Environment ist es möglich, Token exchange von Access Tokens in einer Web Anwendung oder API/Resource zu einer anderen Resource durchzuführen.
Durch externen Trust ist es möglich, Token exchange von externen Access Tokens und SAML 2.0 Tokens zu internen Access Tokens durchzuführen.
Samples
Token exchange ist in den folgenden Samples implementiert:
- AspNetCoreOidcAuthCodeAllUpPartiesSample, zeigt Token exchange von Access Token zu Access Token innerhalb eines Website Backends
- AspNetCoreSamlSample, zeigt Token exchange von SAML 2.0 Token zu Access Token
- AspNetCoreApi1Sample, zeigt Token exchange von Access Token zu Access Token innerhalb einer API
Du kannst Token exchange mit dem Online Web App Sample (Sample Docs) testen, indem du
Log inklickst und dich mit einem beliebigen IdP anmeldest. Klicke dannCall API1 which call API2oderToken Exchange + Call Api2, um eine API mit Token exchange aufzurufen.
Schau dir die Sample Konfiguration in FoxIDs Control an: https://control.foxids.com/test-corp
Erhalte read access mit dem Benutzerreader@foxids.comund PasswortgEh#V6kSw
Anwendungsregistrierung Konfiguration
Es ist möglich zu konfigurieren, ob Token exchange für die OAuth 2.0 Anwendungsregistrierung oder den OpenID Connect Client erlaubt ist. Ebenso kann konfiguriert werden, ob client credentials grant erlaubt sein soll.
Standardmäßig sind sowohl client credentials grant als auch Token exchange für OAuth 2.0 Anwendungsregistrierungen und OpenID Connect Clients erlaubt.
Standardmäßig wird der Client als Token exchange Actor hinzugefügt, dieses Verhalten kann deaktiviert werden.
Token exchange im selben Environment
Es ist möglich, ein Access Token für eine Resource zu exchange und dadurch ein Access Token für eine andere Resource im Environment zu erhalten.
Ein Anwendungsregistrierung Client wird konfiguriert, um Token exchange zu handhaben und zu whitelist welche Resources im Environment Token exchange erlaubt sind.
Access Token zu Access Token in Web Anwendung
Eine Web Anwendung tauscht JWT Access Token zu JWT Access Token' im selben Environment.
In diesem Szenario hat ein OpenID Connect Client nach Benutzer Authentifizierung ein Access Token erhalten.
Der Client kann auch ein OAuth 2.0 Client sein, der client credentials grant verwendet.
Das Environment enthält zwei Resources und der OpenID Connect Client darf sowohl die erste als auch die zweite Resource direkt aufrufen. Um least privileges zu erreichen, erhält der OpenID Connect Client nach Benutzer Authentifizierung nur ein Access Token für die erste Resource. Und erhält anschließend ein Access Token für die zweite Resource, wenn es benötigt wird.
Das erste Access Token wird mit einem Scope/Audience für den OpenID Connect Client ausgestellt und der Client ist damit berechtigt, Access Tokens zu einem Access Token' zu exchange, das für die zweite Resource gültig ist.
Der OpenID Connect Client ist mit einem Secret als Client Credentials konfiguriert, die sowohl in der OpenID Connect Kommunikation als auch beim Token exchange verwendet werden.
Während der Token exchange Sequenz werden Claims Transformations und Limitations auf der OpenID Connect Anwendungsregistrierung ausgeführt.
Der OpenID Connect Client führt einen Token exchange Call an FoxIDs durch, authentifiziert den Client und übergibt das Access Token, während (mit einem Scope) ein Access Token' für die zweite Resource angefordert wird. Bei Erfolg erhält der Resource Client ein Access Token' zurück und kann die zweite Resource mit dem Access Token' aufrufen.
Sample Token exchange POST Request zum 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 zu Access Token in API
Eine API tauscht JWT Access Token zu JWT Access Token' im selben Environment.
In diesem Szenario hat ein OpenID Connect Client nach Benutzer Authentifizierung ein Access Token erhalten.
Der Client kann auch ein OAuth 2.0 Client sein, der client credentials grant verwendet.
Das Environment enthält zwei Resources und der OpenID Connect Client darf die erste Resource direkt aufrufen. Der OpenID Connect Client darf die zweite Resource NICHT direkt aufrufen. Auf der ersten Resource ist ein Client konfiguriert, der Access Tokens mit Client/Resource Audience erlaubt, zu einem Access Token' für die zweite Resource zu exchange.
Der folgende Client auf der ersten Resource ist mit einem Zertifikat als Client Credential konfiguriert.
Während der Token exchange Sequenz werden Claims Transformations und Limitations auf der Anwendungsregistrierung ausgeführt.
Der OpenID Connect Client ruft die erste Resource mit dem erhaltenen Access Token auf. Der Resource Client führt einen Token exchange Call an FoxIDs durch, authentifiziert den Client und übergibt das Access Token, während (mit einem Scope) ein Access Token' für die zweite Resource angefordert wird. Bei Erfolg erhält der Resource Client ein Access Token' zurück und kann die zweite Resource mit dem Access Token' aufrufen.
Sample Token exchange POST Request zum 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 durch Trust
Durch externen Trust zu IdP/OP ist es möglich, ein Access Token oder SAML 2.0 Token auszutauschen, die von einer externen Partei (oder einem anderen FoxIDs Environment) ausgestellt wurden, und dadurch ein Access Token für eine Resource im Environment zu erhalten.
Ein Authentifizierungsmethode Trust wird konfiguriert und ein Anwendungsregistrierung Client wird konfiguriert, um Token exchange basierend auf den Authentifizierungsmethode Trusts zu erlauben. Der Anwendungsregistrierung Client whitelists außerdem, für welche Resources im Environment Token exchange erlaubt ist.
Es ist möglich zu konfigurieren, ob der Authentifizierungsmethode Trust für Token exchange und Benutzer Authentifizierung erlaubt sein soll. Standardmäßig sind beide für OAuth 2.0, OpenID Connect und SAML 2.0 Authentifizierungsmethode Trusts erlaubt.
Access Token zu Access Token durch Trust
Token exchange eines externen JWT Access Tokens zu einem internen JWT Access Token durch externen Trust.
In diesem Szenario vertraut ein OpenID Connect Client einem externen OpenID Provider (OP) / Identity Provider (IdP) und hat nach Benutzer Authentifizierung ein Access Token erhalten.
Der Client kann auch ein OAuth 2.0 Client sein, der client credentials grant verwendet, um das externe Access Token zu erhalten.
Es gibt eine Resource im Environment, aber der extern definierte OpenID Connect Client darf die Resource NICHT direkt aufrufen.
Zuerst wird eine OAuth 2.0 oder OpenID Connect Authentifizierungsmethode konfiguriert, um dem externen OpenID Provider (OP) / Identity Provider (IdP) zu vertrauen, und der SP Issuer wird so konfiguriert, dass er dem Audience des externen OpenID Connect Clients entspricht.
Das folgende externe Trust Beispiel ist ein Trust zu einem anderen FoxIDs Environment.
Dann wird ein OAuth 2.0 Anwendungsregistrierung Client konfiguriert, um externe Access Tokens über den Authentifizierungsmethode Trust zu akzeptieren. Es ist möglich, einen oder mehrere Authentifizierungsmethode Trusts zu haben.
Der folgende Client ist mit einem Secret als Client Credentials konfiguriert.
Damit ist es möglich, ein externes Access Token zu einem internen Access Token zu exchange, das für die Resource gültig ist.
Während der Token exchange Sequenz werden sowohl Claims Transformations als auch Limitations zuerst auf der Authentifizierungsmethode und dann auf der Anwendungsregistrierung ausgeführt.
Die OpenID Connect Client Backend Anwendung führt einen Token exchange Call an FoxIDs durch. Sie authentifiziert den internen OAuth 2.0 Client und übergibt das externe Access Token, während (mit einem Scope) ein Access Token für die Resource angefordert wird. Bei Erfolg erhält die OpenID Connect Client Backend Anwendung ein Access Token zurück und kann nun die Resource aufrufen.
Sample Token exchange POST Request zum 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 zu Access Token durch Trust
Token exchange eines externen SAML 2.0 Tokens zu einem internen JWT Access Token durch externen Trust.
In diesem Szenario vertraut eine SAML 2.0 Anwendung einem externen Identity Provider (IdP) und hat nach Benutzer Authentifizierung ein SAML 2.0 Token erhalten.
Es gibt eine Resource im Environment, aber die extern definierte SAML 2.0 Anwendung darf die Resource NICHT direkt aufrufen.
Zuerst wird eine SAML 2.0 Authentifizierungsmethode konfiguriert, die dem Identity Provider (IdP) vertraut, und der SP Issuer wird so konfiguriert, dass er dem Audience der externen SAML 2.0 Anwendung entspricht.
Das folgende externe Trust Beispiel ist ein Trust zu einer FoxIDs SAML 2.0 Anwendungsregistrierung.
Dann wird ein OAuth 2.0 Anwendungsregistrierung Client konfiguriert, um externe SAML 2.0 Tokens über den Authentifizierungsmethode Trust zu akzeptieren. Es ist möglich, einen oder mehrere Authentifizierungsmethode Trusts zu haben.
Der folgende Client ist mit einem Zertifikat als Client Credentials konfiguriert.
Damit ist es möglich, ein externes SAML 2.0 Token zu einem internen Access Token zu exchange, das für die Resource gültig ist.
Während der Token exchange Sequenz werden sowohl Claims Transformations als auch Limitations zuerst auf der Authentifizierungsmethode und dann auf der Anwendungsregistrierung ausgeführt.
Die SAML 2.0 Backend Anwendung führt einen Token exchange Call an FoxIDs durch. Sie authentifiziert den internen OAuth 2.0 Client und übergibt das externe SAML 2.0 Token, während (mit einem Scope) ein Access Token für die Resource angefordert wird. Bei Erfolg erhält die SAML 2.0 Backend Anwendung ein Access Token zurück und kann nun die Resource aufrufen.
Sample Token exchange POST Request zum 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
}