Czym dokładnie jest token okaziciela OAuth 2.0?

171

Zgodnie z RFC6750 -The OAuth 2.0 Authorization Framework: Bearer Token Usage, token okaziciela to:

Token zabezpieczający z właściwością, którą każda strona będąca w posiadaniu tokena („na okaziciela”) może go używać w dowolny sposób, w jaki może go posiadać każda inna osoba będąca w jego posiadaniu.

Dla mnie ta definicja jest niejasna i nie mogę znaleźć żadnej specyfikacji.

Załóżmy, że implementuję dostawcę autoryzacji, czy mogę podać dowolny ciąg dla tokena okaziciela?
Czy może to być losowy ciąg?
Czy musi to być kodowanie base64 niektórych atrybutów?
Czy powinien być zaszyfrowany?
Czy dostawca usług musi zapytać dostawcę autoryzacji, aby zweryfikować ten token?

Dziękuję za wskazówki.

oauth bearer-token

— Alex Beaupré
źródło

Załóżmy, że implementuję dostawcę autoryzacji, czy mogę podać dowolny ciąg dla tokena okaziciela? Czy może to być losowy ciąg? Tokeny dostępu są wydawane za pośrednictwem punktów końcowych OAuth 2.0 Auth0: / authorize i / oauth / token. Aby uzyskać tokeny dostępu, możesz użyć dowolnej biblioteki zgodnej z OAuth 2.0. Jeśli nie masz jeszcze preferowanej biblioteki OAuth 2.0, Auth0 zapewnia biblioteki dla wielu języków i struktur.

— Bharathkumar V

Odpowiedzi:

146

Token okaziciela Token
zabezpieczający z właściwością, dzięki której każda strona będąca w posiadaniu tokena („na okaziciela”) może go używać w dowolny sposób, jaki może mieć każda inna osoba będąca w jego posiadaniu. Korzystanie z tokena na okaziciela nie wymaga od okaziciela udokumentowania posiadania materiału klucza kryptograficznego (dowód posiadania).

Token okaziciela jest tworzony przez serwer uwierzytelniania. Gdy użytkownik uwierzytelnia Twoją aplikację (klienta), serwer uwierzytelniania przechodzi następnie i generuje dla Ciebie Token. Tokeny okaziciela to przeważający typ tokenów dostępu używanych w OAuth 2.0. Zasadniczo token okaziciela mówi „Daj posiadaczowi tego tokena dostęp”.

Token okaziciela jest zwykle jakąś nieprzezroczystą wartością utworzoną przez serwer uwierzytelniania. To nie jest przypadkowe; jest tworzony na podstawie użytkownika, który daje ci dostęp, i klienta, który uzyskuje dostęp do aplikacji.

Na przykład, aby uzyskać dostęp do API, musisz użyć Access Token. Tokeny dostępu są krótkotrwałe (około godziny). Używasz tokena okaziciela, aby uzyskać nowy token dostępu. Aby uzyskać token dostępu, wysyłasz serwerowi uwierzytelniającemu ten token okaziciela wraz z identyfikatorem klienta. Dzięki temu serwer wie, że aplikacja korzystająca z tokena okaziciela jest tą samą aplikacją, dla której został utworzony token okaziciela. Przykład: nie mogę po prostu wziąć tokena okaziciela utworzonego dla twojej aplikacji i użyć go z moją aplikacją, to nie zadziała, ponieważ nie został wygenerowany dla mnie.

Token Google Refresh wygląda mniej więcej tak: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

skopiowano z komentarza: Nie sądzę, aby były jakieś ograniczenia dotyczące żetonów na okaziciela, które dostarczasz. Jedyne, co przychodzi mi do głowy, to to, że miło jest pozwolić na więcej niż jeden. Na przykład użytkownik może uwierzytelnić aplikację do 30 razy, a stare tokeny okaziciela będą nadal działać. och i jeśli nie był używany przez powiedzmy 6 miesięcy, usunąłbym go z twojego systemu. To Twój serwer uwierzytelniający będzie musiał je wygenerować i zweryfikować, więc sposób ich sformatowania zależy od Ciebie.

Aktualizacja:

Token okaziciela jest ustawiany w nagłówku Authorization każdego żądania HTTP wbudowanego działania. Na przykład:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

Ciąg "AbCdEf123456"w powyższym przykładzie jest tokenem autoryzacji okaziciela. To jest token kryptograficzny wytwarzany przez serwer uwierzytelniania. Wszystkie tokeny okaziciela wysyłane z akcjami mają pole wydania, w którym pole odbiorców określa domenę nadawcy jako adres URL w postaci https: //. Na przykład, jeśli e-mail pochodzi z adresu noreply@example.com, odbiorcą jest https://example.com .

