Qu'est-ce qu'OAuth 2.0

OAuth2.0 est une continuation du protocole OAuth, mais n'est pas compatible avec OAuth 1.0. OAuth2.0 se concentre sur la simplicité pour les développeurs clients, soit via l'organisation entre les propriétaires de ressources et les fournisseurs de services HTTP. Les interactions approuvées agissent sur. au nom de l'utilisateur, ou permettre à des applications tierces d'accéder au nom de l'utilisateur.

OAuth2.0 est une continuation du protocole OAuth, mais n'est pas compatible avec OAuth 1.0 (c'est-à-dire qu'OAuth1.0 est complètement aboli). OAuth 2.0 se concentre sur la simplicité pour les développeurs clients. Soit en structurant les interactions approuvées entre le propriétaire de la ressource et le fournisseur HTTP au nom de l'utilisateur, soit en autorisant les applications tierces à y accéder au nom de l'utilisateur. Il propose également des processus de certification dédiés aux applications Web, aux applications de bureau, aux téléphones mobiles et aux appareils de salon. En octobre 2012, le protocole OAuth 2.0 a été officiellement publié sous le nom de RFC 6749.

Avant-propos :

OAuth 1.0 est déjà dans l'IETF (International Internet Engineering Task Force), numéroté RFC5849

Cela marque également qu'OAuth a officiellement devenir le protocole standard Internet.

OAuth 2.0 a déjà été discuté et rédigé. OAuth2.0 sera probablement la prochaine génération de normes « d’authentification et d’autorisation des utilisateurs ». La plupart des plateformes ouvertes telles que Baidu Open Platform et Tencent Open Platform utilisent désormais le protocole OAuth 2.0 comme support.

OAuth (Open Authorization) est un standard ouvert qui permet aux utilisateurs de permettre aux applications tierces d'accéder aux ressources privées de l'utilisateur (telles que des photos, des vidéos, des listes de contacts) stockées sur un site Web sans exiger que l'utilisateur nomme et mot de passe sont fournis à des applications tierces.

OAuth

permet aux utilisateurs de fournir un jeton au lieu d'un nom d'utilisateur et d'un mot de passe pour accéder à leurs données stockées auprès d'un fournisseur de services spécifique. Chaque jeton autorise un site Web spécifique (par exemple, un site Web de montage vidéo) à accéder à une ressource spécifique (par exemple, uniquement les vidéos d'un certain album) dans un laps de temps spécifique (par exemple, dans les 2 heures suivantes). De cette manière, OAuth permet aux utilisateurs d'autoriser des sites Web tiers à accéder à leurs informations stockées chez un autre fournisseur de services sans partager leurs autorisations d'accès ni l'intégralité du contenu de leurs données.

OAuth est un complément à OpenID, mais un service complètement différent.

OAuth 2.0

est la prochaine version du protocole OAuth, mais n'est pas rétrocompatible avec OAuth 1.0. OAuth 2.0 se concentre sur la simplicité pour les développeurs clients, tout en fournissant des flux d'authentification spécialisés pour les applications Web, les applications de bureau et les appareils mobiles et de salon. En octobre 2012, le protocole OAuth 2.0 a été officiellement publié sous le nom de RFC 6749 [1].

La nouvelle API Graph de Facebook ne prend en charge que OAuth 2.0. Google a également annoncé la prise en charge de l'API Google pour OAuth 2.0 en mars 2011.

Processus d'authentification et d'autorisation :

Les trois parties impliquées dans le processus d'authentification et d'autorisation comprennent :

1. pour stocker des ressources protégées telles que des photos, des vidéos et des listes de contacts.

2. Utilisateur, propriétaire des ressources protégées stockées chez le fournisseur de services.

3. Client, une application tierce qui souhaite accéder aux ressources du fournisseur de services, généralement un site Web, tel qu'un site Web fournissant des services d'impression de photos. Avant le processus d'authentification, le client doit demander une identité client auprès du fournisseur de services.

Le processus d'utilisation d'OAuth pour l'authentification et l'autorisation est le suivant :

L'utilisateur souhaite exploiter les ressources stockées sur le fournisseur de services.

L'utilisateur se connecte au client et demande un jeton temporaire au fournisseur de services.

Une fois que le prestataire de services a vérifié l'identité du client, il accorde un jeton temporaire.

Une fois que le client a obtenu le jeton temporaire, il dirige l'utilisateur vers la page d'autorisation du fournisseur de services pour demander l'autorisation de l'utilisateur. Au cours de ce processus, le jeton temporaire et la connexion de rappel du client sont envoyés au fournisseur de services.

L'utilisateur saisit son nom d'utilisateur et son mot de passe sur la page web du fournisseur de services puis autorise le client à accéder à la ressource demandée.

Une fois l'autorisation réussie, le fournisseur de services guide l'utilisateur vers la page Web du client.

Le client obtient le jeton d'accès du fournisseur de services sur la base du jeton temporaire.

Le fournisseur de services accorde au client un jeton d'accès basé sur le jeton temporaire et le statut d'autorisation de l'utilisateur.

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

Un bref aperçu historique

OAuth 1.0 est sorti fin décembre 2007 et est rapidement devenu un standard de l'industrie.

En juin 2008, OAuth 1.0 Révision A est sortie. Il s'agit d'une version légèrement modifiée qui corrige principalement une faille de sécurité.

En avril 2010, OAuth 1.0 a finalement été publié dans l'IETF, numéro de protocole RFC 5849.

La version préliminaire d'OAuth 2.0 a été publiée à l'IETF début mai 2011.

OAuth est un protocole de sécurité qui permet aux utilisateurs d'accorder à des tiers l'accès à leurs ressources Web sans partager leurs mots de passe. Les applications peuvent accéder aux ressources Web des utilisateurs sans révéler leurs mots de passe à des applications tierces.

OAuth 2.0 est un tout nouveau protocole et n'est pas rétrocompatible avec les versions précédentes. Cependant, OAuth 2.0 conserve la même architecture globale que la version précédente d'OAuth.

Ce projet est basé sur les besoins et les objectifs d'OAuth2.0 et a fait l'objet d'une discussion d'un an. Les participants à la discussion provenaient de diverses entreprises bien connues du secteur, notamment Yahoo !, Facebook, Salesforce, Microsoft. , Twitter, Deutsche Telekom, Intuit, Mozilla et Google.

Nouvelles fonctionnalités d'OAuth 2.0 :

6 nouveaux processus

Flux d'agent utilisateur – le client s'exécute dans l'agent utilisateur (généralement tel qu'un navigateur Web).

