OAuth 1.0

OAuth 1.0

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 3 rôles :

  1. le client (front end ou consumer)
  2. le serveur (back end) hébergeant des ressources
  3. 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é.

Conception

OAuth 1.x ajoute un 3ᵉ rôle à l'architecture client /serveur :

  • 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

Implémentation

Debugger

Notes

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