Najlepszy typ nagłówka autoryzacji HTTP dla JWT

Zastanawiam się, jaki jest najlepszy odpowiedni Authorizationtyp nagłówka HTTP dla tokenów JWT .

Jednym z prawdopodobnie najbardziej popularnych typów jest Basic. Na przykład:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Obsługuje dwa parametry, takie jak login i hasło. Nie dotyczy to tokenów JWT.

Słyszałem także o typie okaziciela , na przykład:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Jednak nie znam jego znaczenia. Czy to dotyczy niedźwiedzi?

Czy istnieje konkretny sposób użycia tokenów JWT w Authorizationnagłówku HTTP ? Czy powinniśmy skorzystać Bearer, czy też powinniśmy uprościć i po prostu użyć:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Dzięki.

Edytować:

A może po prostu JWTnagłówek HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Najlepszym nagłówkiem HTTP dla klienta, który wysyła token dostępu (JWT lub dowolny inny token), jest Authorizationnagłówek ze Bearerschematem uwierzytelniania.

Ten schemat jest opisany przez RFC6750 .

Przykład:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

Jeśli potrzebujesz silniejszej ochrony bezpieczeństwa, możesz również rozważyć następujący projekt IETF: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture . Ten projekt wydaje się być dobrą alternatywą dla (porzuconego?) Https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac .

Należy zauważyć, że nawet jeśli niniejsza specyfikacja RFC i powyższe specyfikacje są powiązane z protokołem OAuth2 Framework, można ich używać w innych kontekstach wymagających wymiany tokena między klientem a serwerem.

W przeciwieństwie do JWTschematu niestandardowego wymienionego w pytaniu, ten Bearerjest zarejestrowany w IANA .

Jeśli chodzi o schematy Basici Digestuwierzytelnianie, są one dedykowane do uwierzytelniania przy użyciu nazwy użytkownika i hasła (patrz RFC7616 i RFC7617 ), więc nie mają zastosowania w tym kontekście.

Krótka odpowiedź

BearerSchemat uwierzytelniania jest to, czego szukasz.

Długa odpowiedź

Czy to dotyczy niedźwiedzi?

Errr ... Nie :)

Zgodnie ze słownikami Oxford , oto definicja okaziciela :

nosiciel _{^{/ ˈbɛːrə /}}
rzeczownik

1. Osoba lub rzecz, która coś niesie lub trzyma.

2. Osoba, która przedstawia czek lub inne polecenie zapłaty.

Pierwsza definicja obejmuje następujące synonimy: posłaniec , agent , przenośnik , emisariusz , przewoźnik , dostawca .

A oto definicja tokena okaziciela zgodnie z RFC 6750 :

1.2 Terminologia

Token na okaziciela

Token zabezpieczający z właściwością, którą dowolna strona będąca w posiadaniu tokena („nosiciel”) może wykorzystać w dowolny sposób, jak każda inna strona będąca w jego posiadaniu. Korzystanie z tokena okaziciela nie wymaga okazania dowodu posiadania materiału klucza kryptograficznego (dowodu posiadania).

BearerSchemat uwierzytelniania jest zarejestrowany w IANA i pierwotnie zdefiniowane w RFC 6750 dla ram autoryzacji OAuth 2.0, ale nic nie stoi na przeszkodzie użyciu Bearersystem tokenów dostępowych w aplikacjach, które nie korzystają z protokołu OAuth 2.0.

Trzymaj się standardów w jak największym stopniu i nie twórz własnych schematów uwierzytelniania.

Token dostępu należy wysłać w Authorizationnagłówku żądania przy użyciu Bearerschematu uwierzytelniania:

2.1 Pole nagłówka żądania autoryzacji

Podczas wysyłania tokena dostępu w Authorizationpolu nagłówka żądania zdefiniowanym przez HTTP / 1.1 klient używa Bearerschematu uwierzytelnienia do przesłania tokena dostępu.

Na przykład:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[...]

Klienci POWINNI składać uwierzytelnione żądania za pomocą tokena nośnika, używając Authorizationpola nagłówka żądania ze Bearerschematem autoryzacji HTTP. [...]

W przypadku nieprawidłowego lub brakującego tokena Bearerschemat powinien zostać zawarty w WWW-Authenticatenagłówku odpowiedzi:

3. Pole nagłówka odpowiedzi uwierzytelnienia WWW

Jeśli żądanie chronionego zasobu nie zawiera poświadczeń uwierzytelnienia lub nie zawiera tokena dostępu, który umożliwia dostęp do chronionego zasobu, serwer zasobów MUSI zawierać WWW-Authenticatepole nagłówka odpowiedzi HTTP [...].

Wszystkie wyzwania zdefiniowane w tej specyfikacji MUSZĄ używać wartości schematu uwierzytelniania Bearer. Po schemacie MUSI następować jedna lub więcej wartości auth-param. [...]

Na przykład w odpowiedzi na żądanie chronionego zasobu bez uwierzytelnienia:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

W odpowiedzi na żądanie zasobów chronionych próbą uwierzytelnienia przy użyciu wygasłego tokena dostępu:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"