Présentation de plusieurs méthodes d'authentification de sécurité Web couramment utilisées

Cet article présente cinq méthodes d'authentification de sécurité Web couramment utilisées, qui ont une certaine valeur de référence. J'espère qu'il pourra être utile à tout le monde.

1. Authentification de base Http

Il s'agit de la méthode d'authentification de sécurité la plus ancienne. Cette méthode consiste simplement à apporter le nom d'utilisateur et le mot de passe consultés lors de l'accès à l'API, car les informations seront exposées. il est de moins en moins utilisé. Des méthodes d'authentification plus sécurisées et confidentielles sont désormais utilisées. Certaines anciennes plates-formes peuvent encore l'utiliser.

Comme le montre l'image ci-dessous, une boîte apparaîtra pour vous permettre de saisir votre nom d'utilisateur et votre mot de passe. Il s'agit de l'authentification HTTPBasic fournie avec Tomcat.

Ceci est votre identifiant pour accéder à l'application. La chaîne xxxXXX a été écrite par moi pour indiquer qu'il s'agit d'un texte chiffré. De quel type de texte chiffré s'agit-il ? sont des textes chiffrés obtenus après le cryptage Base64. Alors, ressentez-vous la même chose maintenant : c'est trop facile à voler, donc les nouvelles applications utilisent rarement cette méthode maintenant. Même si elle est simple, le niveau de sécurité est trop faible.

2. OAuth2

Mon blog précédent a présenté OAuth2 et l'utilisation d'Azure AD pour implémenter l'authentification OAuth2. Ici, j'extraireai une partie du contenu de ce blog pour que tout le monde puisse le résumer et l'examiner.

https://blog.csdn.net/aHardDreamer/article/details/88650939

OAuth est : Open Authrisation (autorisation ouverte). Il s'agit d'un standard ouvert qui permet aux utilisateurs de permettre aux applications tierces d'accéder aux ressources privées de l'utilisateur stockées sur un site Web sans fournir le nom d'utilisateur et le mot de passe à des tiers. . Par exemple, nous sommes habitués à nous connecter à des plateformes tierces via QQ/WeChat/Weibo, etc. Il y a eu de nombreuses failles de sécurité après la sortie d'OAuth 1.0, donc OAuth 1.0 a été complètement aboli dans OAuth 2.0, axé sur la simplicité pour les développeurs clients, ou via un accord approuvé entre le propriétaire de la ressource et le fournisseur de services HTTP. de l'utilisateur, ou permet à une application tierce d'accéder au nom de l'utilisateur. C’est un peu compliqué à lire, mais le principe est en réalité très simple. Veuillez consulter l’explication ci-dessous.

1. Tout d'abord, nous devons comprendre ces trois rôles dans le processus d'authentification et d'autorisation OAuth2 :

1. Fournisseur de services : comme son nom l'indique, les utilisateurs fournissent des services et des ressources protégés. beaucoup de choses y sont stockées.

2. Utilisateur : Une personne qui a enregistré des éléments (photos, informations, etc.) auprès du prestataire de services.

3. Client : l'appelant du service s'il souhaite accéder aux ressources du fournisseur de services, il doit s'inscrire auprès du fournisseur de services, sinon le fournisseur de services ne l'utilisera pas.

2. Processus d'authentification et d'autorisation OAuth2 :

1) L'utilisateur souhaite exploiter les ressources stockées dans le fournisseur de services

2) L'utilisateur se connecte au client ; , et le client Le fournisseur de services demande un jeton temporaire ;

3) Une fois que le fournisseur de services a vérifié l'identité du client, il lui donne un jeton temporaire

4) Une fois que le client a obtenu le jeton temporaire ; jeton, il dirige l'utilisateur vers la page d'autorisation du fournisseur de services et demande l'autorisation de l'utilisateur. (Dans ce processus, le jeton temporaire et le lien/interface de rappel du client seront envoyés au fournisseur de services --- évidemment, le fournisseur de services reviendra pour appeler cette interface après l'authentification et l'autorisation de l'utilisateur)

5 ) L'utilisateur saisit le nom d'utilisateur et le mot de passe pour se connecter. Après une connexion réussie, le client peut être autorisé à accéder aux ressources du fournisseur de services

6) Après une autorisation réussie, le fournisseur de services guidera l'utilisateur vers le site Web du client ; page (appelez le lien/interface de rappel de l'étape 4 à l'intérieur) ;

7) Le client obtient le jeton d'accès officiel du fournisseur de services en fonction du jeton temporaire

8) Le fournisseur de services obtient le ; jeton d'accès officiel basé sur le jeton temporaire et l'autorisation de l'utilisateur. Le client reçoit un jeton d'accès ;

9) Le client utilise le jeton d'accès pour accéder aux ressources protégées de l'utilisateur stockées sur le fournisseur de services.

3. Il existe quatre façons d'obtenir un jeton d'accès (type d'octroi), chacune ayant des scénarios d'application applicables :

1. mode code)

