je vais citer quelques bout du draft relatif a la securité dont j'ai passé les liens il y a quelques temps.
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.
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