Zrozumienie wymiany tokenów w OAuth/OIDC

Wprowadzona w RFC 8693, wymiana tokenów to rozszerzenie OAuth, które pozwala zaufanym klientom wymienić istniejący token na nowy o innych atrybutach lub zakresach. Mechanizm ten jest szczególnie przydatny, gdy usługa, aplikacja lub użytkownik końcowy chce uzyskać zwykły token dostępu OAuth za pomocą preautoryzowanego tokenu, bez potrzeby przechodzenia przez pełny przepływ OAuth.

Porównanie z przepływem kodu autoryzacji#

Na początku spójrzmy na przepływ kodu autoryzacji OAuth, który jest najczęstszym przepływem uzyskiwania tokenu dostępu.

A to jest przepływ wymiany tokenów:

Przekierowanie#

Główna różnica polega na tym, że w przepływie kodu autoryzacji, aplikacja kliencka przekierowuje użytkownika do serwera autoryzacji, aby uzyskać token dostępu. W wymianie tokenów, aplikacja kliencka może wymienić token z serwerem autoryzacji bez zaangażowania użytkownika do przekierowania.

Jest tak, ponieważ w przepływie kodu autoryzacji, aplikacja kliencka nie jest "zaufana" i musi znać dane uwierzytelniające użytkownika, aby uzyskać token dostępu. W wymianie tokenów, aplikacja kliencka jest zaufana, ponieważ uzyskała już token od użytkownika, a serwer autoryzacji zweryfikuje token i wyda nowy.

Wydawca tokenu i usługa wymiany tokenów#

W przepływie wymiany tokenów, "Serwer autoryzacji" teraz jest dwojgiem uczestników:

1. Wydawca tokenu: wystawia token podmiotu dla aplikacji klienckiej.
2. Usługa wymiany tokenów: waliduje token podmiotu i wydaje nowy token dla aplikacji klienckiej.

Usługa wymiany tokenów jest taka sama jak "Serwer autoryzacji" w przepływie kodu autoryzacji, a wydawca tokenu może być zewnętrznym dostawcą tożsamości lub wyodrębnionym z "Serwera autoryzacji" jako dedykowana usługa.

Kiedy używać wymiany tokenów?#

Przepływ wymiany tokenów może być wykonany bez interakcji użytkownika, co jest przydatne w następujących scenariuszach:

• Naśladowanie: Pozwala usługom (np. mikrousługom backendu) lub administratorom na wykonywanie działań w imieniu użytkownika bez ujawniania pełnych danych uwierzytelniających użytkownika.
• Automatyzacja: Pozwala zaufanym usługom na samodzielne wykonywanie działań bez ręcznego interweniowania lub wykonywanie zautomatyzowanych testów.
• Integracja z innymi IdP: Przekładanie tokenów między różnymi systemami tożsamości, aby utrzymać płynne doświadczenie użytkownika i zarządzać uprawnieniami efektywnie; jednym z powszechnych scenariuszy jest przekładanie tokenu SSO na token dla usługi downstream.
• Migracja: Migracja tokenów z jednego serwera autoryzacji na inny, na przykład z systemu legacy na nowoczesny, zgodny z OAuth/OIDC system.

Proces wymiany tokenów#

Wymiana na nowy token dostępu jest najczęstszym przypadkiem użycia, użyjemy tego jako przykład. Nie ogranicza się do tokenu dostępu, wymiana tokenów może być również używana do wydawania innych typów tokenów, takich jak token odświeżania, token ID itp.

Aplikacja kliencka#

Aby przeprowadzić wymianę tokenów, wymagana jest zarejestrowana aplikacja kliencka z serwerem autoryzacji.

I aplikacja kliencka musi posiadać subject_token przed rozpoczęciem przepływu wymiany tokenów. Ten token jest zazwyczaj przyznawany przez serwer autoryzacji lub zaufanego zewnętrznego dostawcę tożsamości. Mając ten token, aplikacja kliencka może teraz być "zaufana" do wymiany tokenów bez potrzeby używania danych uwierzytelniających użytkownika i interakcji.

Żądanie wymiany tokenów#

Klient wysyła żądanie do punktu końcowego tokenu serwera autoryzacji, aby wymienić istniejący token. Zawiera to subject_token (token, który ma być wymieniony) i opcjonalnie, pożądaną docelową publiczność, zakres i typ tokenu.

1. grant_type: WYMAGANY. Wartość tego parametru musi wynosić urn:ietf:params:oauth:grant-type:token-exchange co wskazuje, że dokonywana jest wymiana tokenów.
2. subject_token: WYMAGANY. PAT użytkownika.
3. subject_token_type: WYMAGANY. Typ tokenu bezpieczeństwa podanego w parametrze subject_token. Ogólna wartość tego parametru to urn:ietf:params:oauth:token-type:access_token, ale może się różnić w zależności od wymienianego tokenu.
4. resource: OPCJONALNY. Wskaźnik zasobu, pomaga określić docelowy zasób dla tokenu dostępu.
5. audience: OPCJONALNY. Odbiorcy tokenu dostępu, oznaczający zamierzonych odbiorców tokenu, serwer autoryzacji może użyć wartości resource, jeśli audience nie jest określone.
6. scope: OPCJONALNY. Żądane zakresy.

Również żądanie musi zawierać informacje o kliencie, które można zakodować jako nagłówek Basic Auth lub przesłać jako dane formularza.

Oto przykład żądania:

Wymiana tokenów w Logto#

Logto obsługuje wymianę tokenów od razu, obejmując naśladowanie i osobiste tokeny dostępu.