Utilisé en combinaison avec des applications côté serveur ordinaires.

1) L'utilisateur accède au client, et ce dernier dirige le premier vers le serveur d'authentification. En supposant que l'utilisateur accorde l'autorisation, le serveur d'authentification dirige l'utilisateur vers "l'URI de redirection" (URI de redirection) spécifié dans. avance par le client et y joint un code d'autorisation.

2) Le client reçoit le code d'autorisation, joint l'"URI de redirection" précédent et demande un jeton auprès du serveur d'authentification : GET /oauth/token?response_type=code&client_id=test&redirect_uri=Lien de la page de redirection. La requête renvoie avec succès un code d'autorisation de code, qui est généralement valide pendant 10 minutes.

3) Le serveur d'authentification vérifie le code d'autorisation et l'URI de redirection. Après avoir confirmé qu'ils sont corrects, il envoie le jeton d'accès et le jeton d'actualisation au client. POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=Lien de page de redirection. La demande renvoie avec succès le jeton d’accès et actualise le jeton.

(Partage de vidéos d'apprentissage gratuit : Tutoriel vidéo php)

2. Implicite (mode simplifié)

Utiliser en combinaison avec des applications mobiles ou des Web Apps.

Le jeton d'accès est renvoyé directement par le serveur d'autorisation (canal frontal uniquement)

Les jetons d'actualisation ne sont pas pris en charge

Supposons que le propriétaire de la ressource et l'application cliente publique soient sur le même appareil

Le plus vulnérable aux attaques de sécurité

3. Informations d'identification du mot de passe du propriétaire de la ressource

Applicables aux applications clientes de confiance, telles que celles du même organisation ou application externe.

Les applications qui utilisent un nom d'utilisateur et un mot de passe pour se connecter, telles que les applications de bureau

utilisent le nom d'utilisateur/mot de passe comme méthode d'autorisation pour obtenir un jeton d'accès du serveur d'autorisation

le font généralement ne prend pas en charge le jeton d'actualisation

Supposons que le propriétaire de la ressource et le client public se trouvent sur le même appareil

Les informations d'identification du client

sont convient aux clients pour appeler les applications de type API de service principal (telles que Baidu API Store, les microservices entre différents projets s'appellent)

Uniquement les canaux back-end, utilisez les informations d'identification du client pour obtenir un jeton d'accès

Étant donné que les informations d'identification du client peuvent être un cryptage symétrique ou asymétrique, cette méthode prend en charge les mots de passe ou les certificats partagés

3. Authentification de session de cookie

Comparaison des cookies-. Mécanismes d'authentification de session lorsque nous avons appris J2EE pour la première fois. Généralement, un objet Session est créé côté serveur pour une demande d'authentification, et un objet Cookie est créé côté navigateur du client. La gestion de l'état est obtenue en amenant l'objet Cookie apporté par le client ; correspondre à l'objet de session côté serveur. Par défaut, les cookies sont supprimés lorsque nous fermons le navigateur. Mais vous pouvez rendre le cookie valide pendant une certaine période en modifiant le délai d'expiration du cookie

Cependant, ce type d'authentification basée sur la session de cookie rend difficile l'extension de l'application elle-même ; augmentation du nombre d'utilisateurs clients différents, indépendant Le serveur ne peut plus héberger plus d'utilisateurs et des problèmes avec les applications d'authentification basées sur la session seront exposés à ce moment-là.

Problèmes basés sur l'authentification de session :

1) L'augmentation des sessions augmentera la surcharge du serveur

Une fois chaque utilisateur authentifié par notre application, notre application doit Le serveur crée un enregistrement sur faciliter l'identification de la prochaine requête de l'utilisateur. De manière générale, la session est enregistrée en mémoire à mesure que le nombre d'utilisateurs authentifiés augmente, la surcharge du serveur augmente considérablement.

2) Mauvaise adaptabilité dans les environnements distribués ou multi-serveurs

Après l'authentification de l'utilisateur, le serveur effectue des enregistrements d'authentification si les enregistrements d'authentification sont enregistrés en mémoire, cela signifie que l'utilisateur La requête suivante. doit être effectuée sur ce serveur pour que les ressources autorisées puissent être obtenues. Cela limite donc les capacités de l'équilibreur de charge dans les applications distribuées. Cela signifie également limiter l’évolutivité de l’application. Cependant, certains serveurs peuvent désormais partager des sessions entre chaque serveur en définissant des sessions persistantes.

3) Vulnérable aux attaques CSRF

L'identification de l'utilisateur étant basée sur les cookies, si le cookie est intercepté, l'utilisateur sera vulnérable aux attaques de falsification de requêtes intersites

4. Authentification par jeton

Le mécanisme d'authentification basé sur un jeton est similaire au protocole http et est sans état. Il n'a pas besoin de conserver les informations d'authentification ou de session de l'utilisateur sur le serveur. Cela signifie que les applications basées sur le mécanisme d'authentification par jeton n'ont pas besoin de prendre en compte le serveur auquel l'utilisateur se connecte, ce qui facilite l'expansion des applications.

