Comprendre OAuth2

Si OAuth2 reste un concept flou pour vous ou que vous voulez tout simplement être sûr d’avoir compris ses rouages, cet article devrait vous intéresser.

Qu’est-ce que OAuth2 ?

OAuth2

OAuth2 est, vous l’aurez deviné, la version 2 du protocole (appelé aussi framework) OAuth.

Ce protocole permet à des applications tierces d’obtenir un accès limité à un service disponible via HTTP par le biais d’une autorisation préalable du détenteur des ressources. L’accès est demandé par ce qu’on appelle « un client », et qui peut être un site internet ou une application mobile par exemple. Si les ressources n’appartiennent pas au client, alors ce dernier doit obtenir l’autorisation de l’utilisateur final, sinon il peut directement obtenir l’accès en s’authentifiant avec ses propres identifiants.

La version 2 est censée simplifier la version précédente du protocole et à faciliter l’interopérabilité entre les différentes applications.

Les spécifications sont toujours en cours de rédaction et le protocole évolue sans cesse mais cela ne l’empêche pas d’être plébiscité et implémenté par de nombreux sites tels que Google ou Facebook.

Notions de base

Les rôles

OAuth2 définit 4 rôles bien distincts :

  • Le détenteur des données (Resource Owner) : généralement vous-même.
  • Le serveur de ressources (Resource Server) : serveur qui héberge les données dont l’accès est protégé (par exemple Google qui stocke les informations de votre profil).
  • Le client (Client Application) : une application demandant des données au serveur de ressources (cela peut être votre application PHP côté serveur, une application Javascript côté client ou une application mobile par exemple).
  • Le serveur d’autorisation (Authorization Server) : serveur qui délivre des tokens (ou jetons) au client. Ces tokens seront utilisés lors des requêtes du client vers le serveur de ressources. Ce serveur peut être le même que le serveur de ressources (physiquement et applicativement), et c’est souvent le cas.

Les tokens

Les tokens sont des chaines de caractères générées par le serveur d’autorisation et sont émis lorsque le client en fait la demande.

On distingue 2 types de token :

  • Le token d’accès (Access Token) : c’est le plus important car c’est lui qui permet au serveur de ressources d’autoriser la mise à disposition des données d’un utilisateur. Ce token est envoyé par le client (l’application) en tant que paramètre ou en tant que header dans la requête vers le serveur de ressources. Il a une durée de vie limitée qui est définie par le serveur d’autorisation. Il doit rester confidentiel dès que possible (non connu du détenteur de ressources) mais on verra que ce n’est pas toujours possible, notamment lorsque c’est votre navigateur qui envoie les requêtes au serveur de ressources via Javascript.
  • Le token de renouvellement (Refresh Token) : ce token est délivré au même moment que le token d’accès mais n’est en revanche pas envoyé lors de chaque requête du client vers le serveur de ressources. Il sert simplement à être envoyé au serveur d’autorisation lorsque le token d’accès est expiré et que le client souhaite le renouveler. Pour des raisons de sécurité, il n’est pas tout le temps possible de disposer de ce token pour générer un nouveau token d’accès quand celui-il est expiré. Nous verrons plus loin dans quels cas.

Le paramètre scope

Le scope est un paramètre qui sert à limiter les droits du token d’accès. C’est le serveur d’autorisation qui définit la liste des scopes disponibles. Le client doit alors envoyer le ou les scopes qu’ils souhaitent utiliser lors de la demande d’autorisation. Plus le scope est réduit, plus on a de chance que le détenteur des données autorise l’accès.

Plus d’informations (en anglais) : http://tools.ietf.org/html/rfc6749#section-3.3.

HTTPS

OAuth2 impose l’utilisation de HTTPS pour les échanges entre le client et le serveur d’autorisation du fait des données sensibles qui transitent entre les 2 (token d’accès et éventuellement des identifiants et des mots de passe). Dans les faits rien ne vous oblige à le faire si vous mettez en place votre propre serveur d’autorisation mais sachez que vous ouvrez là une grosse faille de sécurité dans votre application.

S’enregistrer en tant que client

Dès lors qu’on veut accéder aux données d’un serveur de ressource utilisant OAuth2, il faut s’enregistrer en tant que client auprès du serveur d’autorisation.