Jeśli używasz tokenów okaziciela, sprawdź, czy żądanie pochodzi z serwera uwierzytelniania i jest przeznaczone dla domeny nadawcy. Jeśli token nie zostanie zweryfikowany, usługa powinna odpowiedzieć na żądanie z kodem odpowiedzi HTTP 401 (nieautoryzowany).

Tokeny okaziciela są częścią standardu OAuth V2 i są szeroko stosowane w wielu interfejsach API.

— DaImTo
źródło

@ Xavier Egea Bearer token jest w zasadzie tokenem odświeżania, a nie tokenem dostępu.

— Akhil Nambiar,

Token okaziciela nie oznacza, że jest to token odświeżania @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1

— Suman Kundu

Z pierwszego akapitu wynika, że token okaziciela jest tokenem odświeżania, a nie tokenem dostępu. Nie o to chodzi. Ze specyfikacji tokena okaziciela „Ta specyfikacja opisuje sposób wykonywania żądań zasobów chronionych, gdy token dostępu OAuth jest tokenem okaziciela”. RFC6750

— Daniel

Po przeczytaniu odpowiedzi pomyślałem również, że token okaziciela i tokeny odświeżania są takie same. Odpowiedź powinna zostać zaktualizowana, aby to wyjaśnić.

— KurioZ7

Ta odpowiedź jest bardzo myląca. Żetony okaziciela NIE SĄ Tokenem Odświeżania, jak stwierdza początkowe stwierdzenie tej odpowiedzi. Proszę popraw.

— think01

Czytając Twoje pytanie, bezskutecznie próbowałem wyszukać w Internecie, w jaki sposób tokeny okaziciela są szyfrowane lub podpisywane. Wydaje mi się, że tokeny okaziciela nie są zaszyfrowane (może częściowo, ale nie całkowicie), ponieważ w takim przypadku nie będzie możliwe ich odszyfrowanie i pobranie z niego właściwości użytkowników.

Ale Twoje pytanie wydaje się próbować znaleźć odpowiedzi na temat funkcji tokena okaziciela:

Załóżmy, że implementuję dostawcę autoryzacji, czy mogę podać dowolny ciąg dla tokena okaziciela? Czy może to być losowy ciąg? Czy musi to być kodowanie base64 niektórych atrybutów? Czy powinien być zaszyfrowany?

Spróbuję więc wyjaśnić, jak działają tokeny okaziciela i tokeny odświeżania:

Gdy użytkownik wysyła do serwera token wysyłający użytkownika i hasło przez SSL, serwer zwraca dwie rzeczy: token dostępu i token odświeżania .

Token dostępu to token okaziciela, który należy dodać we wszystkich nagłówkach żądań, aby zostały uwierzytelnione jako konkretny użytkownik.

Authorization: Bearer <access_token>

Token dostępu to zaszyfrowany ciąg znaków zawierający wszystkie żądane właściwości użytkownika, oświadczenia i role. (Możesz sprawdzić, czy rozmiar tokenu zwiększa się, jeśli dodasz więcej ról lub roszczeń). Gdy serwer zasobów otrzyma token dostępu, będzie mógł go odszyfrować i odczytać te właściwości użytkownika. W ten sposób użytkownik zostanie zweryfikowany i nadany wraz z całą aplikacją.

Tokeny dostępu mają krótki okres ważności (tj. 30 minut). Gdyby tokeny dostępu miały długi okres ważności to byłby problem, bo teoretycznie nie ma możliwości ich unieważnienia. Wyobraź sobie więc użytkownika z rolą = „Administrator”, która zmienia się na „Użytkownik”. Jeśli użytkownik zachowa stary token z rolą = "Admin", będzie mógł uzyskać dostęp do wygaśnięcia tokena z uprawnieniami administratora. Dlatego tokeny dostępu mają krótki okres ważności.

Ale pojawia się jedna kwestia. Jeśli token dostępu ma krótki okres ważności, musimy co krótki okres wysyłać użytkownika i hasło. Czy to jest bezpieczne? Nie, nie jest. Powinniśmy tego unikać. Wtedy pojawiają się tokeny odświeżania, które rozwiązują ten problem.

Tokeny odświeżania są przechowywane w DB i będą miały długi okres ważności (przykład: 1 miesiąc).

