Autoriser un accès HTTP à ses ressources par
une partie tierce, sans donner ses identifiants (credentials).
Analyse
OAuth vise à :
vérifier l'autorisation conférée au propriétaire de ressource
vérifier l'identité du client faisant une requête
OAuth 2.0 définit 4 rôles en déclinant le "serveur" de OAuth 1.0 en 2 rôles distincts:
le client (front end ou consumer)
serveur de ressource (resource server), recevant les demandes de ressources avec jetons
d'accès (access tokens) et les fournissant si elles sont valides ;
serveur d'autorisation (authorization server) qui fournit au client des jetons
d'accès (access tokens, en échange d'un code d'autorisation typiquement) aux ressources
demandées, après authentification et autorisation du propriétaire de ressources.
le propriétaire de ressource (resource owner) ou "utilisateur final" (end user) vers qui on se tournera pour lui demander s'il autorise u, accès, sans pour autant
dévoiler son identité.
Il existe également des spécialisations de OAuth 2.0 pour :
Pour permettre de déléguer l'autorisation à un service tiers (Google par exemple), OAuth 2.x ajoute un 4ᵉ
rôle en permettant de séparer le rôle serveur de OAuth 1.x en :
OAuth 2.x définit également les formes possibles d'une autorisation donnée par le propriétaire de ressource :
un code d'autorisation (authorization code)
une autorisation implicite (implicit) qui évite la phase d'authentification du client
un mot de passe (password)
des identifiants client (client credentials)
Il existe également un mécanisme d'extensibilité pour ajouter d'autres formes d'autorisation.