Encabezado de autorización HTTP personalizado

124

Me preguntaba si es aceptable poner datos personalizados en un encabezado de autorización HTTP. Estamos diseñando una API RESTful y es posible que necesitemos una forma de especificar un método de autorización personalizado. Como ejemplo, llamémosle FIRE-TOKENautenticación.

¿Algo como esto sería válido y permitido según la especificación: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

La primera parte de la segunda cadena (antes de ':') es la clave API, la segunda parte es un hash de cadena de consulta.

— NRaf
fuente

133

El formato definido en RFC2617 es credentials = auth-scheme #auth-param. Entonces, al estar de acuerdo con Fumanchu, creo que el esquema de autorización corregido sería

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

Dónde FIRE-TOKENestá el esquema y los dos pares clave-valor son los parámetros de autenticación. Aunque creo que las citas son opcionales (del Apéndice B de p7-auth-19) ...

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

Creo que esto se ajusta a los últimos estándares, ya está en uso (ver más abajo) y proporciona un formato de clave-valor para una extensión simple (si necesita parámetros adicionales).

Algunos ejemplos de esta sintaxis de auth-param se pueden ver aquí ...

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
fuente

44

La API de almacenamiento simple de Amazon ofrece otro ejemplo.

— obispo

18

Póngalo en un encabezado separado y personalizado.

La sobrecarga de los encabezados HTTP estándar probablemente causará más confusión de lo que vale, y violará el principio de menor sorpresa . También podría generar problemas de interoperabilidad para los programadores de sus clientes API que deseen utilizar kits de herramientas estándar que solo pueden manejar la forma estándar de los encabezados HTTP típicos (como Authorization).

— Brian Kelly
fuente

3

Esto podría ser más difícil de entender de lo que parece. El enlace que proporciona fumanchu (en un comentario a su respuesta) explica por qué la introducción de un encabezado personalizado agrega la carga adicional de tener que configurar manualmente el Control de caché correctamente.

— Jon-Eric

44

Además, si realiza una solicitud de origen cruzado a través del navegador, ahora se encuentra en territorio previo al vuelo solo por el encabezado personalizado donde de lo contrario podría haberlo evitado. Para ciertas aplicaciones, estas solicitudes se suman.

— Wil Moore III

31

Enorme no a los encabezados de autenticación personalizados. El Authorizationencabezado estándar de especificaciones con su propio esquema personalizado debería ser más que suficiente. Además, evita las solicitudes de Origen previas al vuelo como indica @wilmoore. Los esquemas personalizados no interfieren con ningún servidor HTTP razonablemente moderno que conozca, además, si usa su propio esquema, tendrá que analizarlo usted mismo: ninguna biblioteca debería entrar en conflicto (de lo contrario, la biblioteca está mal escrita).

— Les Hazlewood

77

Una buena razón para transmitir credenciales en el Authorizationencabezado, en lugar de hacerlo en un encabezado personalizado, es que los proxies y los registradores saben que la información es confidencial.

— Eron Wright

15

No, esa no es una producción válida según la definición de "credenciales" en RFC 2617 . Usted proporciona un esquema de autenticación válido, pero los valores de parámetro de autenticación deben tener la forma token "=" ( token | quoted-string )(consulte la sección 1.2), y su ejemplo no usa "=" de esa manera.

— fumanchu
fuente

1

Eso no es correcto Consulte la página 5 del documento para ver un formato de ejemplo: Autorización: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

Es verdad. Pero como tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 dice: "La notación" b64token "se introdujo por compatibilidad con los esquemas de autenticación existentes y solo se puede usar una vez por desafío / credenciales. Por lo tanto, los nuevos esquemas deberían utilizar la sintaxis "auth-param", porque de lo contrario las extensiones futuras serían imposibles ". Consulte también la discusión sobre caché allí con respecto a la autenticación en encabezados personalizados.

— fumanchu

9

Antigua pregunta que sé, pero para los curiosos:

Lo creas o no, este problema se resolvió hace ~ 2 décadas con HTTP BASIC, que pasa el valor como nombre de usuario codificado en base64: contraseña. (Ver http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Podrías hacer lo mismo, para que el ejemplo anterior se convierta en:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— Mike Marcacci
fuente

44

Aconsejaría contra esta respuesta, ya que, según un comentario sobre otra respuesta aquí , la notación utilizada aquí es para compatibilidad con esquemas existentes y no se recomienda para nuevas extensiones.

— Whymarrh