Comment une API doit-elle utiliser l'authentification de base http

Lorsqu'une API nécessite qu'un client s'authentifie auprès d'elle, j'ai vu deux scénarios différents utilisés et je me demande quel cas utiliser pour ma situation.

Exemple 1. Une API est proposée par une entreprise pour permettre à des tiers de s'authentifier avec un jeton et un secret à l'aide de HTTP Basic.

Exemple 2. Une API accepte un nom d'utilisateur et un mot de passe via HTTP Basic pour authentifier un utilisateur final. Généralement, ils obtiennent un jeton pour les demandes futures.

Ma configuration: je disposerai d'une API JSON que j'utiliserai comme backend pour une application mobile et web. Cela semble être une bonne pratique pour l'application mobile et Web d'envoyer un jeton et un secret afin que seules ces deux applications puissent accéder à l'API bloquant tout autre tiers.

Mais l'application mobile et Web permet aux utilisateurs de se connecter et de soumettre des messages, d'afficher leurs données, etc. Je voudrais donc qu'ils se connectent également via HTTP Basic à chaque demande.

Dois-je utiliser en quelque sorte une combinaison de ces deux méthodes ou envoyer uniquement les informations d'identification de l'utilisateur final (nom d'utilisateur et jeton) à chaque demande? Si j'envoie uniquement les informations d'identification de l'utilisateur final, dois-je les stocker dans un cookie sur le client?

api rest authentication

— Paul Sylling
source

Notez que les cookies ne font pas partie du protocole HTTP et sont simplement une fonctionnalité de navigateur commune. Donc, si vous ne déployez pas pour le Web, oubliez-les.

— Yam Marcovic

Si les cookies ne sont pas recommandés, comment / où stockez-vous les creds pour passer à l'api?

— Paul Sylling

Les cookies ne sont qu'un moyen pour les utilisateurs de navigateur de stocker de manière transparente des jetons de session. Si vous interagissez avec un développeur, cela n'a pas besoin d'être transparent. Vous pouvez configurer un service de connexion publique qui accorde des «tickets», et les développeurs peuvent conserver leur ticket en mémoire ou où ils le souhaitent. Notez que je n'ai aucune expérience pratique des services Web et qu'il existe probablement des solutions standard pour ce genre de choses.

— Yam Marcovic

Que pensez-vous de la partie de ma question sur l'authentification de l'utilisateur final et l'authentification API. Je ne suis toujours pas sûr de cela

— Paul Sylling

Réponses:

L'authentification de base HTTP nécessite l'envoi du nom d'utilisateur et du mot de passe à chaque demande de ressource. Le nom d'utilisateur: le mot de passe est passé dans l'en-tête de demande "Autorisation" chaîne codée en base64 préfixée par "De base". Si toutes vos communications http sont cryptées (via ssl), les informations de l'en-tête d'autorisation ne devraient pas pouvoir être facilement utilisées par les attaquants, car il est peu probable qu'ils puissent les récupérer.

Un http chiffré SSL avec une authentification de base devrait suffire.

— Nathan Pilling
source

pouvez-vous en donner un exemple? C'est ce dont j'ai besoin, juste TRÈS coincé en ce moment ...

— ganders

OAuth / OpenID peut-il fonctionner avec un jeton / secret?

J'ai récemment envisagé le scénario suivant:

Front-end d'application Web
API REST sous-jacente
Applications pour appareils mobiles, accès à l'API REST

Comme simple test, j'ai pu:

Authentifiez les utilisateurs via l'application Web à l'aide d'OAuth
L'API REST autorisée via OAuth, entraînant la génération d'un secret et sa transmission au client
Le périphérique mobile s'authentifierait alors via OAuth, puis serait autorisé par l'API REST via le secret

Cela permettrait à l'application pour appareil mobile de s'authentifier avec les mêmes informations d'identification que via le Web Front End (le même compte) et pourrait également autoriser l'accès à l'API.

— Brendan Green
source

Ainsi, dans votre exemple, seul l'utilisateur s'authentifie. Les clients dans lesquels passent les appels à l'API (application web, application mobile) n'authentifient pas qui ils sont. Théoriquement, l'API est publique et toute application peut publier un nom d'utilisateur et un mot de passe et potentiellement récupérer un jeton

— Paul Sylling

L'utilisateur s'authentifie via l'application et l'application effectue les appels au nom de l'utilisateur. Le processus d'authentification dérive le jeton, que l'application transmet ensuite.

— Brendan Green