Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

658c29959d8a9fd352afa440a5813137?s=47 ritou
August 30, 2014

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

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

658c29959d8a9fd352afa440a5813137?s=128

ritou

August 30, 2014
Tweet

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