Chaque fournisseur de service est libre d’enregistrer un client par la méthode de son choix. Le protocole définit seulement les paramètres qui doivent être renseignés par le client lors de l’enregistrement et ceux qui doivent être retournés par le serveur d’autorisation.

Voici les paramètres (ils peuvent différer selon les fournisseurs de service) :

Enregistrement en tant que client

  • Application Name: le nom de l’application
  • Redirect URLs: les URLs du client vers lesquelles les redirections (contenant le code d’autorisation et le token d’accès) seront effectuées par le serveur d’autorisation
  • Grant Type(s): les types d’autorisation qui seront utilisés par le client
  • Javascript Origin (optionnel): le nom de domaine qui sera autorisé à effectuer des requêtes XMLHttpRequest vers le serveur de ressource

Réponse du serveur d’autorisation

  • Client Id: chaîne de caractères unique et générée aléatoirement
  • Client Secret: clé secrète qui doit le rester en toute circonstance

Plus d’informations (en anglais) : RFC 6749 — Client Registration.

Les types d’autorisation

Avec OAuth2 il y a 4 types d’autorisation possibles selon l’emplacement et la nature des entités intervenant dans l’obtention du token d’accès.

L’autorisation via un code (Authorization Code Grant)

Quand utiliser ce type d’autorisation ?

Il doit être utilisé dès que possible et tout particulièrement quand le client est un serveur web. Permet d’obtenir un token d’accès de longue durée qui pourra être renouvelé via un token de renouvellement (si le serveur d’autorisation le permet).

Exemple :

  • Détenteur des données (Resource Owner) : vous
  • Serveur de ressources (Resource Server) : un serveur Google
  • Client (Client Application) : un site internet quelconque
  • Serveur d’autorisation (Authorization Server) : un serveur Google

Scénario :

  1. Un site internet quelconque souhaite accéder aux informations de votre profil Google.
  2. Vous êtes redirigé par le client (le site internet) vers le serveur d’autorisation (Google).
  3. Si vous autorisez l’accès, le serveur d’autorisation (Google) envoie un code d’autorisation au site internet.
  4. Ce code est échangé (entre le site internet et Google) par un token d’accès de façon transparente pour vous.
  5. Le site internet peut donc maintenant utiliser ce token d’accès pour accéder aux données de votre profil par le serveur de ressources (Google).

Vous n’accèderez jamais au token d’accès, il sera stocké par le site internet (en session par exemple). Google envoie également d’autres informations en dehors du token d’accès comme la durée de validité du token d’accès et un token de renouvellement par exemple mais celui-ci n’est pas obligatoire.

C’est le scénario idéal et le plus sûr car le token d’accès n’est pas transmis côté client (votre navigateur web dans notre exemple).

Plus d’informations (en anglais) : RFC 6749 — Authorization Code Grant.

Diagramme de séquence :

Authorization Code Grant Flow

L’autorisation implicite (Implicit Grant)

Quand utiliser ce type d’autorisation ?

Il doit être utilisé quand l’application se trouve côté client (typiquement une application Javascript). Il ne permet pas d’obtenir de token de renouvellement.

Exemple :

  • Détenteur des données (Resource Owner) : vous
  • Serveur de ressources (Resource Server) : un serveur Facebook
  • Client (Client Application) : un site internet utilisant AngularJS par exemple
  • Serveur d’autorisation (Authorization Server) : un serveur Facebook

Scénario :

  1. Le client (AngularJS) souhaite accéder aux informations de votre profil Facebook.
  2. Vous êtes redirigé par le navigateur web vers le serveur d’autorisation (Facebook).
  3. Si vous autorisez l’accès, le serveur d’autorisation vous redirige sur le site internet et met à disposition le token d’accès dans le fragment de l’url (non envoyé au serveur web). Exemple de callback : http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN.
  4. Ce token d’accès peut maintenant être utilisé (après avoir été validé) pour faire des appels à l’API Facebook via Javascript (par exemple https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN).

Si vous avez bien suivi vous vous demandez comment on peut faire un appel à l’API Facebook avec Javascript sans se faire jeter à cause du Same Origin Policy ? Eh bien cet appel « cross-domain » est possible car Facebook l’autorise via un header nommé Access-Control-Allow-Origin présent dans la réponse.

