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 2.0 définit 4 rôles  en déclinant le "serveur" de OAuth 1.0 en 2 rôles distincts:

1. le client (front end ou consumer)
2. serveur de ressource (resource server), recevant les demandes de ressources avec jetons d'accès (access tokens) et les fournissant si elles sont valides ;
3. 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.
4. 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 :

• applications web
• applications natives

Conception

l'architecture client /serveur :

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 :

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

Publié 2012.

Etendu par OpenID Connect en ajoutant des fonctionnalités standards d'identification.