| [openplacos-dev] foutus token |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/openplacos-dev Archives
]
- To: openplacos-dev@xxxxxxxxxxxxxxxxxxx
- Subject: [openplacos-dev] foutus token
- From: flagos <flagospub@xxxxxxxxx>
- Date: Sat, 28 Jan 2012 12:28:48 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=asPH+aE31Qtz9SsDD2lQByjXO/jVF2woyDZqq8eE3Ik=; b=WWeQkpuqV6ZtbTXa04ErZKejmoQTOfnpWWrRYFxIhDQqBORDMPVjjuf2kf6k0JC4Dm DBVfgXbV8m0VAMmWygaODyC4UR+rehgHH47kWMGknQbIB4oSbJBmT3OyqbrlbWvMDsGN VUwNMU0KvddQOcq10AVCfxQ1dI/17fu5gMwGs=
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