API OAuth d'authentification

Posté par (page perso) . Édité par Benoît Sibaud et Xavier Claude. Modéré par Benoît Sibaud. Licence CC by-sa
33
11
déc.
2011
LinuxFr.org

LinuxFr.org dispose maintenant d'une API Rest au format JSON qui s'appuie sur OAuth2 pour l'authentification. Cette API est encore très limitée (elle ne possède qu'une seule méthode), mais elle s'enrichira en fonction de vos demandes. N'hésitez pas à créer des entrées dans le suivi pour indiquer quelles seraient les méthodes dont vous auriez besoin.

Pour le moment, elle permet à des sites externes d'authentifier un utilisateur à partir de son compte sur LinuxFr.org comme le proposent des réseaux sociaux bien connus. Cela pourrait par exemple servir à des tribunes hébergées sur d'autres sites pour permettre à leurs utilisateurs de se connecter en un clic.

Cela fonctionne avec le standard OAuth2 mais, si vous êtes un développeur Ruby, je vous recommande d'utiliser la gem Omniauth qui permet de mettre en place l'authentification via LinuxFr.org de manière très simple.

  • # NoNo<

    Posté par . Évalué à 9.

    Tu roxes :D Best feature out there \o/

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

  • # la question qui fâche

    Posté par . Évalué à 3.

    et pourquoi ne pas utiliser OpenID ?

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: la question qui fâche

      Posté par (page perso) . Évalué à 10.

      Je ne voudrais pas m'avancer, mais je pense que Bruno s'est basé sur une analyse de marché établie sur des données fiables, vérifiées et brillamment interprétées.

      Des données fiables, vérifiées et brillamment interprétées

    • [^] # Re: la question qui fâche

      Posté par . Évalué à 9. Dernière modification le 11/12/11 à 21:31.

      OAuth et OpenID ne servent pas à la même chose.

      OpenID c'est pour t'identifier sur des sites externes en utilisant ton compte LinuxFR. L'avantage de OpenID c'est que ça marche sur tous les sites qui supportent OpenID, même si le site en question n'a jamais entendu parler de LinuxFR.

      OAuth2 c'est plus pour consommer un service fournis par LinuxFR (l'API, dans ce cas): Un site spécialement conçu pour utiliser l'API de LinuxFR peut utiliser l'API en tant que toi, si tu lui en donne l'autorisation.

      Les sites peuvent aussi s'en servir comme moyen d'identification, mais ce n'est pas l'usage premier de OAuth. Au contraire d'OpenID, il faut que le site gère l'identification via LinuxFR explicitement (comme ça se fait avec Twitter et Facebook, qui utilisent OAuth eux aussi).

      Donc OAuth c'est bien quand on fournis une API, et OpenID c'est bien quand on veut fournir une identité.

      • [^] # Re: la question qui fâche

        Posté par (page perso) . Évalué à 3.

        Donc l'idée sous-jacente serait de pouvoir troller depuis un site/logiciel tiers comme l'on tweet ? ...

        • [^] # Re: la question quifâche

          Posté par . Évalué à 3.

          Par hasard, Monboob ?

        • [^] # Re: la question qui fâche

          Posté par . Évalué à 4.

          Oui, si à terme l'API authorize à poster des commentaires etc, alors on pourra développer des clients natifs pour linuxfr.

          • [^] # Re: la question qui fâche

            Posté par (page perso) . Évalué à 3.

            C'est effectivement l'idée. Maintenant développer l'API pour faire toutes les actions possibles depuis l'interface web risque de prendre beaucoup de temps, donc si certains ont un avis sur ce qui devrait être fait en premier, je suis preneur.

            • [^] # Re: la question qui fâche

              Posté par . Évalué à 1.

              La tribune (ok, je sors).
              Sérieusement, les fonctions de création de contenu me paraissent les plus importantes, suivies de l'accès au suivi.

              "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

              • [^] # Re: la question qui fâche

                Posté par (page perso) . Évalué à 2.

                La tribune (ok, je sors).

                Ben c'est pas idiot de commencer par le post dans la tribune : ça permet de se faire les dents sur un truc simple. De plus, les clients existent déjà, les nombreux développeurs de coincoins seront tout heureux d'implémenter cette nouvelle feature !

            • [^] # Re: la question qui fâche

              Posté par . Évalué à 2.

              Ok, alors c'est parti je développe le plugin MS Office 2011. Ça devrait aider certains.

    • [^] # Re: la question qui fâche

      Posté par (page perso) . Évalué à 5.

      et pourquoi ne pas utiliser OpenID ?

      Je compte développer d'autres méthodes dans cette API (par exemple, pouvoir poster un commentaire) et cette partie à base d'OAuth2 va servir de base pour cela. OpenID ne fait que de l'authentification (et encore assez mal) et ne s'occupe pas de la partie autorisations.

    • [^] # Re: la question qui fâche

      Posté par (page perso) . Évalué à 2.

      openid comme provider ( auquel cas, je dirait "+1" ) , ou permettre de s'authentifier à partir d'un provider openid externe ( auquel cas je dirais "bof" ).

  • # OAuth 1.0 vs. 2.0 ?

    Posté par (page perso) . Évalué à 6.

    Une simple question : pourquoi choisir OAuth 2.0 qui n'est pas actuellement un standard (toujours en cours d'écriture), qui n'est pas stabilisé, qui oblige client et serveur à implémenter et utiliser TLS, qui est très peu utilisé, et enfin qui n'est pas compatible avec OAuth 1.0 ; plutôt que OAuth 1.0 qui est un standard stable et reconnu (RFC), qui ne nécessite pas de gérer le TLS si on le souhaite, et qui est utilisé par un peu tout le monde ?

    Ou pourquoi ne pas gérer les deux tout simplement ?

    (Perso j'ai pas compris pourquoi OAuth 2.0 a gardé le nom OAuth alors que ça n'est pas rétro-compatible et que ça n'a plus grand chose à voir...)

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: OAuth 1.0 vs. 2.0 ?

      Posté par . Évalué à 10. Dernière modification le 11/12/11 à 23:24.

      OAuth2 est beaucoup plus simple.

      OAuth utilise une connexion HTTP en clair, et donc doit implémenter des techniques pour vérifier l'authenticité des messages, chiffrage, anti-replay, nonce, etc. Le résultat est que consommer une API OAuth est assez complexe et requière une bibliothèque.

      OAuth2 laisse ce travail à TLS, et du coup le protocole est hyper simple. Côté client une bibliothèque HTTP est amplement suffisante pour consommer une API OAuth2.

      Forcer l'utilisation de TLS n'est pas un problème pour le client, à mon avis, tant que le serveur a un certificat de confiance.

      OAuth2 est utilisé par Facebook entre autres, ce qui fait que la catégorie de développeurs qui a déjà touché à OAuth1 a certainement déjà touché à OAuth2 aussi.

      • [^] # Re: OAuth 1.0 vs. 2.0 ?

        Posté par (page perso) . Évalué à 4.

        OAuth2 est beaucoup plus simple.

        Voilà, ça résume bien ;-)

      • [^] # Re: OAuth 1.0 vs. 2.0 ?

        Posté par (page perso) . Évalué à 3.

        Forcer l'utilisation de TLS n'est pas un problème pour le client, à mon avis, tant que le serveur a un certificat de confiance.

        Ça existe ça, un certificat X.509 de confiance ? ^^

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: OAuth 1.0 vs. 2.0 ?

      Posté par (page perso) . Évalué à 10.

      pourquoi choisir OAuth 2.0

      Parce que c'est beaucoup plus simple que OAuth 1.0.

      qui n'est pas actuellement un standard (toujours en cours d'écriture)

      HTML5 est aussi dans cette zone mouvante. Est-ce qu'il faudrait ne pas l'utiliser avant 2022 ?

      qui n'est pas stabilisé

      Si, maintenant, c'est relativement bien stabilisé (même si par le passé, il y a eu de gros changements).

      qui oblige client et serveur à implémenter et utiliser TLS

      Oui, mais je préfère ça à devoir gérer ça avec des trucs plus bas niveau comme dans OAuth 1.0.

      qui est très peu utilisé

      Cough. C'est "juste" utilisé par Facebook, Google, Github, Instagram, Foursquare, 37signals... Bref, en dehors de twitter, ça fait quand même une très grosse partie des API à fort trafic dans le monde.

      qui n'est pas compatible avec OAuth 1.0

      Certes, mais vu que le numéro majeur de version a changé, ça semble logique.

      plutôt que OAuth 1.0 qui est un standard stable et reconnu (RFC), qui ne nécessite pas de gérer le TLS si on le souhaite, et qui est utilisé par un peu tout le monde ?

      OAuth est surtout connu pour être très compliqué à implémenter. Et, à part Twitter, je ne crois pas avoir rencontré récemment d'API qui utilise OAuth 1.0.

      • [^] # Re: OAuth 1.0 vs. 2.0 ?

        Posté par (page perso) . Évalué à 2.

        HTML5 est aussi dans cette zone mouvante. Est-ce qu'il faudrait ne pas l'utiliser avant 2022 ?

        Je suggérerais bien d'oublier cette erreur de la nature et de passer directement à HTML 6 qui (idéalement) séparera HTML de tout le reste du bouzin, cette spéc étant absolument illisible. Mais c'est un autre troll ^^

        Oui, mais je préfère ça à devoir gérer ça avec des trucs plus bas niveau comme dans OAuth 1.0.

        Normalement c'est la lib utilisée qui fait le boulot note, d'un point de vue dév ça change pas grand chose j'ai l'impression. Par contre oui d'un point de vue développeur de lib OAuth, je suis très heureux de ne plus avoir à mettre le nez dans ce bordel de signatures machin, même si maintenant que c'est fait ça bougera plus.

        C'est "juste" utilisé par Facebook, Google, Github, Instagram, Foursquare, 37signals... Bref, en dehors de twitter, ça fait quand même une très grosse partie des API à fort trafic dans le monde.

        A part facebook, la plupart (google & co.) qui l'implémentent préviennent que c'est expérimental et que ça peut changer / disparaître à tout moment, ce qui n'est guère rassurant. Mais c'est pas parce que c'est quelques "gros" machins que ça veut dire que c'est répandu... Ça me semble encore relativement rare perso.

        Sur le fond je parlais de l'implémentation des libs (provider/consumer/whatever) qui me semble pour le moment relativement faiblarde comparé à ce qui existe pour OAuth 1.0.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Et le spam?

    Posté par (page perso) . Évalué à 4.

    Sur cette page, il est expliqué que l'API permet de récupérer l'adresse mail d'un utilisateur authentifié. Est-ce vraiment souhaitable?

    http://devnewton.bci.im

    • [^] # Re: Et le spam?

      Posté par (page perso) . Évalué à 4.

      L'utilisateur doit donner son accord pour qu'une application puisse accéder à ses informations.

      • [^] # Re: Et le spam?

        Posté par (page perso) . Évalué à 6.

        C'est dommage que ce soit binaire: je donne accès à toutes mes infos ou à aucune.

        http://devnewton.bci.im

  • # Drupal 6

    Posté par (page perso) . Évalué à 2.

    Cela pourrait par exemple servir à des tribunes hébergées sur d'autres sites pour permettre à leurs utilisateurs de se connecter en un clic.
    
    

    C'est justement mon cas : ) (http://euromussels.eu/ ) Cette tribune tourne sur Drupal. Comme le module tribune n'est compatible qu'avec la version 6 de Drupal, j'utilise toujours cette version. J'ai l'impression que pour faire fonctionner correctement les modules OAuth2, il faut utiliser Drupal 7 maintenant. Vous me conseillez d'installer quels modules Drupal (en espérant qu'il y a experts de Drupal qui traînent ici)?

  • # Clair comme de l'eau de roche

    Posté par . Évalué à 6.

    LinuxFr.org dispose maintenant d'une API Rest au format JSON qui s'appuie sur OAuth2 pour l'authentification

    Ouais, c'est pas faux.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # BrowserID

    Posté par . Évalué à -5.

    Utilisr ce que tout le monde utilise c'est bien beau, mais personellement je préfére utiliser ce qui est plus proche de mes valeurs ca qui protége ma vie privée, comme par exemple, BrowserID.

    Le concept est interessant d'ailleurs, et puis pas très dur a implémenter.

    https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site

    • [^] # Re: BrowserID

      Posté par . Évalué à 2.

      Le concept est peut-être intéressant (ou peut-être pas, j'ai pas regardé en détail), mais ça n'a rien à voir avec ce qui est discuté ici.

    • [^] # Re: BrowserID

      Posté par . Évalué à 3.

      Depuis le temps que j'en entends parler sans prendre le temps de m'y intéresser, tu pourrais m'expliquer un truc? Chaque fois que je regarde, j'ai l'impression que c'est tout sauf décentralisé (et complètement dépendant de browserid.org), je me trompe?

    • [^] # Re: BrowserID

      Posté par . Évalué à 3.

      BrowserID c'est comme OpenID ça permet juste de fournir une authentification alors qu'avec OAuth on peut gérer des autorisation. De plus BrowserID est lié au navigateur il me semble alors que là l'un des intérêts est de pouvoir créer des clients natif (le renouveau de wmcoincoin ?).

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.