ソーシャルプラットフォームが前面に出てユーザ認可を得ようとする動きはアリかナシか?

0
👹秋田の猫🐱 @ritou

ParseっていうBaaSのソーシャル連携の実装がよろしくない気がする - r-weblife http://t.co/1UkhQMSW

2012-05-24 03:34:50
がぶ飲み @gabunomi_

@ritou 1点質問が。Request/Access TokenをParseプラットフォームが取得する案についてです。「ユーザーが認可するのはParseアプリだと思うのですが、そのAccessTokenをParseプラットフォームに渡すのは認可先の観点で問題ないのでしょうか。」

2012-05-25 02:31:21
👹秋田の猫🐱 @ritou

@gabunomi0320 現状もアクセストークンはParseプラットフォームに渡されるので、認可先の問題はあると思います。○○プラットフォーム上で動く▲▲アプリとして動くことをポリシーURLとともにユーザーに伝えて同意をもらうとかしないといけない気はしています。

2012-05-25 07:37:00
がぶ飲み @gabunomi_

@ritou やはり認可先の問題はありますよね。 // サイトの追記見ました。トークンをプラットフォーム側で管理する方が良いという考えなんですね。なるほど。

2012-05-25 16:04:55
👹秋田の猫🐱 @ritou

@gabunomi0320 似たようなところで、ソーシャルログインと呼ばれるものにも同様の同意先の課題があります。 http://t.co/lwhuGIBa ←例えば、FBでログインさせるためにClient ID/Secret渡して戻り先の処理をJanRainがやります。

2012-05-25 16:41:35
がぶ飲み @gabunomi_

@ritou 確かにJanRainにも同様の問題がありますね。 // ソーシャルログインは、GigyaのようにGigyaプラットフォームの認証/認可にて実現させるのが良いのでは?というのが現在の考えです。Gigya自身がTwitterクライアントになるイメージで。

2012-05-25 19:46:45
👹秋田の猫🐱 @ritou

@gabunomi0320 認可相手として明白でいいと思います。しかし、BaaSも前面に出てくるのはちょっとアレですね。。。

2012-05-25 20:41:48
がぶ飲み @gabunomi_

@ritou BaaSが前面に出てくると抵抗ありますか。ふむ…。 // BaaS提供OAuthの認証部分をSNS提供OAuthで担えば、認可先が明瞭なSNSログインが実現する気がしてます。「SNSで認証」「SNS経由でParseを認可」「Parse経由でParseアプリを認可」。

2012-05-27 22:16:33
👹秋田の猫🐱 @ritou

@gabunomi0320 考えに同意です。自分でもプラットフォーム側でやるべきと言いながら、なんとなくユーザーがBaaS含めた多段の認可をどれだけ理解できるのかなと不安を覚えてましたが、やはりちゃんと説明(教育)して同意もらうしかないですね。

2012-05-27 22:39:57