Plus d’informations sur le Cross-Origin Resource Sharing (CORS) : https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#The_HTTP_response_headers.

Attention ! Ce type d’autorisation doit être utilisé uniquement si aucun autre type d’autorisation n’est utilisable. C’est en effet le moins sécurisé de tous puisqu’il expose le token d’accès côté client. Il peut donc être intercepté beaucoup plus facilement qu’avec l’autorisation par code où le token d’accès réside côté serveur.

Plus d’informations (en anglais) : RFC 6749 — Implicit Grant.

Diagramme de séquence :

Implicit Grant Flow

L’autorisation via mot de passe (Resource Owner Password Credentials Grant)

Quand utiliser ce type d’autorisation ?

Avec ce type d’autorisation, les identifiants (et donc le mot de passe) sont envoyés au client et ensuite au serveur d’autorisation. Il est donc impératif qu’il y ait une confiance absolue entre ces 2 entités. Il est donc principalement utilisé lorsque le client a été développé par la même autorité que celle fournissant le serveur d’autorisation. On pourrait par exemple imaginer un site web example.com voulant accéder à des ressources protégées de son propre sous-domaine api.example.com. L’utilisateur ne serait donc pas surpris de renseigner son mot de passe sur le site example.com puisque son compte a été créé sur ce même site.

Exemple :

  • Détenteur des données (Resource Owner) : vous ayant un compte sur le site acme.com de la société Acme
  • Serveur de ressources (Resource Server) : la société Acme exposant son API à api.acme.com
  • Client (Client Application) : le site internet acme.com de la société Acme
  • Serveur d’autorisation (Authorization Server) : un serveur de la société Acme

Scénario :

  1. La société Acme fait les choses bien et a pensé à mettre à disposition à des applications tierces une API RESTful exposant tout plein de méthodes pratiques pour récupérer des données diverses et variées de ses utilisateurs.
  2. Cette société se dit qu’il serait pratique d’utiliser sa propre API pour éviter de réinventer la roue et de maintenir du code à plusieurs endroits.
  3. Elle a donc besoin d’un token d’accès pour appeler les méthodes de son API.
  4. Pour cela elle vous demande de renseigner vos identifiants de connexion via un formulaire HTML classique tel que vous le faites habituellement.
  5. L’application côté serveur (le site acme.com) va échanger vos identifiants contre un token d’accès auprès du serveur d’autorisation (si vos identifiants sont valides bien évidemment).
  6. L’application peut donc maintenant utiliser ce token d’accès auprès du serveur de ressources (api.acme.com).

Plus d’informations (en anglais) : RFC 6749 — Resource Owner Password Credentials Grant.

Diagramme de séquence :

Resource Owner Password Credentials Grant Flow

L’autorisation serveur à serveur (Client Credentials Grant)

Quand utiliser ce type d’autorisation ?

Il doit être utilisé lorsque le client est lui-même le détenteur des données. Il n’y a pas d’autorisation à obtenir de la part de l’utilisateur final.

Exemple :

  • Détenteur des données (Resource Owner) : un site internet quelconque
  • Serveur de ressources (Resource Server) : Google Cloud Storage
  • Client (Client Application) : le détenteur des données
  • Serveur d’autorisation (Authorization Server) : un serveur Google

Scénario :

  1. Un site internet quelconque stocke des fichiers de toute sorte sur Google Cloud Storage.
  2. Le site internet doit passer par l’API Google pour récupérer ou modifier des fichiers et doit donc s’authentifier auprès du serveur d’autorisation.
  3. Une fois authentifié, le site internet obtient un token d’accès qu’il peut désormais utiliser auprès du serveur de ressources (Google Cloud Storage).

Ici, l’utilisateur final n’intervient pas et n’a dons pas à donner son accord pour accéder au serveur de ressources.

Plus d’informations (en anglais) : RFC 6749 — Client Credentials Grant.

Diagramme de séquence :

Client Credentials Grant Flow

Utilisation du token d’accès

Le token d’accès peut être envoyé de plusieurs façons au serveur de ressources.

Paramètre de la requête (GET ou POST)

Exemple avec GET : https://api.example.com/profile?access_token=MzJmNDc3M2VjMmQzN

Cela n’est pas idéal car le token peut se retrouver dans les logs d’accès du serveur web.

Header Authorization

