Tipo di intestazione autorizzazione HTTP migliore per JWT

Question

Mi chiedo quale sia il tipo di intestazione HTTP Authorization appropriato per JWT tokens.

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

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

Inoltre, ho sentito parlare di Portatore tipo, per esempio:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

Tuttavia, non so il suo significato. È legato agli orsi?

C'è un modo particolare per utilizzare i token JWT nell'intestazione HTTP Authorization? Dovremmo usare Bearer, o dobbiamo semplificare e basta usare:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

Grazie.

Edit:

O forse, solo un colpo di testa JWT HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

Answer 1

A Il token JWT può essere utilizzato senza OAuth.

Quindi, un semplice "Authorization: JWT <your_token>" sarebbe più appropriato.

Esempio:

curl -H "Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" https://api.domain.tld/me/account 

Answer 2

Il miglior intestazione HTTP per il vostro client di inviare un token di accesso (JWT o qualsiasi altro token) è la Authorization intestazione con lo schema di autenticazione Bearer.

Questo schema è descritto dallo RFC6750.

Esempio:

GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ

Se avete bisogno di maggiore protezione di sicurezza, si può anche considerare il seguente progetto di 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 questa RFC e le specifiche sopra riportate sono correlate al protocollo OAuth2 Framework, possono essere utilizzate in qualsiasi altro contesto che richiede uno scambio di token tra un client e un server.

A differenza dello schema personalizzato JWT indicato nella domanda, the Bearer one is registered at the IANA.

Per quanto riguarda gli schemi di autenticazione Basic e Digest, si sono dedicati a autenticazione utilizzando un nome utente e un segreto (vedi RFC7616 e RFC7617) e quindi non applicabile in tale contesto.

Answer 3

È legato agli orsi?

Errr ... No!

Ecco la definizione di portatore Token secondo il RFC 6750:

1.2. Terminology

portatore Token

un token di sicurezza con la proprietà che una parte in possesso del token (un "portatore") può usare il gettone in qualsiasi modo possibile a qualsiasi altra parte in suo possesso. L'uso di un token al portatore non richiede un portatore per dimostrare il possesso di materiale chiave crittografico (proof-of-possession).

Lo schema Bearer è originariamente definito nel RFC 6750 per il framework di autorizzazione OAuth 2.0, ma nulla vi impedisce di utilizzare lo schema di Bearer per i token di accesso nelle applicazioni che non utilizzano OAuth 2.0.

Attenersi agli standard il più possibile e non creare schemi di autenticazione personalizzati.

---

Un token di accesso deve essere inviato nell'intestazione Authorization richiesta utilizzando lo schema di autenticazione Bearer:

2.1. Authorization Request Header Field

Quando si invia il token di accesso nel campo di intestazione Authorization richiesta definito da HTTP/1.1, il client utilizza lo schema di autenticazione Bearer per trasmettere il token di accesso.

Ad esempio:

richieste

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

[...]

I clienti dovrebbero fare autenticati con un token portatore utilizzando il campo di intestazione Authorization richiesta con il regime di autorizzazione Bearer HTTP. [...]

In caso di non validi o mancanti di token, lo schema Bearer dovrebbe essere incluso nell'intestazione WWW-Authenticate risposta:

3. The WWW-Authenticate Response Header Field

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

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. [...].

Per esempio, in risposta ad 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 tramite un token di accesso scaduto:

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