J'essaie toujours de trouver la meilleure solution de sécurité pour protéger les API REST, car le nombre d'applications mobiles et d'API augmente chaque jour.
J'ai essayé différentes méthodes d'authentification, mais il y a toujours des malentendus. J'ai donc besoin des conseils de quelqu'un de plus expérimenté.
Laissez-moi vous dire comment je comprends tout ça. Si je comprends quelque chose de mal, s'il vous plaît faites le moi savoir.
Dans la mesure où l'API REST est sans état, de même que WEB en général, nous devons envoyer des données d'authentification dans chaque demande (cookies, jeton, etc.). Je connais trois mécanismes largement utilisés pour authentifier l'utilisateur
Jeton avec HTTPS. J'ai souvent utilisé cette approche avec HTTPS. Si l'utilisateur fournit un mot de passe et une connexion corrects, il recevra un jeton en réponse et l'utilisera pour les demandes ultérieures. Le jeton est généré par le serveur et stocké, par exemple dans la table séparée ou de la même manière que les informations utilisateur sont stockées. Donc, pour chaque requête, le serveur vérifie si l'utilisateur a un jeton et qu'il est identique à celui de la base de données. Tout est assez simple.
JWT Token. Ce jeton est auto-descriptif, il contient toutes les informations nécessaires sur le jeton lui-même. L'utilisateur ne peut pas modifier, par exemple, la date d'expiration ou toute autre revendication, car ce jeton est généré (signé) par le serveur avec le mot clé secret. Ceci est également clair. Mais un gros problème, personnellement pour moi, comment invalider un jeton.
OAuth 2. Je ne comprends pas pourquoi cette approche devrait être utilisée lorsque la communication est établie directement entre le serveur et le client. Autant que je sache, le serveur OAuth est utilisé pour émettre un jeton avec une portée restreinte afin de permettre à d'autres applications d'accéder aux informations utilisateur sans stocker de mot de passe ni de connexion. C'est une excellente solution pour les réseaux sociaux. Lorsque l'utilisateur souhaite s'inscrire sur une page, le serveur peut demander des autorisations pour obtenir des informations sur l'utilisateur, par exemple sur Twitter ou Facebook, et remplir les champs d'enregistrement avec les données de l'utilisateur, etc.
Envisagez le client mobile pour la boutique en ligne.
Première question devrais-je préférer JWT au premier jeton de type? Dans la mesure où j'ai besoin de connexion / déconnexion d'un utilisateur sur un client mobile, je dois stocker un jeton quelque part ou, en cas de JWT, un jeton doit être invalidé à la déconnexion. Différentes approches sont utilisées pour invalider le jeton. L’une des méthodes consiste à créer une liste de jetons non valide (liste noire). Hmm. La table / le fichier aura une taille beaucoup plus grande que si le jeton était stocké dans la table et associé à l'utilisateur, et simplement supprimé lors de la déconnexion.
Alors, quels sont les avantages du jeton JWT?
Deuxième question sur OAuth, devrais-je l'utiliser en cas de communication directe avec mon serveur? A quoi sert une couche supplémentaire entre le client et le serveur pour émettre un jeton, mais la communication ne se fera pas avec oauth server mais avec le serveur principal. Si je comprends bien, le serveur OAuth n’est responsable que de donner aux tiers des autorisations (jetons) d’accéder aux informations personnelles de l’utilisateur. Mais mon application client mobile n'est pas une tierce partie.