iOSアプリを開発していて、FacebookなどのOAuthを利用しつつ、自社のweb apiにアクセスする際の認証・認可の方法を考えています。
具体的にはpinterestはfoursquareなどと同様の仕組みです。
解決策
数人で考えてみました。
1. 自社の web api 認証にOAuth providerのuid, tokenを使いまわす
（その場に居た人が大きな声では言えないが、こうしていると言ってていて「それやばいっしょ」って話になったのであえて解決策の1に挙げてますがダメなやつ）
- 自社の web api でユーザーのヒモ付をOAuth providerのuid, 初回に発行されたtokenで行う
- token はしっかり守っていないといけないのでは？
- 本来、OAuth provider 認可に利用するtokenを自分のweb api認証・認可に使いまわすのはだめじゃない？
この方法はセキュリティ的にはなしでは？
2. web api 認証にサイト独自tokenを利用する
どのように行うか
- web view を用いて、そこでOAuth providerへ認証・認可を求めるフローをはじめる
- OAuth provider認証ボタン、それ以降のフローを開発者が詐称出来る。(urlバーがでないのでフィッシング可能)
- 上記問題はアプリをインストールした時点でアプリを信用しているということで担保出来るのでは？という案もある
- 割りと色々なアプリでやられているが上記のリスクがあるので避けたい
- browser を裏で開き1と同様のフローをたどる
- 例えば、facebookアプリを使っているユーザーにとってはbrowser側でも認証しないといけないのが不便
- 他にもなんかあったような？
- 第三の案は以下
facebookのパターン
- facebook sdkで認証終了後、web apiにtokenを渡し、web apiからfacebook apiを /meを叩く。
- その結果のfacebook uidと照らし合わしユーザーを確認。
- /appを叩き、アプリ自体の認証
- web apiでtokenを発行し、以後そのtokenでweb apiとやりとりする。
facebook sdkの場合、iosのfacebookアプリを入れていると、認証時にiosのfacebookアプリが立ち上がりますが、そのアニメーション自体を詐称したアプリ作ると、web viewと同じリスクあるのではという議論があります。
twitterのパターン
OAuth1.0は、APIアクセスする度にclient secret使うので/appでの認証が不要だがfacebookとほぼ同様のフロー