http - best - rest authorization header
Encabezado de autorización HTTP personalizado (4)
Me preguntaba si es aceptable colocar 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 personalizado de autorización. Como ejemplo, vamos a llamarlo autenticación FIRE-TOKEN .
Sería algo así como válido y permitido de acuerdo con la especificación: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
La primera parte de la segunda cadena (antes del '':'') es la clave API, la segunda parte es un hash de cadena de consulta.
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 se vería como
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
Donde FIRE-TOKEN es el esquema y los dos pares clave-valor son los parámetros de autenticación. Aunque creo que las citas son opcionales (del Apendice 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 a continuación) y proporciona un formato de clave-valor para la 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
No, esa no es una producción válida de acuerdo con la definición de "credenciales" en RFC2617 . Usted otorga un esquema de autenticación válido, pero los valores de auth-param deben tener el formato token "=" ( token | quoted-string ) (ver sección 1.2), y su ejemplo no usa "=" de esa manera.
Ponlo en un encabezado personalizado y separado.
La sobrecarga de los encabezados HTTP estándar probablemente genere más confusión de la que merece y violará el principio de menor sorpresa . También podría generar problemas de interoperabilidad para los programadores de cliente de API que deseen utilizar kits de herramientas estándar que solo pueden tratar con la forma estándar de encabezados HTTP típicos (como Authorization ).
Una vieja pregunta que sé, pero para los curiosos:
Lo creas o no, este problema fue resuelto ~ hace 2 décadas con HTTP BASIC, que pasa el valor como base64 codeded username: password. (Ver http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )
Usted podría hacer lo mismo, para que el ejemplo anterior se convierta en:
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==