Flux du serveur Web – Le client fait partie du programme du serveur Web et est accessible via une requête http. Il s'agit d'une version simplifiée du processus fourni par OAuth 1.0.

Device Flow – convient au client pour effectuer des opérations sur un appareil restreint, mais l'utilisateur final accède indépendamment au navigateur d'un autre ordinateur ou appareil

Nom d'utilisateur et mot de passe Flow – pour ce processus L'utilisation Le cas est que l'utilisateur fait confiance au client pour gérer les informations d'identification, mais ne souhaite toujours pas que le client stocke son nom d'utilisateur et son mot de passe. Ce processus s'applique uniquement lorsque l'utilisateur a un degré élevé de confiance dans le client.

Flux d'informations d'identification du client – ​​Le client utilise ses informations d'identification pour obtenir le jeton d'accès. Ce flux prend en charge les scénarios OAuth à deux étapes.

Flux d'assertion – Le client échange une assertion contre un jeton d'accès, tel qu'une assertion SAML.

Les applications natives peuvent prendre en charge OAuth (applications exécutées sur un système d'exploitation de bureau ou un appareil mobile) en utilisant les processus ci-dessus.

la prise en charge des applications (applications exécutées sur un ordinateur de bureau ou un appareil mobile)) peut être implémentée en utilisant plusieurs des flux ci-dessus.

jeton de confiance

OAuth 2.0 fournit une méthode d'authentification qui ne nécessite pas de cryptage. Cette méthode est basée sur l'architecture de vérification des cookies existante. secret, envoyez-le via HTTPS, remplaçant ainsi la méthode de cryptage et d'envoi via HMAC et le jeton secret. Cela permettra d'utiliser cURL pour lancer des appels API et d'autres outils de script simples sans suivre la méthode de demande et de signature d'origine.

Simplification de la signature :

Pour la prise en charge des signatures, le mécanisme de signature est grandement simplifié et ne nécessite pas d'analyse, d'encodage et de tri spéciaux des paramètres. Utilisez un secret pour remplacer les deux secrets d'origine.

Jetons à court terme et informations d'identification à long terme

L'OAuth d'origine émettrait un jeton avec une très longue période de validité (généralement un an ou aucune limite de validité). Le serveur émettra un jeton d'accès à courte validité et un jeton d'actualisation de longue durée. Cela permettra au client d'obtenir un nouveau jeton d'accès sans que l'utilisateur ait à le refaire, et limitera également la période de validité du jeton d'accès.

Séparation des rôles

OAuth 2.0 sera divisé en deux rôles :

Le serveur d'autorisation est responsable de l'obtention de l'autorisation de l'utilisateur et de l'émission des jetons.

La ressource est responsable de la gestion des appels API.

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!