Utilisation personnalisée de l'en-tête d'autorisation dans une API REST

Je construis une API REST où les clients sont authentifiés à l'aide de certificats clients. Dans ce cas, un client n'est pas un utilisateur individuel, mais une sorte de couche de présentation. Les utilisateurs sont authentifiés en utilisant une approche personnalisée et il est de la responsabilité de la couche de présentation de voir que cela est correctement fait (note: je sais que ce n'est pas la bonne approche, mais l'API n'est pas publique).

Je voudrais transmettre le nom d'utilisateur pour chaque demande (pas le mot de passe), mais je ne sais pas où le faire. Serait-ce une bonne idée d'utiliser l'en-tête d'autorisation?

rest authentication headers

— Matsen75
source

Réponses:

Utiliser l'en-tête d'autorisation semble être la bonne chose à faire. C'est tout le but de l'en-tête d'autorisation.

Sur http://tools.ietf.org/html/rfc7235#section-4.2 :

Le champ d'en-tête "Autorisation" permet à un agent utilisateur de s'authentifier auprès d'un serveur d'origine - généralement, mais pas nécessairement, après avoir reçu une réponse 401 (non autorisée). Sa valeur consiste en des informations d'identification contenant les informations d'authentification de l'agent utilisateur pour le domaine de la ressource demandée.

Si vous avez votre propre schéma d'authentification, documentez-le, mais il n'est pas nécessaire de réinventer la roue.

— Zach Dennis
source

Il ne se contente pas sembler être la bonne chose, il est la bonne chose. (J'ai fait des recherches à ce sujet toute la journée) La section 4.1 de la RFC 7235 montre expressément l'utilisation d'un schéma personnalisé "Newauth" dans le "Par exemple", ainsi qu'un schéma standard "Basic" permettant au client d'utiliser son choix de l'un ou l'autre schéma . Cela dit, si vous utilisez un schéma "standard", vous devez l'utiliser correctement. La réponse de Zach est correcte et celle de Filip est incorrecte .

— Stephen P

Je ne vous recommanderais pas d'utiliser de manière non standard un en-tête HTTP standard. Principalement parce qu'il peut être trompeur pour d'autres développeurs qui savent comment l'en- Authoriziationtête est destiné à être utilisé dans l'authentification HTTP, mais aussi pour éviter tout problème potentiel avec d'autres parties de votre pile ayant une connaissance conflictuelle du même en-tête de demande.

Quoi qu'il en soit, rien ne vous empêche d'utiliser un en- X-Authorization-Usertête personnalisé et non standard , spécialement pour vos besoins.

— Filip Dupanović
source

100% d'accord. Si vous voulez faire quelque chose de personnalisé, c'est à cela que X-servent les en-têtes préfixés. Si vous allez utiliser un en-tête standard, ne l'utilisez pas pour quelque chose d'inhabituel ou d'inattendu.

— Carson63000

Je pensais juste que je devrais mentionner que le "X-" a été déprécié: stackoverflow.com/questions/3561381/…

— Matsen75

D'après cette réponse, cela signifie-t-il qu'Amazon S3 se trompe? docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

— Tom Lianza

-1. Comme mentionné par Zach Dennis, contrairement à la plupart des autres en-têtes HTTP, l'en-tête d'autorisation est conçu pour être étendu et il existe un moyen clairement spécifié de définir votre propre schéma d'autorisation. En résumé, assurez-vous simplement d'utiliser un nom de schéma d'autorisation personnalisé.

— Lie Ryan