Najlepszy typ nagłówka autoryzacji HTTP dla JWT

228

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
Zag zag ..
źródło

Odpowiedzi:

295

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.

Florent Morselli
źródło
3
Dziękuję Ci! Dobrze jest zobaczyć pochodzenie tego Bearersłowa kluczowego. Ale pochodzi z OAuth. Jednak JWT może być używany bez OAuth. Jest całkowicie niezależny od specyfikacji OAuth.
Zag zag ..
2
Tak, pochodzi z protokołu frameworka OAuth2, ale można go używać w dowolnym innym kontekście. Twój serwer może swobodnie akceptować JWT przy użyciu innych nagłówków lub sposobów (np. W żądaniu treści lub ciągu zapytania), ale Authenticatenagłówek jest bardziej odpowiedni i jest zgodny z RFC7235, który opisuje strukturę uwierzytelniania w kontekście HTTP 1.1
Florent Morselli
1
Zgadzam się z Zag Zag, niestandardowy schemat, taki jak „JWT”, wydaje się o wiele bardziej odpowiedni niż zmuszanie do tego schematu Nośnika OAuth2.
l8nite
50
To powinna być zaakceptowana odpowiedź. Cytowanie jwt.io/introduction „agent użytkownik powinien wysłać JWT, zazwyczaj w nagłówku odpowiedzialnego za pomocą schematu okaziciela treść nagłówka powinna wyglądać następująco: Autoryzacja: okaziciela <token>”
wrschneider
3
Jeśli to komuś pomaga - przyszedłem tutaj, szukając tego przykładu: - zwinąć prośbę za pomocą schematu na okaziciela:curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd>
Kevin Friedheim
76

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"
kasiomolina
źródło
5
Tak. Jest związany z niedźwiedziami. W ten sam sposób, w jaki python jest powiązany z wężami. Duh.
Nicholas Hamilton,
4
Niedźwiedzie .. To wystarczy. Dziękuję za zrobienie mojego dnia.
user2501323,
Czy jest to luka w zabezpieczeniach, jeśli: daję użytkownikowi token, ale kiedy chce wysłać mi żądanie, musi odesłać token z powrotem w treści żądania? Zdobędę go stamtąd i potwierdzę? Naprawdę nie mam innych opcji, ponieważ sposób, w jaki wysyłają żądanie, nie jest zdefiniowany przeze mnie, ale byłbym zainteresowany, czy to będzie złe lub czy istnieje rozwiązanie, które uczyni je bardziej bezpiecznym.
Daniel Jeney