Processus :

L'utilisateur utilise le nom d'utilisateur et le mot de passe pour demander au serveur

Le serveur vérifie les informations de l'utilisateur

Le serveur envoie à l'utilisateur un jeton par vérification

Le client stocke le jeton et envoie la valeur du jeton à chaque demande

Le serveur vérifie la valeur du jeton et renvoie les données

Ce jeton doit être envoyé à chaque request Transmise au serveur, elle doit être enregistrée dans l'en-tête de la requête. De plus, le serveur doit prendre en charge la politique CORS (Cross-Origin Resource Sharing). Généralement, nous pouvons faire cela sur le serveur : Access-Control-Allow-Origin. .

5. Mécanisme d'authentification JWT (Json Web Token)

JWT, en tant que norme ouverte (RFC 7519), définit une méthode concise et personnalisable. sont utilisés pour transférer de manière sécurisée des informations entre les parties communicantes sous la forme d’objets Json. En raison de l'existence de signatures numériques, ces informations sont crédibles et JWT peut être signé à l'aide de l'algorithme HMAC ou de la paire de clés publique-privée RSA.

Simplicité

Peut être envoyé via une URL, des paramètres POST ou dans un en-tête HTTP, car le volume de données est faible et la vitesse de transmission est rapide

Autonome

La charge utile contient toutes les informations requises par l'utilisateur, évitant ainsi plusieurs requêtes vers la base de données

Il est utile d'utiliser JSON Web Token dans les scénarios suivants :

Autorisation : il s'agit du scénario le plus courant pour l'utilisation de JWT. Une fois l'utilisateur connecté, chaque requête suivante contiendra un JWT, permettant à l'utilisateur d'accéder aux itinéraires, services et ressources autorisés par ce jeton. L'authentification unique est une fonctionnalité de JWT qui est désormais largement utilisée car elle entraîne peu de frais généraux et peut être facilement utilisée sur plusieurs domaines.

Échange d'informations : les jetons Web JSON sont sans aucun doute un bon moyen de transmettre des informations en toute sécurité entre les parties. Étant donné que les JWT peuvent être signés, par exemple, avec une paire de clés publique/privée, vous pouvez être sûr que l'expéditeur est bien celui qu'il prétend être. De plus, puisque la signature est calculée à l’aide de l’en-tête et de la charge utile, vous pouvez également vérifier que le contenu n’a pas été falsifié.

Structure de JWT :

À travers cette image, il est clair que la structure de JWT est divisée en trois parties, et elles sont reliées par "." :

En-tête :

L'en-tête se compose généralement de deux parties : le type de jeton ("JWT") et le nom de l'algorithme (tel que : HMAC SHA256 ou RSA, etc.).

Par exemple :

Ensuite, utilisez Base64 pour encoder ce JSON afin d'obtenir la première partie du JWT

Payload :

La deuxième partie du JWT est la charge utile, qui contient les revendications (exigences). Les revendications sont des déclarations sur des entités (généralement des utilisateurs) et d'autres données. Il existe trois types de déclarations : enregistrées, publiques et privées.

Allégations enregistrées : Il existe ici un ensemble d'allégations prédéfinies, elles ne sont pas obligatoires, mais recommandées. Par exemple : iss (émetteur), exp (heure d'expiration), sub (sujet), aud (audience), etc.

Réclamations publiques : peuvent être définies comme vous le souhaitez.

Revendications privées : revendications utilisées pour partager des informations entre des parties qui acceptent de les utiliser, et ne sont pas des revendications enregistrées ou publiques.

Ce qui suit est un exemple :

Encodez en base64 la charge utile pour obtenir la deuxième partie du JWT

Remarque, ne pas inclure dans le JWT Mettez les informations sensibles dans la charge utile ou l'en-tête à moins qu'elles ne soient cryptées.

Signature :

Afin d'obtenir la partie signature, vous devez avoir l'en-tête encodé, la charge utile encodée, une clé secrète, l'algorithme de signature est celui spécifié dans l'en-tête, puis signez-les.

Par exemple :

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

La signature est utilisée pour vérifier si le message est remis lors de la livraison est modifié et, pour les jetons signés avec une clé privée, il peut également vérifier que l'expéditeur du JWT est bien celui qu'il prétend être.

Lorsque vous rencontrez le token JWT, vous pouvez vous rendre sur le site officiel de JWT pour le décrypter. Voici les données décryptées par le site officiel. Vous pouvez clairement voir ses trois parties :

Pour plus d'informations sur JWT, vous pouvez consulter ce blog :

https://www.cnblogs.com/cjsblog/p/9277677.html

Référence :

https://www.jianshu.com/p/f8c43dcd8b69

https://blog.csdn.net/alan_liuyue/article/details/88183267

https ://www .cnblogs.com/cjsblog/p/9277677.html

Recommandations associées :

Sécurité du serveur Web

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!