Czym dokładnie jest token okaziciela OAuth 2.0?

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.

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 [email protected], 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.

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.

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

• RFC 5234 3.6.0 Zmienne powtarzanie: * Reguła
• RFC 2616 2.1 Augmented BNF