OAuth

Open AUTHorization : autorisation ouverte/libre.

Motivation

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 définit différents rôles côté client et côté serveur, selon la version 1 ou 2 du protocole.

Conception

Au-delà du modèle architectural client/serveur qui définit :

une application cliente (front end ou consumer)
un serveur (back end) hébergeant des ressources

OAuth définit clairement le 3ᵉ rô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é.

le propriétaire de ressource (resource owner, end user) qui a le contrôle d'accès aux ressources du serveur

le serveur (service provider) héberge les ressources protégées

le client ou consommateur (consumer) qui n'est pas propriétaire de la resource, mais agit en son nom  accède aux ressources contrôlées par le propriétaire de ressource ;

Il définit 2 processus :

une redirection par le user agent pour autoriser un client à accéder à des ressources ;
des requêtes HTTP authentifiant le client et le propriétaire de ressource ayant autorisé la requête

sequenceDiagram
    Title OAuth 1.x worfklow
    Actor Resource Owner
    Resource Owner->>Server: signup (username, password)
    Resource Owner->>Server: upload (resource)
    Client->>Server: signup (clientId, clientSharedSecret)
    Resource Owner->>Client: useMyResourceFrom (Server)
    Client->>Server: initiate (realm,clientId,callback,hmacSha1Signature)
    Server-->>Client: oauth_token,oauth_token_secret
    Client-->>Resource Owner: redirectTo (server/authorize?oauth_token)
    Resource Owner->>Server: authorize (oauth_token)
    Server-->>Resource Owner: 401 need to sign
    Resource Owner->>Server: signin (username, password)
    Server-->>Resource Owner: Ok to share resource to Client?
    Resource Owner->>Server: yes
    Server-->>Resource Owner: redirect?client/ready?oauth_token&oauth_verifier
    Resource Owner->>Client: ready(oauth_token,oauth_verifier)
    Client->>Server: token(consumer_key,oauth_token,oauth_verifier,signature)
    Server-->>Client: ok(oauth_token,oauth_token_secret)
    Client->>Server: getResource(realm,consumer_key,oauth_token,signature)
    Server-->>Client: resource

On voit donc qu'il existe 3 types d'identifiants (credentials) dans OAuth :

client (consumer key & secret) pour identifier le Client faisant la requête
temporaire (request token & secret) pour la demande d'autorisation
token (access token & secret) pour l'autorisation d'accès

2.x

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 :

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.

sequenceDiagram
    Title OAuth 2.x worfklow
    Actor Resource Owner
    Resource Owner->>Resource Server: signup (username, password)
    Resource Owner->>Resource Server: upload (resource)
    Client->>Resource Server: signup (clientId, clientSharedSecret)
    Resource Owner->>Client: useMyResourceFrom (Server)
    Client->>Resource Server: initiate (realm,clientId,callback,hmacSha1Signature)
    Resource Server-->>Client: oauth_token,oauth_token_secret
    Client-->>Resource Owner: redirectTo (authorizationServer/authorize?oauth_token)
    Resource Owner->>Authorization Server: authorize (oauth_token)
    Authorization Server-->>Resource Owner: 401 need to sign
    Resource Owner->>Authorization Server: signin (username, password)
    Authorization Server-->>Resource Owner: Ok to share resource to Client?
    Resource Owner->>Authorization Server: yes
    Authorization Server-->>Resource Owner: redirect?client/ready?oauth_token&oauth_verifier
    Resource Owner->>Client: ready(oauth_token,oauth_verifier)
    Client->>Authorization Server: token(consumer_key,oauth_token,oauth_verifier,signature)
    Authorization Server-->>Client: ok(oauth_token,oauth_token_secret)
    Client->>Resource Server: getResource(realm,consumer_key,oauth_token,signature)
    Resource Server-->>Client: resource

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.

Implémentation

Debugger

Notes

Stabilisé en octobre 2007, revisé en juin 2009 (révision A).

OpenID Connect étend OAuth 2.x en ajoutant des fonctionnalités standards d'identification.