ParseっていうBaaSのソーシャル連携の実装がよろしくない気がする - r-weblife http://t.co/1UkhQMSW
2012-05-24 03:34:50@ritou 1点質問が。Request/Access TokenをParseプラットフォームが取得する案についてです。「ユーザーが認可するのはParseアプリだと思うのですが、そのAccessTokenをParseプラットフォームに渡すのは認可先の観点で問題ないのでしょうか。」
2012-05-25 02:31:21@gabunomi0320 現状もアクセストークンはParseプラットフォームに渡されるので、認可先の問題はあると思います。○○プラットフォーム上で動く▲▲アプリとして動くことをポリシーURLとともにユーザーに伝えて同意をもらうとかしないといけない気はしています。
2012-05-25 07:37:00@ritou やはり認可先の問題はありますよね。 // サイトの追記見ました。トークンをプラットフォーム側で管理する方が良いという考えなんですね。なるほど。
2012-05-25 16:04:55@gabunomi0320 似たようなところで、ソーシャルログインと呼ばれるものにも同様の同意先の課題があります。 http://t.co/lwhuGIBa ←例えば、FBでログインさせるためにClient ID/Secret渡して戻り先の処理をJanRainがやります。
2012-05-25 16:41:35@ritou 確かにJanRainにも同様の問題がありますね。 // ソーシャルログインは、GigyaのようにGigyaプラットフォームの認証/認可にて実現させるのが良いのでは?というのが現在の考えです。Gigya自身がTwitterクライアントになるイメージで。
2012-05-25 19:46:45@ritou BaaSが前面に出てくると抵抗ありますか。ふむ…。 // BaaS提供OAuthの認証部分をSNS提供OAuthで担えば、認可先が明瞭なSNSログインが実現する気がしてます。「SNSで認証」「SNS経由でParseを認可」「Parse経由でParseアプリを認可」。
2012-05-27 22:16:33@gabunomi0320 考えに同意です。自分でもプラットフォーム側でやるべきと言いながら、なんとなくユーザーがBaaS含めた多段の認可をどれだけ理解できるのかなと不安を覚えてましたが、やはりちゃんと説明(教育)して同意もらうしかないですね。
2012-05-27 22:39:57