Miglior tipo di intestazione di autorizzazione HTTP per JWT

Mi chiedo quale sia il Authorizationtipo di intestazione HTTP più appropriato per i token JWT .

Uno dei tipi probabilmente più popolari è Basic. Per esempio:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Gestisce due parametri come un login e una password. Quindi non è rilevante per i token JWT.

Inoltre, ho sentito parlare del tipo di Bearer , ad esempio:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Tuttavia, non ne conosco il significato. È legato agli orsi?

Esiste un modo particolare di utilizzare i token JWT Authorizationnell'intestazione HTTP ? Dovremmo usare Bearero dovremmo semplificare e usare solo:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Grazie.

Modificare:

O forse, solo JWTun'intestazione HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

La migliore intestazione HTTP per il tuo client per inviare un token di accesso (JWT o qualsiasi altro token) è l' Authorizationintestazione con lo Bearerschema di autenticazione.

Questo schema è descritto dall'RFC6750 .

Esempio:

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

Se hai bisogno di una maggiore protezione della sicurezza, puoi anche considerare la seguente bozza IETF: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture . Questa bozza sembra essere una buona alternativa al (abbandonato?) Https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac .

Si noti che anche se questo RFC e le specifiche sopra riportate sono correlate al protocollo OAuth2 Framework, possono essere utilizzate in tutti gli altri contesti che richiedono uno scambio di token tra un client e un server.

A differenza della personalizzato JWTschema si menziona nella sua interrogazione, l' Beareruno è iscritto alla IANA .

Per quanto riguarda le Basice Digestschemi di autenticazione, sono dedicati a autenticazione utilizzando un nome utente e un segreto (vedi RFC7616 e RFC7617 ) e quindi non applicabile in tale contesto.

Risposta breve

Lo Bearerschema di autenticazione è quello che stai cercando.

Risposta lunga

È legato agli orsi?

Errr ... No :)

Secondo i dizionari di Oxford , ecco la definizione di portatore :

bearer _{^{/ ˈbɛːrə /}}
sostantivo

1. Una persona o cosa che porta o tiene qualcosa.

2. Una persona che presenta un assegno o un altro ordine per pagare denaro.

La prima definizione include i seguenti sinonimi: messaggero , agente , trasportatore , emissario , vettore , fornitore .

Ed ecco la definizione di token al portatore secondo RFC 6750 :

1.2. Terminologia

Toker al portatore

Un token di sicurezza con la proprietà che qualsiasi parte in possesso del token (un "portatore") può utilizzare il token in qualsiasi modo possibile qualsiasi altra parte in possesso di esso. L'uso di un token al portatore non richiede al portatore di dimostrare il possesso di materiale chiave crittografico (prova di possesso).

Lo Bearerschema di autenticazione è registrato in IANA e originariamente definito in RFC 6750 per il framework di autorizzazione OAuth 2.0, ma nulla ti impedisce di utilizzare lo Bearerschema per i token di accesso in applicazioni che non utilizzano OAuth 2.0.

Rispetta gli standard il più possibile e non creare i tuoi schemi di autenticazione.

Un token di accesso deve essere inviato nell'intestazione della Authorizationrichiesta utilizzando lo Bearerschema di autenticazione:

2.1. Campo intestazione richiesta di autorizzazione

Quando si invia il token di accesso nel Authorizationcampo dell'intestazione della richiesta definito da HTTP / 1.1, il client utilizza lo Bearerschema di autenticazione per trasmettere il token di accesso.

Per esempio:

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

[...]

I client DOVREBBERO effettuare richieste autenticate con un token di connessione utilizzando il Authorizationcampo dell'intestazione della richiesta con lo Bearerschema di autorizzazione HTTP. [...]

In caso di token non valido o mancante, lo Bearerschema deve essere incluso nell'intestazione della WWW-Authenticaterisposta:

3. Il campo dell'intestazione della risposta con autenticazione WWW

Se la richiesta di risorsa protetta non include credenziali di autenticazione o non contiene un token di accesso che consente l'accesso alla risorsa protetta, il server di risorse DEVE includere il WWW-Authenticatecampo dell'intestazione della risposta HTTP [...].

Tutte le sfide definite da questa specifica DEVONO utilizzare il valore dello schema di autenticazione Bearer. Questo schema DEVE essere seguito da uno o più valori di auth-param. [...].

Ad esempio, in risposta a una richiesta di risorsa protetta senza autenticazione:

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

E in risposta a una richiesta di risorsa protetta con un tentativo di autenticazione utilizzando un token di accesso scaduto:

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