Użytkownik może otrzymać nowy token dostępu (po jego wygaśnięciu, na przykład co 30 minut) za pomocą tokena odświeżania, który otrzymał w pierwszym żądaniu tokenu. Po wygaśnięciu tokenu dostępu klient musi wysłać token odświeżania. Jeśli ten token odświeżania istnieje w DB, serwer zwróci klientowi nowy token dostępu i inny token odświeżania (i zastąpi stary token odświeżania nowym).

W przypadku złamania token dostępu użytkownika, token odświeżania tego użytkownika musi zostać usunięty z bazy danych. W ten sposób token będzie ważny tylko do wygaśnięcia tokenu dostępu, ponieważ gdy haker spróbuje uzyskać nowy token dostępu, wysyłając token odświeżania, ta akcja zostanie odrzucona.

— Xavier Egea
źródło

Nie rozumiem tej części: „Gdy serwer autoryzacji otrzyma token dostępu, będzie mógł go odszyfrować i odczytać właściwości użytkownika. W ten sposób użytkownik zostanie zweryfikowany i przyznany w całej aplikacji”. Czy to nie serwer autoryzacyjny przyznaje token dostępu, a nie go otrzymuje? Próbuję poradzić sobie z tym tematem i wiele przykładów wyraźnie odróżnia serwer autoryzacji od serwera zasobów. Zrozumiałem, że otrzymujesz token dostępu z serwera autoryzacji, a następnie przekazujesz go wraz z każdym żądaniem do serwera zasobów?

— kivikall

@kivikall Masz rację. Zmieniłem to w odpowiedzi. Serwer zasobów otrzymuje token (token zaszyfrowany przez serwer autoryzacji w procesie tworzenia tokenu) w każdym żądaniu i odszyfrowuje go.

— Xavier Egea

@kivikall Właściwie odszyfrowanie tokena powinno być czymś związanym z autoryzacją, więc powinno należeć do serwera autoryzacji. Dlatego napisał to w odpowiedzi. Ale w praktyce oznaczałoby to, że w każdym żądaniu musisz zweryfikować z serwerem autoryzacyjnym otrzymany token (być może wykonując kolejne żądanie). Dlatego, aby uniknąć utraty wydajności, lepiej jest udostępnić część funkcji odszyfrowywania tokenu na serwerze zasobów. Sprawdź następny link: stackoverflow.com/questions/12296017/…

— Xavier Egea

Jednak przy każdym żądaniu serwer zasobów powinien sprawdzić, czy podany AccessToken jest ważny w stosunku do serwera autoryzacji. Więc jeśli rola się zmieni, zmiana może zostać natychmiast odzwierciedlona przez Auth Server, prawda? Dlaczego mielibyśmy usuwać RefreshToken, jeśli AccessToken został naruszony? Nie można obliczyć RefreshToken na podstawie AccessToken, więc po jego wygaśnięciu haker jest ponownie blokowany.

— mandarynka

Jak powiedziałem, token dostępu zawiera informacje o użytkowniku, takie jak rola. Jeśli rola użytkownika ulegnie zmianie, ta zmiana zostanie odzwierciedlona w następnym tokenie po wygaśnięciu bieżącego tokenu. Oznacza to, że w krótkim czasie (do wygaśnięcia tokena dostępu) użytkownik będzie pełnił tę samą rolę, a Auth Server na to pozwoli, ponieważ token jest nadal ważny. Jeśli chodzi o drugie pytanie, usunięcie Refresh Token powoduje, że użytkownik ponownie wprowadza swoje poświadczenia. Właśnie tego chcemy, jeśli skompilowany jest token dostępu. W innym przypadku haker może zostać autoryzowany do wygaśnięcia tokena odświeżającego (np. 1 miesiąc)

— Xavier Egea

Token okaziciela to jedno lub więcej powtórzeń alfabetu, cyfry, „-”, „”. , „_”, „~”, „+”, „/” a następnie 0 lub więcej „=”.

RFC 6750 2.1. Pole nagłówka żądania autoryzacji (format to ABNF (rozszerzony BNF))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Wygląda jak Base64, ale zgodnie z Czy token w nagłówku powinien być zakodowany w formacie base64? , nie jest.

Zagłębiając się nieco w temat „HTTP / 1.1, część 7: Uwierzytelnianie” **, widzę jednak, że b64token to po prostu definicja składni ABNF zezwalająca na znaki typowo używane w base64, base64url itd. Więc b64token nie zdefiniuj dowolne kodowanie lub dekodowanie, ale raczej po prostu definiuje, jakie znaki mogą być używane w części nagłówka Authorization, która będzie zawierać token dostępu.

Bibliografia

— pon
źródło

W ogóle nie wyjaśniasz celu żetonów okaziciela.

— Jaime Hablutzel