Wymiana tokenów

FoxIDs obsługuje dwa różne scenariusze wymiany tokenów: wymianę tokenów w tym samym środowisku oraz wymianę tokenów przez zaufanie do zewnętrznego IdP/OP.

W tym samym środowisku można wykonywać wymianę tokenów dostępu w aplikacji webowej lub API/zasobie na token dla innego zasobu.

Przy zaufaniu zewnętrznym można wymieniać zewnętrzne tokeny dostępu oraz tokeny SAML 2.0 na wewnętrzne tokeny dostępu.

Przykłady

Wymiana tokenów jest zaimplementowana w następujących przykładach:

Wymianę tokenów możesz przetestować w przykładowej aplikacji online (dokumentacja przykładu) klikając Log in i logując się opcjonalnym IdP. Następnie kliknij Call API1 which call API2 lub Token Exchange + Call Api2, aby wywołać API z użyciem wymiany tokenów. Zobacz przykładową konfigurację w FoxIDs Control: https://control.foxids.com/test-corp Uzyskaj dostęp tylko do odczytu użytkownikiem reader@foxids.com i hasłem gEh#V6kSw

Konfiguracja rejestracji aplikacji

Można skonfigurować, czy wymiana tokenów jest dozwolona w rejestracji aplikacji OAuth 2.0 lub kliencie OpenID Connect. Podobnie można skonfigurować, czy ma być dozwolony client credentials grant. Domyślnie zarówno client credentials grant, jak i wymiana tokenów są dozwolone w rejestracjach aplikacji OAuth 2.0 i klientach OpenID Connect. Domyślnie klient jest dodawany jako aktor wymiany tokenów; to zachowanie można wyłączyć.

Konfiguracja klienta OAuth 2.0

Wymiana tokenów w tym samym środowisku

Można wymienić token dostępu wydany dla zasobu i tym samym uzyskać token dostępu dla innego zasobu w środowisku. Klient rejestracji aplikacji jest konfigurowany do obsługi wymiany tokenów i do whitelisting’u zasobów w środowisku, dla których wymiana tokenów jest dozwolona.

Token dostępu na token dostępu w aplikacji webowej

Aplikacja webowa wymienia token dostępu JWT na token dostępu JWT w tym samym środowisku.

W tym scenariuszu klient OpenID Connect uzyskał token dostępu po uwierzytelnieniu użytkownika. Klient może też być klientem OAuth 2.0 używającym client credentials grant.

Wymiana tokenów, token dostępu na token dostępu w aplikacji webowej

Środowisko zawiera dwa zasoby, a klient OpenID Connect może bezpośrednio wywoływać zarówno pierwszy, jak i drugi zasób. Aby uzyskać mniejsze uprawnienia, klient OpenID Connect otrzymuje po uwierzytelnieniu użytkownika token dostępu tylko dla pierwszego zasobu. Następnie uzyskuje token dostępu do drugiego zasobu wtedy, gdy jest potrzebny.

Klient OpenID Connect - zakresy zasobów

Pierwszy token dostępu jest wydany ze scope/audience dla klienta OpenID Connect, dzięki czemu klient może wymienić token dostępu na token dostępu ważny dla drugiego zasobu. Klient OpenID Connect jest skonfigurowany z sekretem jako poświadczeniem klienta używanym zarówno w komunikacji OpenID Connect, jak i w wymianie tokenów.

Podczas sekwencji wymiany tokenów wykonywane są transformacje i ograniczenia oświadczeń w rejestracji aplikacji OpenID Connect.

Klient OpenID Connect wykonuje żądanie wymiany tokenu do FoxIDs, uwierzytelniając klienta i przekazując token dostępu, jednocześnie żądając (ze scope) tokenu dostępu dla drugiego zasobu. Po sukcesie klient zasobu otrzymuje token dostępu i może wywołać drugi zasób z tym tokenem dostępu.

Przykładowe żądanie POST wymiany tokenu do punktu końcowego tokenów:

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

Przykładowa odpowiedź JSON na wymianę tokenu:

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
}

Przykładowa treść tokenu dostępu JWT:

