>> Qu'est ce qui empeche le client de ressortir son token ?
>
>
> j'aurais du préciser, "a chaque fois que le token expire ou est perdu"
>
> en fait le client secret permet de verifier que l'utilisateur a bien
> autorisé le client. (l'autorisation c'est la demande a l'utilisateur de
> valider les scopes)
> si on ne peut pas faire confiance au client, il faut demander une
> autorisation a chaque fois qu'on demande un token.
> si le token a une durée de vie infinie, et qu'il est sauvegardé par le
> client, alors il me semble que l'autorisation ne sera demandé qu'une seule
> fois
>
> Le 31 janvier 2012 16:25, flagos <
flagospub@xxxxxxxxx> a écrit :
>
>> Oui non je reviens sur ma derniere considération: effectivement
>> quoiqu'il arrive, ca fait que le client_secret peut etre du coup
>> usurpé.
>>
>> Donc la seule piste qui reste est la génération a la volée, charge a
>> nous d'automatiser le bousin.
>>
>> Le 31 janvier 2012 16:16, flagos <
flagospub@xxxxxxxxx> a écrit :
>> > Bon ben voila, ca repond super bien a la question. Le cas de
>> > differents instances d'un serveur d'authentification a été traitée
>> > dans la norme, et c'est la premiere solution (dans mon mail) qui est
>> > retenue.
>> >
>> > (Fais chier avec ces machins tout standard, on peut meme plus troller !)
>> >
>> > Donc en gros, on dédie une api rest a la recupération de tokens,
>> > charge a chaque client de se démerder pour stocker ses client_id et
>> > client_secret dans un endroit sur.
>> >
>> > en temps normal on a un truc du genre
>> > 1ere utilisation :
>> > user : login
>> > user : autorization du client
>> > autorization ok, je balance un token
>> >
>> > utilisation ultérieure :
>> > user : login (je suis pas sur)
>> > le client_secret me dit que le client est deja autorisé pour cet
>> > utilisateur, je balance un token.
>> >
>> > comme le client_secret ne peut etre verifié, l'autorisation devra etre
>> > demandé a chaque fois, c'est pas terrible comme truc.
>> >
>> > Qu'est ce qui empeche le client de ressortir son token ?
>> >
>> > bon je ne commenterais pas ce passage.
>> >
>> > lol effectivement, c'est pas une bonne idée.
>> >
>> > En fait, il faudrait que, de la meme maniere qu'on peut
>> > l'authentification de l'utilisateur, opuvoir déporter
>> > l'authentification du client avec ses client_id et client_secret vers
>> > un serveur qu'on hebergerait nous. C'est vraiment ca qui manque dans
>> > oauth2 et qui nous oblige a faire des machins générés a la volée.
>> >
>> > Le 31 janvier 2012 15:13, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>> >> justement j'allais repondre un peu la dessus.
>> >>
>> >> je vais citer quelques bout du draft relatif a la securité dont j'ai
>> >> passé
>> >> les liens il y a quelques temps.
>> >> Ce passage concerne le problème du déploiement d'applications
>> >>
>> >> :
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-5.2.3.4
>> >>
>> >> For native applications, things are more complicated because every
>> >>
>> >> installation of the app on any device is another deployment.
>> >> Deployment specific secrets will require
>> >>
>> >> 1. Either to obtain a client_id and client_secret during download
>> >> process from the app market, or
>> >>
>> >> 2. During installation on the device.
>> >>
>> >> Either approach will require an automated mechanism for issuing
>> >> client ids and secrets, which is currently not defined by OAuth.
>> >>
>> >> The first approach would allow to achieve a level where the client
>> >> is
>> >> authenticated and identified, whereas the second option only allows
>> >> to authenticate the client but not to validate properties of the
>> >> client. But this would at least help to prevent several replay
>> >> attacks. Moreover, deployment-specific client_id and secret allow
>> >> to
>> >> selectively revoke all refresh tokens of a specific deployment at
>> >> once.
>> >>
>> >>
>> >> donc pour resumer, dans de tel cas il est conseillé d'avoir une
>> >> procédure
>> >> (non spécifié dans oauth) permettant au client de recuperer un
>> >> client-id
>> >> plus ou moins automatiquement lors du déploiment. Il me semble que dans
>> >> ce
>> >> cas, ca reste plus ou moins valide uniquement si la source du
>> >> déploiment est
>> >> fiable (genre le market ?) mais je me trompe peu etre.
>> >>
>> >> un autre passage interessant concerne les clients "qui ne peuvent
>> >> garder un
>> >> secret"
>> >>
>> >> .
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-5.2.3.2
>> >>
>> >> The authorization may issue a client id, but only accept
>> >> authorization request, which are approved by the end-user. This
>> >> measure precludes automatic authorization processes.
>> >>
>> >>
>> >> de ce que je comprend, on ne peut faire confiance un client_secret pour
>> >> valider que c'est bien le bon client, et donc on fait appel a
>> >> l'utilisateur
>> >> pour valider le truc. il est préciser que ca casse le procéssus
>> >> automatique
>> >> d'autorisation, j'ai du mal a saisir mais je le vois comme ca, a chaque
>> >> requette necessitant l'envois d'un token, l'utilisateur doit valider la
>> >> demande d'autorisation.
>> >> en temps normal on a un truc du genre
>> >> 1ere utilisation :
>> >> user : login
>> >> user : autorization du client
>> >> autorization ok, je balance un token
>> >>
>> >> utilisation ultérieure :
>> >> user : login (je suis pas sur)
>> >> le client_secret me dit que le client est deja autorisé pour cet
>> >> utilisateur, je balance un token.
>> >>
>> >> comme le client_secret ne peut etre verifié, l'autorisation devra etre
>> >> demandé a chaque fois, c'est pas terrible comme truc.
>> >>
>> >> enfin je colle un dernier passage qui me semble interessant, plus en
>> >> relation avec la deuxiemme proposition que tu fait (il me semble) :
>> >>
>> >> Authorization servers should not issue secrets to clients, if these
>> >> cannot sufficiently protect it. This prevents the server from
>> >> overestimating the value of a sucessful authentication of the
>> >> client.
>> >>
>> >> For example, it is of limited benefit to create a single client id
>> >> and secret which is shared by all installations of a native app.
>> >> First of all, this secret must be somehow transmitted from the
>> >> developer via the respective distribution channel, e.g. an app
>> >> market, to all installations of the app on end-user devices. So the
>> >> secret is typically burned into the source code of the app or a
>> >> associated resource bundle, which cannot be entirely protected from
>> >> reverse engineering. Second, effectively such secrets cannot be
>> >> revoked since this would immediatly put all installations out of
>> >>
>> >> work. Moreover, since the authorization server cannot really trust
>> >>
>> >> on the client's identity, it would be dangerous to indicate to end-
>> >> users the trustworthiness of the client.
>> >>
>> >>
>> >> bon je ne commenterais pas ce passage.
>> >>
>> >> par contre j'aimerais rebondir sur ces histoire de token (les vrais,
>> >> pas les
>> >> client_secret)
>> >> il me semble que les token identifient une autorisation, cad un couple
>> >> client/user avec les permission correspondantes.
>> >> j'ai encore du mal a voir si on doit sauver les token quelques par pour
>> >> eviter a l'utilisateur de devoir se logger a chaque redemarage d'appli.
>> >>
>> >> voila je c pas si ca aporte du grain au moulin, je v relire tes
>> >> propositions
>> >>
>> >> Le 31 janvier 2012 08:24, flagos <
flagospub@xxxxxxxxx> a écrit :
>> >>
>> >>> Je fais un up sur le sujet, faut qu'on avance la dessus aussi
>> >>>
>> >>> Je reprends le truc depuis le debut:
>> >>>
>> >>> soit on dit que chaque serveur genere ses propres cles => ce qui
>> >>> oblige a faire un protocole pour que les applis demande
>> >>> automatiquement une clé. C'est faisable via une api rest par exemple.
>> >>> Il faut ensuite qu'elle stocke cette clé et qu'elle offre un moyen
>> >>> facile pour l'utilisateur de supprimer cette clé (en cas de format de
>> >>> la machine par exemple). Ca me semble pas infaisable, mais cela
>> >>> remonte de la complexité au niveau appli. La sécurité n'est pas
>> >>> compromise. Cependant on dévie clairement de oauth2, y va y avoir du
>> >>> hack autour des libs pour oauth2.
>> >>>
>> >>> soit on centralise la gestion des clés => ca nous oblige a gerer un
>> >>> truc en central pour que les gens qui veulent faire leur applis
>> >>> puissent s'incrire (un mail ca suffit) et a faire un wget pour aller
>> >>> recuperer la derniere version (ou via des machins de migration a
>> >>> chaque release d'opos ?). On revient a un fonctionnement classique de
>> >>> oauth2. Il faut bien faire gaffe a ce qu'on recupere pour pas
>> >>> compromettre la sécurité du bouzin. Un avantage aussi est qu'un
>> >>> instance d'un client pour fonctionner sur 2 opos differents sans avoir
>> >>> 15 000 considerations a gerer.
>> >>>
>> >>> Le 28 janvier 2012 12:28, flagos <
flagospub@xxxxxxxxx> a écrit :
>> >>> > Yop,
>> >>> >
>> >>> > Bon j'aimerai faire le point sur ces histoires de tokens pour
>> >>> > oauth2.
>> >>> > Distinguons plusieurs cas:
>> >>> >
>> >>> > Les pseudo clients: il s'agit des plugins locaux qui font
>> >>> > passerelle,
>> >>> > ex: rails, jabber. Ils ont l'avantage d'etre en local, on peut
>> >>> > facilement recuperer leurs token en local, suffit de se mettre
>> >>> > d'accord sur un petit formalisme.
>> >>> >
>> >>> > Les clients distants: Il s'agit d'une appli distribué sur le device
>> >>> > du
>> >>> > client. ex: widget gnome, CLI, appli android. Je ne sais pas quelle
>> >>> > confiance on peut accorder a un client-secret distribué de cette
>> >>> > maniere.
>> >>> >
>> >>> > Les autres sites web: ex: rails s'il est intallé sur un serveur
>> >>> > central pour mutualiser les ressources. On est en pleins dans
>> >>> > oauth2.
>> >>> > Le client-secret ne peut pas etre regeneré a chaque fois. => besoin
>> >>> > d'une db distante et centrale pour ceux la, a moins que le site
>> >>> > manipule autant de client-secret que de serveurs vers lequel il peut
>> >>> > se connecter.
>> >>> >
>> >>> > --
>> >>> > Tapé depuis mon clavier
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Tapé depuis mon clavier
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Tapé depuis mon clavier
>>
>>
>>
>> --
>> Tapé depuis mon clavier
>>
>>
>
--
Tapé depuis mon clavier