OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること #yapcasia

YAPC::Asia Tokyo 2014 で話したスライドです。
http://yapcasia.org/2014/talk/show/cc57f3ca-01b8-11e4-b7e8-e4a96aeab6a4

Transcript

1. OAuth/OpenID Connectを用いて ID連携を実装するときに気を付けること Ryo Ito(@ritou) YAPC::Asia Tokyo 2014 1
2. 用語定義 :ソーシャルログイン • FacebookやGoogleなど外部サービスの認証結果 やユーザーの属性情報を自サービスの認証や 新規登録に利用するしくみ YAPC::Asia Tokyo 2014 2
3. 内容 • ソーシャルログインを利用する際に気をつけること • パスワード認証しているサービスへのソーシャル ログインの導入 • 導入事例 YAPC::Asia Tokyo 2014 3
4. 自己紹介 • Ryo Ito (@ritou) ← あーるいとう or りとう • OpenID Foundation Japan : Evangelist • http://www.openid.or.jp/ • エンジニア@株式会社ミクシィ • CPAN • OAuth::Lite2 • OIDC::Lite YAPC::Asia Tokyo 2014 4
5. YAPC::Asia Tokyo 2013 • OpenID Connect これが最新のOpenID仕様だッ！ • www.slideshare.net/ritou/yapc2013-ritou-oidc YAPC::Asia Tokyo 2014 5
6. ソーシャルログインを利用する際に 気をつけること https://qiita.com/ http://yapcasia.org/2014/login YAPC::Asia Tokyo 2014 6
7. の前に、ソーシャルログインの目的 • 利便性向上 • アカウント登録のハードルを下げる • 属性情報の利用 • コスト削減 • 認証機能の実装コスト(まじめにやると高くつく) YAPC::Asia Tokyo 2014 7
8. OAuth Dance YAPC::Asia Tokyo 2014 8 http://alpha.mixi.co.jp/entry/2013/12020/
9. 実装 • 各サービスのSDKを利用 • WebApplicationFrameworkのプラグイン • 各言語の汎用ライブラリ YAPC::Asia Tokyo 2014 9
10. 気をつけること • UI/UX : 使いやすく • セキュリティ : 安全に YAPC::Asia Tokyo 2014 10
11. UI/UX 1. 連携キャンセル時の挙動 2. 未登録ユーザーの扱い 3. 前回のログイン情報の取り扱い YAPC::Asia Tokyo 2014 11
12. 連携キャンセル時の挙動 YAPC::Asia Tokyo 2014 12 https://www.timeticket.jp
13. 連携キャンセル時の挙動 • 果たしてエラーなのか？ユーザーの意図は？ • Permission多すぎでやめた -> 使うのやめたい • このアカウントじゃなかった！ -> やりなおしたい • error=access_denied などで判別可能 • 次のアクションにつなげられるようにすべき YAPC::Asia Tokyo 2014 13
14. 連携キャンセル時の挙動 YAPC::Asia Tokyo 2014 14 http://yapcasia.org/2014/login?error=access_denied
15. 未登録ユーザーの扱い YAPC::Asia Tokyo 2014 15 https://miil.me/
16. 未登録ユーザーの扱い • エラー扱いや新規登録からやり直して系の文言 • 新規登録フローに誘導するのも効果的 • 属性情報もうまく使って最短経路を提供 • どこまで進めてよいかは要検討 • 利用規約へ同意するタイミング • 勝手に登録完了？嫌がるユーザーもいる YAPC::Asia Tokyo 2014 16
17. 過去のログイン情報の取り扱い • 多くのサービスはログアウト後 一覧からやりなおし • 以前から、アイコンが並ぶUIは混乱を招くと言われ ていた 「どのアカウント使ってたっけ？」 • 前回利用したサービスを保存して利用する • デフォルト表示 or 強調表示 YAPC::Asia Tokyo 2014 17 http://janrain.com/product/social-login/
18. セキュリティ • Webアプリ • リダイレクト時のCSRF対策 • ネイティブアプリ • バックエンドサーバーとのやりとり YAPC::Asia Tokyo 2014 18
19. WebアプリとCSRF • OAuthのセキュリティ強化を目的とする拡張仕様を 導入しました - mixi Engineers' Blog • http://alpha.mixi.co.jp/entry/2013/12020/ • 最初の部分でこの問題について触れている • OAuth2.0で強制連携させるCSRFの影響と、その対 策について • http://subtech.g.hatena.ne.jp/mala/20140724/1406209 989 YAPC::Asia Tokyo 2014 19
20. CSRFフロー YAPC::Asia Tokyo 2014 20 http://alpha.mixi.co.jp/entry/2013/12020/
21. リスク • 第3者のアカウントでログインさせられる • クレカ情報、住所情報を知られるリスク • 第3者のソーシャルログイン アカウントと連携 • 第3者がログインできる -> アカウントのっとり YAPC::Asia Tokyo 2014 21
22. 対策 • 通常のCSRF対策をクロスドメインで行う必要がある • 外部サービスに引き回すstateパラメータを用いる • セッションと紐づけておいて戻ってきたら検証 • stateパラメータにセッションIDそのものは利用しない YAPC::Asia Tokyo 2014 22
23. YAPC::Asia Tokyo 2014 23 http://alpha.mixi.co.jp/entry/2013/12020/ CSRF対策により検知可能
24. ネイティブアプリとソーシャルログイン ソーシャルログインを認証に利用する場合、バック エンドサーバーとのやりとりが必要となる 1. アプリはAccess Tokenなどをバックエンドサー バーに送信 2. バックエンドサーバーはユーザー識別子を取得 3. 紐づく自サービス内のユーザーを特定し、セッ ション発行などの処理 YAPC::Asia Tokyo 2014 24
25. ネイティブアプリとソーシャルログイン YAPC::Asia Tokyo 2014 25 User Native App IdP Backend Server 「◦◦でログイン」 認証処理、アクセス権限への同意など トークンなどをやりとり Backend Serverに 送信 ログイン情報など ユーザー識別子を要求
26. 連携方法は各サービスによって異なる • SDKなどで取得したAccess Tokenを送信 • (UI)WebViewでWebアプリ向けのAuthorization Codeを取得して送信 YAPC::Asia Tokyo 2014 26
27. SDKなどで取得したAccess Tokenを送信 • 大手BaaSでも採用されている方式 • SDKやOSネイティブ機能でAccess Tokenを受け取る • 「Token Replace Attack(置換攻撃)」のリスク • 他のアプリ向けのAccess Tokenによりアカウントののっ とりが行われる可能性がある • バックエンドサーバーは必ずそのAccess Tokenが 自らのアプリに対して発行されたことを確認する • 通信路が云々… YAPC::Asia Tokyo 2014 27
28. SDKなどで取得したAccess Tokenを送信 YAPC::Asia Tokyo 2014 28 User Native App IdP Backend Server 「◦◦でログイン」 （SDK）認証処理、アクセス権限への同意など Access Token要求 Backend Serverに Acess Tokenを送信 ログイン情報など Access Tokenの発行先を確認 ユーザー識別子を要求
29. (UI)WebViewでWebアプリ向けの Authorization Codeを取得して送信 • 昔から行われている方式の一つ • Client Credential(Client Secret)をアプリで持つ必要 がないことは良い • Authorization Code -> Access Tokenの変換はバックエン ドサーバーが行う • WebViewで外部サービスの画面表示するのは フィッシングなどの面から良くない YAPC::Asia Tokyo 2014 29
30. (UI)WebViewでWebアプリ向けの Authorization Codeを取得して送信 YAPC::Asia Tokyo 2014 30 User Native App IdP Backend Server 「◦◦でログイン」 (WebView)認証処理、アクセス権限への同意など Authorization Code取得 Backend ServerにAuthorization Codeを送信 ログイン情報など Access Tokenと交換 ユーザー識別子を要求
31. ネイティブアプリで気をつけること • Access Tokenを送信する場合は検証が必要 • Authorization Codeを送る方法は安全だが、 (UI)WebViewにて認証画面や同意画面を出すの は良くない すっきりしないのは、ソーシャルログインを提供する 側がネイティブアプリ + バックエンドの利用を想定し ていないから… YAPC::Asia Tokyo 2014 31
32. Googleの場合 • GoogleではProjectに複数Clientがぶら下がる • Webアプリ • iOSアプリ • Androidアプリ • ネイティブアプリ向けSDKからWebアプリ向けの Authorization Codeを取得可能 • バックエンドサーバーがAuthorization CodeからAccess Tokenに変換 • (おまけ)ユーザー識別子の取得だけならID Tokenを利 用するのが便利(OpenID Connect仕様をサポート) YAPC::Asia Tokyo 2014 32
33. Googleの場合 YAPC::Asia Tokyo 2014 33 User Native App IdP Backend Server 「◦◦でログイン」 （SDK）認証処理、アクセス権限への同意など Authorization Code取得 Backend ServerにAuthorization Codeを送信 ログイン情報など Access Tokenと交換 ユーザー識別子を要求
34. パスワード認証しているサービスへの ソーシャルログインの導入 • どの外部サービスを利用？ • ソーシャルログインにより どの機能を省略(代替)する？ • どの機能から？ • どのデバイスから? YAPC::Asia Tokyo 2014 34
35. どの外部サービスを利用？ • サービスの特性 • 利用できる属性情報 • プロフィール情報 • メールアドレス • ニックネーム YAPC::Asia Tokyo 2014 35
36. ソーシャルログインにより どの機能を省略(代替)する？ • 認証 • 全ての認証 • 最初のログインで全ての機能が使える • 強度の低い認証 • 最初のログインである程度までの機能が使える • 重要な処理の前に二段階認証や、パスワード確認 • メールアドレス確認 • Googleが自社で提供しているGmailのメアド • Facebookが確認済みのメアド • 属性情報の入力 • 姓名、ニックネームなど YAPC::Asia Tokyo 2014 36
37. どの機能から？ • 既存アカウントとの連携 & ログイン • 既存ユーザーの利便性向上 • 新規登録より先に実装しても問題ない • 新規登録 • 新規ユーザーの利便性向上 YAPC::Asia Tokyo 2014 37
38. どのデバイスから? • スマートフォン向けWebアプリ • 文字入力が面倒 • PCより新規登録時のハードルが高い(?) • PC向け Webアプリ • ネイティブアプリ • ログアウトの機会は比較的少ない YAPC::Asia Tokyo 2014 38
39. 導入事例 YAPC::Asia Tokyo 2014 39
40. mixiとGoogleアカウント • 2014/08/04 プレスリリース http://mixi.co.jp/press/2014/0804/12248/ YAPC::Asia Tokyo 2014 40
41. Googleアカウントでログイン/登録が可能 YAPC::Asia Tokyo 2014 41
42. 未連携＆キャンセル YAPC::Asia Tokyo 2014 42
43. mixiのユーザー登録/認証 • 登録時の確認項目 • メールアドレス : 確認用メールの送信 • 電話番号の確認 : SMS/IVR • メールアドレス/パスワードで認証 • 各種設定変更やセンシティブな処理の前にパス ワード確認 YAPC::Asia Tokyo 2014 43
44. mixiのユーザー登録/認証 • 登録時の確認項目 • メールアドレス : 確認用メールの送信 • 電話番号の確認 : SMS/IVR • メールアドレス/パスワードで認証 • 各種設定変更やセンシティブな処理の前にパス ワード確認 • ↑パスワード撤廃失敗 YAPC::Asia Tokyo 2014 44
45. 実装順序 • 機能 • 既存アカウントとの連携/ログイン -> 新規登録 • デバイス • スマートフォンブラウザ -> ??? YAPC::Asia Tokyo 2014 45
46. まとめ • UI/UXのちょっと改善できそうな点と、セキュリティ 面で気をつけてほしい点を紹介した • 既存のサービスに導入する際には、ソーシャルロ グインによりどの機能を置き換えられるかを考慮 すべき • mixiがGoogleアカウントに対応したことを紹介 YAPC::Asia Tokyo 2014 46
47. 終わり • 気になった点があれば声をかけてください • Twitterで @ritou 宛のメンションでもかまいません • 「社内勉強会に講師を派遣します」 • http://www.openid.or.jp/blog/2014/06/oidfj-supports- internal-tech-seminar.html YAPC::Asia Tokyo 2014 47