{
    "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"
}

Token dostępu na token dostępu w API

API wymienia token dostępu JWT na token dostępu JWT w tym samym środowisku.

W tym scenariuszu klient OpenID Connect uzyskał token dostępu po uwierzytelnieniu użytkownika. Klient może też być klientem OAuth 2.0 używającym client credentials grant.

Wymiana tokenów, token dostępu na token dostępu w API

Środowisko zawiera dwa zasoby, a klient OpenID Connect może bezpośrednio wywoływać pierwszy zasób. Klient OpenID Connect NIE może bezpośrednio wywoływać drugiego zasobu. Na pierwszym zasobie klient jest skonfigurowany tak, aby umożliwić wymianę tokenów dostępu z audience klienta/zasobu na token dostępu ważny dla drugiego zasobu. Klient na pierwszym zasobie jest skonfigurowany z certyfikatem jako poświadczeniem klienta.

Klient OAuth 2.0 na pierwszym zasobie

Podczas sekwencji wymiany tokenów wykonywane są transformacje i ograniczenia oświadczeń w rejestracji aplikacji.

Klient OpenID Connect wywołuje pierwszy zasób z uzyskanym tokenem dostępu. Klient zasobu wykonuje żądanie wymiany tokenu do FoxIDs, uwierzytelniając klienta i przekazując token dostępu, jednocześnie żądając (ze scope) tokenu dostępu do drugiego zasobu. Po sukcesie klient zasobu otrzymuje token dostępu i może wywołać drugi zasób z tym tokenem dostępu.

Przykładowe żądanie POST wymiany tokenu do punktu końcowego tokenów:

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

Przykładowa odpowiedź JSON na wymianę tokenu:

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
}

Przykładowa treść tokenu dostępu JWT:

{
    "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"
}

Wymiana tokenów przez zaufanie

Przy zaufaniu zewnętrznym do IdP/OP można wymienić token dostępu lub token SAML 2.0 wydany przez podmiot zewnętrzny (lub inne środowisko FoxIDs) i w ten sposób uzyskać token dostępu dla zasobu w środowisku. Konfigurowane jest zaufanie metody uwierzytelniania, a klient rejestracji aplikacji jest konfigurowany tak, aby umożliwić wymianę tokenów na podstawie zaufania metody uwierzytelniania. Klient rejestracji aplikacji dodatkowo whitelistuje zasoby w środowisku, dla których wymiana tokenów jest dozwolona.

Można skonfigurować, czy zaufanie metody uwierzytelniania ma być dozwolone dla wymiany tokenów i uwierzytelniania użytkowników. Domyślnie oba są dozwolone w zaufaniach metod uwierzytelniania OAuth 2.0, OpenID Connect i SAML 2.0.

Konfiguracja zaufania OAuth 2.0

Token dostępu na token dostępu przez zaufanie

Wymiana zewnętrznego tokenu dostępu JWT na wewnętrzny token dostępu JWT przez zaufanie zewnętrzne.

W tym scenariuszu klient OpenID Connect ufa zewnętrznemu dostawcy OpenID (OP) lub dostawcy tożsamości (IdP) i uzyskał token dostępu po uwierzytelnieniu użytkownika. Klient może też być klientem OAuth 2.0 używającym client credentials grant do uzyskania zewnętrznego tokenu dostępu.

Wymiana tokenów, token dostępu na token dostępu przez zaufanie

W środowisku jest zasób, ale zewnętrznie zdefiniowany klient OpenID Connect NIE może bezpośrednio wywoływać zasobu. Najpierw konfiguruje się metodę uwierzytelniania OAuth 2.0 lub OpenID Connect, aby ufała zewnętrznemu dostawcy OpenID (OP) lub dostawcy tożsamości (IdP), a issuer SP jest konfigurowany tak, aby pasował do audience zewnętrznego klienta OpenID Connect. Poniższy przykład zaufania zewnętrznego dotyczy zaufania do innego środowiska FoxIDs.

Zaufanie metody uwierzytelniania OAuth 2.0

