Nous avons déjà un diagramme et beaucoup de bonnes données, voici donc un exemple au cas où cela pourrait aider.
Disons que je veux publier un commentaire sur StackOverflow. StackOverflow n'autorise les commentaires que si un utilisateur a 50 points de réputation.
StackOverflow doit autoriser cette demande (par exemple, ne l'autoriser que si l'utilisateur a> = 50 rep). StackOverflow n'utiliserait pas OAuth pour ce faire car StackOverflow possède la ressource protégée. Si StackOverflow essayait de publier un commentaire sur Facebook au nom de l'utilisateur, il utiliserait OAuth. Au lieu de cela, StackOverflow utilisera l'autorisation locale (par exemple if (user.reputation < 50) throw InsufficientReputationError (); )
Pour ce faire, StackOverflow doit d'abord savoir qui fait le demande. En d'autres termes, pour autoriser la demande, il doit d'abord authentifier la demande.
StackOverflow vérifie d'abord la session et les en-têtes HTTP pour voir si l'utilisateur peut être rapidement authentifié ( par exemple, ce n'est pas leur première requête) mais cela échoue.
Imaginons que StackOverflow ait décidé d'utiliser OpenID Connect. Cela signifie que StackOverflow approuve un fournisseur d'identité. Il s'agit d'un service approuvé par StackOverflow, qui peut indiquer à StackOverflow qui est l'utilisateur actuel. Dans cet exemple, nous supposerons qu'il s'agit de Google.
StackOverflow demande maintenant à Google qui est l'utilisateur actuel. Cependant, Google doit d'abord s'assurer que StackOverflow est autorisé à savoir qui est l'utilisateur actuel. En d'autres termes, Google doit autoriser StackOverflow. Puisque Google est le propriétaire de la ressource protégée et StackOverflow est celui qui y accède, nous pouvons utiliser OAuth ici. En fait, OpenID Connect l'exige.
Cela signifie que StackOverflow doit s'authentifier auprès d'un serveur d'autorisation en qui Google fait confiance (en réalité, ce serait également Google, mais ce n'est pas forcément le cas) et obtenir un jeton d'accès . Il prend ce jeton d'accès à Google et demande l'identité de l'utilisateur. Google renvoie ensuite l'identité de l'utilisateur (en signant l'identité en cours de route) et StackOverflow autorise ensuite la demande maintenant qu'il connaît l'identité de l'utilisateur.
Au cas où vous l'auriez manqué, il y avait plusieurs étapes d'authentification et d'autorisation chacune.
- StackOverflow a tenté d'authentifier la demande à l'aide de cookies de session, mais cela a échoué.
- StackOverflow a ensuite authentifié la demande à l'aide de OpenID Connect
- Google a autorisé la demande d'identité du SO en utilisant OAuth
- Le serveur d'autorisation authentifié StackOverflow (probablement à l'aide d'un identifiant client & client secret).
- De plus, dans le cadre du workflow OAuth, le serveur d’autorisation peut avoir authentifié la demande en demandant à l’utilisateur son nom d’utilisateur, le mot de passe &.
- En outre, l'utilisateur elle-même peut avoir autorisé la demande d'identité de l'OS en répondant à une subvention écran (par ex. "voulez-vous autoriser StackOverflow à accéder à votre messagerie?")
- StackOverflow a autorisé la demande en s'assurant que l'utilisateur avait> 50 points de réputation.
Qu'est-ce que OpenID (sans la connexion)?
Il s'agissait d'un protocole antérieur qui permettait à un fournisseur d'identité (comme Google) de transmettre des informations utilisateur à un service (comme StackOverflow). Cependant, il a utilisé une autre méthode (pas OAuth) pour que Google autorise StackOverflow à accéder à l'identité de l'utilisateur. OpenID avait quelques failles de sécurité (qui, je crois, ont été corrigées) mais à mon avis, le vrai tueur était simplement le fait qu'OAuth avait un meilleur support et avait donc tendance à être moins de travail que l'apprentissage du protocole personnalisé d'OpenID.
Depuis aujourd'hui, tout le monde l'abandonne. Ne l'utilisez pas. Utilisez OpenID Connect.
"Abuser" d'OAuth
Dans le scénario que j'ai décrit ci-dessus, OAuth est utilisé exactement comme prévu pour l'autorisation. Cependant, il existe un autre flux de travail qui peut souvent dérouter les gens. Cela est dû au fait que dans de nombreuses situations (la plupart?), Le serveur fournissant l'identité de l'utilisateur et le serveur d'autorisation OAuth sont le même serveur.
Dans ce cas, il semble un peu excessif qu'une requête HTTP soit d'abord adressée au serveur d'autorisation pour obtenir un jeton d'accès, puis à nouveau sur le même serveur pour obtenir un jeton d'identité. Ainsi, une extension a été créée pour la spécification OAuth afin de permettre au serveur d'autorisation de regrouper les informations d'identité de l'utilisateur avec le jeton d'accès.
Cela permet à l'authentification de se produire entièrement dans le navigateur (par exemple, StackOverflow's les serveurs n'ont pas besoin d'être impliqués). Cependant, ce type d'authentification est moins utile et (je pense?) Est moins couramment utilisé.