Re: [openplacos-dev] Re: foutus token

[flagos <flagospub@xxxxxxxxx>]

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