GET /profile HTTP/1.1
Host: api.example.com
Authorization: Bearer MzJmNDc3M2VjMmQzN

C’est pratique et élégant mais tous les serveurs de ressources ne le permettent pas.

Sécurité

OAuth2 est parfois critiqué pour sa perméabilité mais cela vient souvent d’implémentations trop laxistes du protocole. Il y a des grosses erreurs à éviter lors de son utilisation dont voici quelques exemples.

Faille dans l’autorisation par code

Il existe une faille dans ce type d’autorisation qui permet à une personne malveillante de voler le compte d’un utilisateur dans certaines conditions. Cette faille revient souvent et a affecté beaucoup de sites connus (Pinterest, SoundCloud, Digg, …) qui n’ont pas correctement implémenté le type d’autorisation par code.

Exemple :

  • Votre victime possède un compte valide sur un site internet A.
  • Le site internet A permet le login et la création de compte via Facebook et s’est donc préalablement enregistré en tant que client OAuth2 auprès de Facebook.
  • Vous cliquez sur le bouton Facebook Connect du site internet A mais bloquez la redirection, via le module NoRedirect de Firefox ou en utilisant Burp par exemple (le callback ressemble à cela : http://site-internet-a.com/facebook/login?code=OGI2NmY2NjYxN2Y4YzE3).
  • Vous récupérez l’url (contenant le code d’autorisation) vers laquelle vous alliez être redirigé (visible dans Firebug).
  • Il ne vous reste plus qu’à forcer votre victime à visiter cette url via une iframe cachée sur un site, une image dans un mail ou autre du moment que c’est transparent pour la victime.
  • Si la victime est connectée au site internet A eh bien bingo ! Vous venez d’autoriser l’accès au compte de la victime via votre compte Facebook. Il ne vous reste plus qu’à cliquer sur le bouton Facebook Connect et vous serez connecté avec le compte de la victime.

Solution :

Il existe un moyen d’empêcher cela grâce au paramètre « state » préconisé dans OAuth2. Ce paramètre est seulement recommandé et non obligatoire dans les spécifications. Si le client envoie ce paramètre lors de la demande de code d’autorisation, il sera retourné tel quel par le serveur d’autorisation dans la réponse et pourra donc être comparé par le client avant la demande d’échange du code par un token d’accès. Ce paramètre correspond généralement à un hash unique d’un nombre aléatoire qui sera stocké dans la session de l’utilisateur. Par exemple en PHP : sha1(uniqid(mt_rand(), true)).

Dans notre exemple, si le site internet A utilisait le paramètre « state » il se serait rendu compte lors du callback que le hash ne correspondait pas à celui enregistré dans la session de la victime juste avant la demande de code d’autorisation et aurait donc empêché le vol du compte utilisateur.

Plus d’informations (en anglais) : RFC 6749 — Cross-Site Request Forgery.

Faille dans l’autorisation implicite

Ce type d’autorisation est le moins sécurisé de tous étant donné qu’il expose le token d’accès côté client (Javascript la plupart du temps). Il existe une faille très répandue qui provient du fait que le client ne sait pas si le token d’accès a été généré pour lui ou non (Confused Deputy Problem) et qui permet de subtiliser le compte d’une victime.

Exemple :

  • Une personne mal intentionnée a pour objectif de subtiliser le compte d’une victime sur un site internet A. Ce site permet la connexion via un compte Facebook et utilise l’autorisation implicite.
  • Le pirate crée un site internet B autorisant la connexion via Facebook également.
  • La victime se connecte sur le site internet B avec son compte Facebook et a donc autorisé implicitement la génération d’un token d’accès pour cela.
  • Le pirate récupère ce token d’accès via son site internet B et l’utilise sur le site internet A en modifiant le token d’accès dans le fragment de l’url. Si le site internet A n’est pas protégé contre cette attaque, le compte de la victime est désormais compromis et le pirate a libre accès à celui-ci.

Solution :

Pour éviter cela, le serveur d’autorisation doit mettre à disposition dans son API un moyen de récupérer les informations d’un token d’accès. Ainsi, le site internet A aurait pu récupérer les informations du token d’accès que le pirate avait substitué dans l’url puis aurait comparé le client_id retourné par l’API avec son propre client_id. Comme le token d’accès subtilisé avait été généré pour le site internet B, le client_id aurait été différent du sien et la connexion aurait pu être refusée.

Google l’explique dans la documentation de son API (en anglais) : https://developers.google.com/accounts/docs/OAuth2Login#validatingtoken.

Plus d’informations également dans la RFC (en anglais) : http://tools.ietf.org/html/rfc6819#section-4.4.2.6.

Clickjacking

Cette technique permet de tromper l’internaute en cachant la page d’autorisation d’accès à ses données dans une iframe transparente et en l’incitant à cliquer sur un lien qui se situe visuellement sur le bouton « Autoriser » de la page d’autorisation.

Exemple en image :

OAuth2 Clickjacking

Solution :

Pour éviter cela, il faut que le serveur d’autorisation renvoie un header nommé X-Frame-Options sur sa page d’autorisation avec comme valeur DENY ou SAMEORIGIN. Cela empêche la page d’autorisation d’être affichée dans une iframe (DENY) ou oblige la concordance du nom de domaine entre l’url de la page appelante et l’url de l’iframe (SAMEORIGIN).

Ce header n’est pas standard mais est supporté par IE8+, Firefox3.6.9+, Opera10.5+, Safari4+, Chrome 4.1.249.1042+.

Plus d’informations : https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options.

Voici la RFC listant les failles potentielles du protocole et les mesures à prendre pour en limiter l’exploitation (en anglais) : http://tools.ietf.org/html/rfc6819.

Conclusion

Que ça plaise ou non (troll d’un ancien contributeur du protocole), OAuth2 semble s’imposer comme solution standard pour la délégation d’autorisation entre différentes applications pour quelques années encore.

En tout cas, j’espère vous avoir aidé à comprendre ses rouages. Nous verrons dans un prochain article comment créer son propre serveur d’autorisation OAuth2 avec Symfony2.

++

52 réponses à “Comprendre OAuth2”

  1. Eric dit :

    Un grand merci pour cet article. Ca fait vraiment plaisir de trouver du contenu d’une telle qualité, claire, bien expliqué, et en plus en Français. Bravo!

    J’attends avec impatience la suite avec OAuth2 et Symfony2, car je pense que beaucoup galère sur ce sujet… moi le premier.

  2. bebshow dit :

    Salut ! J’aime beaucoup cet article, clair, précis, avec citations, liens etc.
    parfait merci and
    Deeply the next article on symfony2 !

  3. adrien dit :

    Merci beaucoup !
    Je cherchais à réaliser des web services REST utilisant OAuth avec Symfony 2 sans vraiment avoir de connaissances sur le sujet et cet article m’a bien éclairci les idées !
    Est-il possible de savoir où en est le tuto « comment créer son propre serveur d’autorisation OAuth2 avec Symfony2″ ? Comme mon prédécesseur, je galère un peu sur le sujet et si un tuto de qualité égale à cet article était mis en ligne il simplifierait le travail de beaucoup de personnes !

    • Johann Reinke dit :

      Merci à tous,
      J’ai commencé l’article sur l’API Symfony2 avec serveur OAuth2. Pas encore eu le temps de terminer mais je n’oublie pas ;)

  4. JC dit :

    Bravo !
    C’est un article clair et très facile a comprendre, pourtant le sujet ne l’était pas.
    Super sympa d’avoir pris du temps pour expliquer tout cela.

  5. Uneak dit :

    Sujet difficile, mais malgré tout SUPER clair !
    Félicitation !!

  6. David dit :

    Cool post, thanks!

  7. Flo63 dit :

    Merci ! tout est très clair !

  8. Laurent dit :

    Bonjour

    Bravo pour cet article. Par contre, qualifier de « troll » le « coming-out » du leader des spécifications me semble inapproprié. Il ne faut pas minorer ce fait, qui montre qu’il y a des problèmes.

  9. Narayan dit :

    Many thanks for this great article (and the flows).

  10. Max dit :

    Salut,

    Quel est l’intérêt d’échanger un autorization code par un token, je veux dire pourquoi ne pas retourner directement le token puisque c’est le même serveur et le même client qui communiquent ?

    Merci !

  11. Jean-Marc dit :

    Enfin un article clair sur le sujet. J’ai particulièrement apprécié les diagrammes de séquence. Continue ce super boulot !

  12. Sébastien dit :

    Très bon article, merci.

  13. Zouhair dit :

    Bon article, super

  14. jbn dit :

    Merci pour l’article.

    Je ne trouve pas l’article suivant sur comment réaliser son propre serveur oauth ?
    J’ai trouver le bundle Symfony2 FOSAuthServerBundle mais une explication claire m’aiderai à l’intégrer dans notre environnement.

    Cordialement et bonne continuation !

  15. Xavier dit :

    Excellent article.
    Merci :)

  16. Séyram dit :

    C’est Article est très bien écrit, le sujet est difficile mais on en ressort bien éclairé après la lecture. Merci beaucoup
    Bonne continuation.

  17. BlackDev'S dit :

    Je te remercie pour cette article sur l’OAuth 2.0 j’apprend actuellement à utiliser les API et grâce à toi j’ai beaucoup avancer !

  18. Kashouf dit :

    Bonjour, merci pour ce superbe article. Tout est bien expliqué et j’en apprends enfin un peu plus sur ce protocole. Les diagrammes de séquences sont bien utiles aussi. Tout ce qu’il manque à la limite, c’est un peu de code pour illustrer son utilisation…
    Je suis confronté à un problème de modification et de copie de documents dans le drive, si vous avez des exemples du Client Credentials Grant je suis preneur ^^.
    Merci

  19. hordanh ongouo dit :

    merci énormément pour cet article car ça m’a beaucoup aidé.

  20. Pierre de LESPINAY dit :

    Les graphiques les plus parlants que j’ai pu voir au sujet d’OAuth2 jusqu’à maintenant.
    Merci.

  21. Super article! Très bien expliqué et clair! Merci beaucoup

  22. Sébastien B dit :

    Bonjour,
    En effet un grand merci, très bon travail de vulgarisation.
    En revanche j’avoue que je n’arrive pas à comprendre l’intérêt de ce protocole en terme de sécurité, même suite à la lecture de cet article
    En particulier la multiplicité des « méthodes » possibles.

    J’ai travaillé avec OAuth v1 et j’ai cru comprendre que l’intérêt résidait dans la « sécurité » qu’apportait le navigateur utilisé comme étant « neutre » pour l’utilisateur et rendant fiable le mécanisme.
    Si j’ai bien compris, mis à part facilité, OAuth2 permet notamment d’être exploité sur application mobile native ce qui n’est pas le cas d’Oauth v1, mais dans ce cas, il semble que niveau sécurité ce ne soit « que » du https, rien de plus, l’autorisation de partage pourra être bypassée par l’appli qui controle totalement l’environnement

    Qu’est ce que j’ai manqué?

  23. VaN dit :

    Toujours pas de nouvelles de l’article sur l’intégration de OAuth dans Symfony2 ? Je ne me fais pas trop d’illusions, au bout de 2 ans :p

  24. Bravo, c’est très explicite et très pédagogique, vivement la suite “OAuth2 avec Symfony2″, bon courage et bonne continuation ;-)

  25. Nam's dit :

    Bonjour et merci pour tes explications,

    j’ai cependant quelques questions.
    Je récupere en PHP via Curl les info relatives a mon compte google analytics et je passe donc mes parametres dans l’URL.

    $url =’https://www.googleapis.com/analytics/v3/data/realtime?ids=ga%3A104738580&metrics=rt%3AactiveUsers&access_token=ya29.-AF73Jm4hjBtqlVrK1o8RNhaJot1S4rY98GU6md0PHK9AW-Jve9jreSJzSNBvbXHZ7xr';

    Le probleme est que ce token n’a une durée de vie que d’une heure.
    Je me susi donc généré un refresh-token mais je ne sais pas comment l’utiliser dans mon code.
    Ou le placer dans l’url ?
    Quelle manipe faire avec ?

    Si quelqu’un peut m’aider ca serait top.

    Merci d’avance.

    Nam’s.

  26. GM_CED dit :

    Merci pour cette explication!

  27. nanou dit :

    ça mériterais de figurer sur un wiki, excellent travail, merci pour le partage !

  28. techtech dit :

    Super article;
    Le diagramme des séquences est super clair et est le parfait complément !

  29. L Truong dit :

    Merci pour les explications qui font bien le lien avec les exemples d’implémentation en Java Servlet chez IBM pour les rois types d’autorisations (sauf implicit) :
    http://www.ibm.com/developerworks/library/se-oauthjavapt3/
    Si quelqu’un trouve des meilleurs exemples, merci de bien vouloir partager.

  30. aload dit :

    Bonjour,
    Super tuto merci, mais un truc m’échappe, il faut s’enregistrer en tant que client auprès du serveur d’autorisation. OK
    Mais le client == utilisateur ??? ou client == application (JS, android, php)
    car je ne sais pas si je doit générer une seul paire de client_id + secret (ayant qu’une appli JS ) ou alors, chaque utilisateur se voit obtenir une paire de clef.

    ha oui « ressource owner » c’est bien un utilisateur ?

  31. Pavan Vadlmudi dit :

    Very Useful POST

  32. FL dit :

    Merci pour les explications.

    Mais je ne comprend pas une partie:
    Lorsque le « Authorization Server » délivre un token, comment le « Ressource Server » sait que le token est valide ? Quelles méthode sont utilisées pour que ces deux la soient d’accords sur la validité (et l’expiration) d’un token ?

    Pour les tokens d’accès (exemple : « Authorization: Bearer MzJmNDc3M2VjMmQzN »), en quoi ça change d’une Basic Auth ?

  33. TOMASIAN dit :

    Excellent article. Clair et précis. Merci pour ce superbe travail.

    Cordialement.

  34. fred dit :

    Merci pour votre super article, très didactique.
    Par contre, je n’ai pas bien compris l’exemple de faille que vous décrivez.

  35. Praveen dit :

    Great work . Nicely explain the terminology with examples.
    Thanks a lot Johann Reinke.

  36. Gonzalo dit :

    Great article, When it should be used? made the difference from other articles in the internet.
    Do you have anything written about OAuth1?

  37. Lala dit :

    Il se peut que je ne saisit pas l’idee de l’auteur mais il semble que la phrase ci dessous

    Ce code est échangé (entre le site internet et Google) par un token d’accès de façon transparente pour vous.

    devrait se lire ainsi

    Ce code est échangé (entre le site internet et Google) par un token d’accès de façon opaque pour vous.

    En effer on ne voit pas ce qui s’echange entre ces 2 sites alors c’est plutot opaque que transparente…

    Merci de me corriger si besoin svp…

  38. Brian Chandler dit :

    Thank you very much for this excellent explanation. The diagrams and when each flow tends to be used really cut through the fog.

  39. Kavita dit :

    Good explanation

  40. Michael dit :

    Hi Johann,

    thanks for this useful POST. I guess there is a little mistake in Chapter Roles:

    Authorization Server: server issuing access token to the client. This token will be used for the client to request the resource server. This server can be the same as the authorization resource server (same physical server and same application), and it is often the case.

    Regards,
    Michael

  41. Syed dit :

    One of the best post so far on OAuth2 explanantion. Thanks for such a informative and clear post about OAuth.

  42. Gimhani dit :

    A very useful article
    Thank you

  43. Bhuvan Doshi dit :

    Thanks for useful post. salute for your knowledge :)

  44. Mantas dit :

    With regards to definition of the Roles:


    Authorization Server: server issuing access token to the client. This token will be used for the client to request the resource server. This server can be the same as the authorization server (same physical server and same application), and it is often the case.

    Am I missing something in the above or does it say « … Authorization server … can be the same as the authorization server …. » ?

  45. Ashok dit :

    Excellent explanation.Many of my confusions regarding grant types got cleared. Thank you man

  46. Ritwik dit :

    Finally I could found a post – that clears all the flows. Thanks a lot.

  47. ivan dit :

    magnifique cet article

  48. Milan dit :

    From my perspective this is the most useful article regarding oAuth2 processes for the beginners.
    Clearly written, but still with great technical details and diagrams. Reminds me on good old days of internet when people were putting their efforts in the articles.
    Thanks and cheers!

  49. thomas dit :

    lire la RFC 6749 (anglais) qui est beaucoup plus complète, si on prend en considération que la majeur partie des paragraphes auraient pu être copier de la rfc dans google traduction. Il n’y a que les schémas qui ont le mérite d’avoir été refait.

  50. Maris dit :

    Great article.

Laisser un commentaire

* Champs requis

Categories