Następnie konfiguruje się klienta rejestracji aplikacji OAuth 2.0, aby akceptował zewnętrzne tokeny dostępu na podstawie zaufania metody uwierzytelniania. Możliwe jest posiadanie jednego lub wielu zaufanych metod uwierzytelniania. Ten klient jest skonfigurowany z sekretem jako poświadczeniem klienta.

Klient rejestracji aplikacji OAuth 2.0 dla aplikacji OIDC

Dzięki temu możliwa jest wymiana zewnętrznego tokenu dostępu na wewnętrzny token dostępu ważny dla zasobu.

Podczas sekwencji wymiany tokenów transformacje i ograniczenia oświadczeń są wykonywane najpierw w metodzie uwierzytelniania, a następnie w rejestracji aplikacji.

Backend klienta OpenID Connect wykonuje żądanie wymiany tokenu do FoxIDs. Uwierzytelnia wewnętrznego klienta OAuth 2.0 i przekazuje zewnętrzny token dostępu, jednocześnie żądając (ze scope) tokenu dostępu dla zasobu. Po sukcesie backend klienta OpenID Connect otrzymuje token dostępu i może wywołać zasób.

Przykładowe żądanie POST wymiany tokenu do punktu końcowego tokenów:

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

Przykładowa odpowiedź JSON na wymianę tokenu:

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 na token dostępu przez zaufanie

Wymiana zewnętrznego tokenu SAML 2.0 na wewnętrzny token dostępu JWT przez zaufanie zewnętrzne.

W tym scenariuszu aplikacja SAML 2.0 ufa zewnętrznemu dostawcy tożsamości (IdP) i uzyskała token SAML 2.0 po uwierzytelnieniu użytkownika.

Wymiana tokenów, SAML 2.0 na token dostępu przez zaufanie

W środowisku jest zasób, ale zewnętrznie zdefiniowana aplikacja SAML 2.0 NIE może bezpośrednio wywoływać zasobu. Najpierw konfiguruje się metodę uwierzytelniania SAML 2.0, aby ufała dostawcy tożsamości (IdP), a issuer SP jest konfigurowany tak, aby pasował do audience zewnętrznej aplikacji SAML 2.0. Poniższy przykład zaufania zewnętrznego dotyczy zaufania do rejestracji aplikacji SAML 2.0 w FoxIDs.

Zaufanie metody uwierzytelniania SAML 2.0

Następnie konfiguruje się klienta rejestracji aplikacji OAuth 2.0, aby akceptował zewnętrzne tokeny SAML 2.0 na podstawie zaufania metody uwierzytelniania. Możliwe jest posiadanie jednego lub wielu zaufanych metod uwierzytelniania. Ten klient jest skonfigurowany z certyfikatem jako poświadczeniem klienta.

Klient rejestracji aplikacji OAuth 2.0 dla aplikacji SAML 2.0

W ten sposób możliwa jest wymiana zewnętrznego tokenu SAML 2.0 na wewnętrzny token dostępu ważny dla zasobu.

Podczas sekwencji wymiany tokenów transformacje i ograniczenia oświadczeń są wykonywane najpierw w metodzie uwierzytelniania, a następnie w rejestracji aplikacji.

Backend aplikacji SAML 2.0 wykonuje żądanie wymiany tokenu do FoxIDs. Uwierzytelnia wewnętrznego klienta OAuth 2.0 i przekazuje zewnętrzny token SAML 2.0, jednocześnie żądając (ze scope) tokenu dostępu do zasobu. Po sukcesie backend aplikacji SAML 2.0 otrzymuje token dostępu i może wywołać zasób.

Przykładowe żądanie POST wymiany tokenu do punktu końcowego tokenów:

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

Przykładowa odpowiedź JSON na wymianę tokenu:

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
}

Twoja prywatność

Używamy plików cookie, aby poprawić korzystanie z naszych stron internetowych. Kliknij przycisk „Akceptuj wszystkie pliki cookie”, aby wyrazić zgodę na ich użycie. Aby zrezygnować z nieistotnych plików cookie, kliknij „Tylko niezbędne pliki cookie”.

Odwiedź naszą politykę prywatności, aby dowiedzieć się więcej