Client faisant face à l'authentification API REST

Question

J'ai vu beaucoup de messages différents concernant différentes solutions pour authentifier une API RESTful et j'ai quelques questions, étant donné ce scénario actuel.

J'ai créé une API REST qui permettra aux clients de mon service logiciel (nous sommes une société B2B) d'accéder aux ressources par programmation. Maintenant que l'API fonctionne correctement, j'aimerais la sécuriser de la manière la plus standardisée possible. Je dois autoriser l'accès à certaines ressources en fonction de l'appelant de l'API. C'est-à-dire que tous les utilisateurs de l'API ne peuvent pas accéder à toutes les ressources.

J'ai URLS disponibles dans les formats suivants:

https://mydomain/api/students 
https://mydomain/api/students/s123 
https://mydomain/api/students/s123/classes 
https://mydomain/api/students/s123/classes/c456 

Jusqu'à présent, je suis venu avec ces solutions possibles:

1. une clé unique Fournir à chaque client qu'ils peuvent utiliser pour finalement générer un jeton chiffré qui sera passé en paramètre GET à la fin de chaque appel REST pour (re) authentifier chaque requête unique. Cette approche est trop cher

   https://mydomain.com/api/students/s123?token=abc123

2. Fournir une valeur dans l'en-tête HTTP d'autorisation comme on le voit here. Est-ce presque la même chose que # 1? (Sauf que je ne peux pas coller une URL dans le navigateur) Les gens utilisent-ils ces en-têtes?

3. Utilisez OAuth 2 (que je ne suis toujours pas clair sur). OAuth 2 authentifie-t-il réellement le client en tant qu'utilisateur connecté? Et cela ne va-t-il pas à l'encontre de l'esprit d'une API REST qui serait apatride? J'espérais qu'OAuth était la bonne solution pour moi (puisque c'est une norme publique), mais après en avoir lu un peu, je ne suis pas si sûr. Est-ce trop et/ou incorrect pour les appels API REST?

Mon but est de fournir une API qui ne doit être changé pour chaque client qui veut consommer l'API, mais que je peux fournir une documentation standard mis à la disposition de tous nos clients.

Je serai heureux de poster des détails supplémentaires si je n'ai pas été clair.

Answer 1

Il y a 2 types de clients que vous voulez sans doute pour préparer votre API:

• clients de confiance - qui sont écrites par vous. Ils peuvent avoir le nom d'utilisateur et le mot de passe de l'utilisateur réel, et ils peuvent envoyer ces données à votre serveur à chaque requête, éventuellement dans un en-tête auth HTTP. Tout ce dont vous avez besoin est une connexion cryptée par eux.

• Clients tiers - Qui sont écrits par un développeur aléatoire. Vous pouvez les enregistrer dans votre service et ajouter une clé API unique à chacun d'entre eux. Après cela, si un utilisateur souhaite utiliser ses services, vous devez lui montrer une invite dans laquelle il peut autoriser l'accès au client tiers. Après cela, le client tiers sera affecté au compte de l'utilisateur avec les autorisations données et il recevra un jeton d'accès spécifique à l'utilisateur. Ainsi, lorsque le client envoie sa clé API et le jeton spécifique à l'utilisateur avec la requête, il envoie les demandes au nom de l'utilisateur.

OAuth peut vous aider à contrôler la deuxième situation.

Vos URL n'ont pas de signification pour les clients. Par REST vous devez découpler les clients de la structure d'URL en envoyant des liens annotés avec la sémantique (par exemple les relations de lien). Donc, votre documentation ne doit rien contenir sur la structure de l'URL (peut-être que cela peut être utile pour le débogage côté serveur, mais rien de plus). Vous devez parler de différents types de liens. En générant ces liens côté serveur, vous pouvez vérifier les autorisations de l'utilisateur réel (ou du client tiers) et ignorer les liens qu'il n'a pas l'autorisation de suivre.