Intestazione di autorizzazione HTTP personalizzata

124

Mi chiedevo se fosse accettabile inserire dati personalizzati in un'intestazione di autorizzazione HTTP. Stiamo progettando un'API RESTful e potrebbe essere necessario un modo per specificare un metodo di autorizzazione personalizzato. Ad esempio, chiamiamolo FIRE-TOKENautenticazione.

Qualcosa del genere sarebbe valido e consentito secondo le specifiche: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

La prima parte della seconda stringa (prima di ':') è la chiave API, la seconda parte è un hash della stringa di query.

— NRaf
fonte

133

Il formato definito in RFC2617 è credentials = auth-scheme #auth-param. Quindi, d'accordo con fumanchu, penso che il sistema di autorizzazione corretto sarebbe simile

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

Dov'è FIRE-TOKENlo schema e le due coppie chiave-valore sono i parametri di autenticazione. Anche se credo che le virgolette siano opzionali (dall'Appendice B di p7-auth-19) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

Credo che questo si adatti agli standard più recenti, sia già in uso (vedi sotto) e fornisce un formato valore-chiave per una semplice estensione (se hai bisogno di parametri aggiuntivi).

Alcuni esempi di questa sintassi auth-param possono essere visti qui ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

— StarTrekRedneck
fonte

4

Semplice API di archiviazione di Amazon offre un altro esempio.

— vescovo,

18

Inseriscilo in un'intestazione separata e personalizzata.

Il sovraccarico delle intestazioni HTTP standard probabilmente causerà più confusione di quanto valga la pena e violerà il principio della minima sorpresa . Potrebbe anche portare a problemi di interoperabilità per i programmatori dei client API che desiderano utilizzare kit di strumenti standard che possono gestire solo la forma standard delle tipiche intestazioni HTTP (come Authorization).

— Brian Kelly
fonte

3

Questo potrebbe essere più difficile da ottenere di quanto sembri. Il link fornito da fumanchu (in un commento alla sua risposta) spiega perché l'introduzione di un'intestazione personalizzata aggiunge l'onere aggiuntivo di dover ora impostare manualmente il Cache-Control correttamente.

— Jon-Eric,

4

Inoltre, se si sta effettuando una richiesta di origine incrociata tramite il browser, ci si trova ora in territorio pre-volo solo a causa dell'intestazione personalizzata in cui altrimenti sarebbe stato possibile evitarlo. Per alcune applicazioni, queste richieste si sommano.

— Wil Moore III,

31

Enorme no alle intestazioni di autenticazione personalizzate. L' Authorizationintestazione spec-standard con il tuo schema personalizzato dovrebbe essere più che sufficiente. Inoltre eviti le richieste di origine pre-volo come indica @wilmoore. Gli schemi personalizzati non interferiscono con nessun server HTTP ragionevolmente moderno di cui io sia a conoscenza, inoltre se usi il tuo schema personale, dovrai analizzarlo tu stesso - nessuna libreria dovrebbe essere in conflitto (altrimenti la biblioteca è scritta male).

— Les Hazlewood,

7

Un buon motivo per trasmettere le credenziali Authorizationnell'intestazione, piuttosto che in un'intestazione personalizzata, è che i proxy e i logger sanno come trattare le informazioni come sensibili.

— Eron Wright,

15

No, questa non è una produzione valida secondo la definizione di "credenziali" in RFC 2617 . Fornisci uno schema auth valido, ma i valori di auth-param devono avere il formato token "=" ( token | quoted-string )(vedi sezione 1.2) e il tuo esempio non usa "=" in quel modo.

— fumanchu
fonte

1

Non è corretto Vedere la pagina 5 del documento per un formato di esempio: Autorizzazione: QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

È vero. Ma come dice tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 , "La notazione" b64token "è stata introdotta per la compatibilità con gli schemi di autenticazione esistenti e può essere utilizzata solo una volta per sfida / credenziali. I nuovi schemi dovrebbero quindi utilizzare la sintassi "auth-param", perché altrimenti le future estensioni saranno impossibili. " Vedi anche la discussione sulla cache lì relativa al fare auth nelle intestazioni personalizzate.

— fumanchu,

9

Vecchia domanda che conosco, ma per i curiosi:

Che ci crediate o no, questo problema è stato risolto ~ 2 decenni fa con HTTP BASIC, che passa il valore come nome utente con codifica base64: password. (Vedi http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Potresti fare lo stesso, in modo che l'esempio sopra diventi:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— Mike Marcacci
fonte

4

Vorrei sconsigliare questa risposta, poiché, per un commento su un'altra risposta qui , la notazione utilizzata qui è per la compatibilità con gli schemi esistenti e non è consigliata per le nuove estensioni.

— Whymarrh,