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

by ritou

Slide 1

Slide 1 text

OAuth/OpenID Connectを用いて ID連携を実装するときに気を付けること Ryo Ito(@ritou) YAPC::Asia Tokyo 2014 1

Slide 2

Slide 2 text

用語定義 :ソーシャルログイン • FacebookやGoogleなど外部サービスの認証結果やユーザーの属性情報を自サービスの認証や新規登録に利用するしくみ YAPC::Asia Tokyo 2014 2

Slide 3

Slide 3 text

内容 • ソーシャルログインを利用する際に気をつけること • パスワード認証しているサービスへのソーシャルログインの導入 • 導入事例 YAPC::Asia Tokyo 2014 3

Slide 4

Slide 4 text

自己紹介 • Ryo Ito (@ritou) ← あーるいとう or りとう • OpenID Foundation Japan : Evangelist • http://www.openid.or.jp/ • エンジニア@株式会社ミクシィ • CPAN • OAuth::Lite2 • OIDC::Lite YAPC::Asia Tokyo 2014 4

Slide 5

Slide 5 text

YAPC::Asia Tokyo 2013 • OpenID Connect これが最新のOpenID仕様だッ！ • www.slideshare.net/ritou/yapc2013-ritou-oidc YAPC::Asia Tokyo 2014 5

Slide 6

Slide 6 text

ソーシャルログインを利用する際に気をつけること https://qiita.com/ http://yapcasia.org/2014/login YAPC::Asia Tokyo 2014 6

Slide 7

Slide 7 text

の前に、ソーシャルログインの目的 • 利便性向上 • アカウント登録のハードルを下げる • 属性情報の利用 • コスト削減 • 認証機能の実装コスト(まじめにやると高くつく) YAPC::Asia Tokyo 2014 7

Slide 8

Slide 8 text

OAuth Dance YAPC::Asia Tokyo 2014 8 http://alpha.mixi.co.jp/entry/2013/12020/

Slide 9

Slide 9 text

実装 • 各サービスのSDKを利用 • WebApplicationFrameworkのプラグイン • 各言語の汎用ライブラリ YAPC::Asia Tokyo 2014 9

Slide 10

Slide 10 text

気をつけること • UI/UX : 使いやすく • セキュリティ : 安全に YAPC::Asia Tokyo 2014 10

Slide 11

Slide 11 text

UI/UX 1. 連携キャンセル時の挙動 2. 未登録ユーザーの扱い 3. 前回のログイン情報の取り扱い YAPC::Asia Tokyo 2014 11

Slide 12

Slide 12 text

連携キャンセル時の挙動 YAPC::Asia Tokyo 2014 12 https://www.timeticket.jp

Slide 13

Slide 13 text

連携キャンセル時の挙動 • 果たしてエラーなのか？ユーザーの意図は？ • Permission多すぎでやめた -> 使うのやめたい • このアカウントじゃなかった！ -> やりなおしたい • error=access_denied などで判別可能 • 次のアクションにつなげられるようにすべき YAPC::Asia Tokyo 2014 13

Slide 14

Slide 14 text

連携キャンセル時の挙動 YAPC::Asia Tokyo 2014 14 http://yapcasia.org/2014/login?error=access_denied

Slide 15

Slide 15 text

未登録ユーザーの扱い YAPC::Asia Tokyo 2014 15 https://miil.me/

Slide 16

Slide 16 text

未登録ユーザーの扱い • エラー扱いや新規登録からやり直して系の文言 • 新規登録フローに誘導するのも効果的 • 属性情報もうまく使って最短経路を提供 • どこまで進めてよいかは要検討 • 利用規約へ同意するタイミング • 勝手に登録完了？嫌がるユーザーもいる YAPC::Asia Tokyo 2014 16

Slide 17

Slide 17 text

過去のログイン情報の取り扱い • 多くのサービスはログアウト後一覧からやりなおし • 以前から、アイコンが並ぶUIは混乱を招くと言われていた「どのアカウント使ってたっけ？」 • 前回利用したサービスを保存して利用する • デフォルト表示 or 強調表示 YAPC::Asia Tokyo 2014 17 http://janrain.com/product/social-login/

Slide 18

Slide 18 text

セキュリティ • Webアプリ • リダイレクト時のCSRF対策 • ネイティブアプリ • バックエンドサーバーとのやりとり YAPC::Asia Tokyo 2014 18

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

CSRFフロー YAPC::Asia Tokyo 2014 20 http://alpha.mixi.co.jp/entry/2013/12020/

Slide 21

Slide 21 text

リスク • 第3者のアカウントでログインさせられる • クレカ情報、住所情報を知られるリスク • 第3者のソーシャルログインアカウントと連携 • 第3者がログインできる -> アカウントのっとり YAPC::Asia Tokyo 2014 21

Slide 22

Slide 22 text

対策 • 通常のCSRF対策をクロスドメインで行う必要がある • 外部サービスに引き回すstateパラメータを用いる • セッションと紐づけておいて戻ってきたら検証 • stateパラメータにセッションIDそのものは利用しない YAPC::Asia Tokyo 2014 22

Slide 23

Slide 23 text

YAPC::Asia Tokyo 2014 23 http://alpha.mixi.co.jp/entry/2013/12020/ CSRF対策により検知可能

Slide 24

Slide 24 text

ネイティブアプリとソーシャルログインソーシャルログインを認証に利用する場合、バックエンドサーバーとのやりとりが必要となる 1. アプリはAccess Tokenなどをバックエンドサーバーに送信 2. バックエンドサーバーはユーザー識別子を取得 3. 紐づく自サービス内のユーザーを特定し、セッション発行などの処理 YAPC::Asia Tokyo 2014 24

Slide 25

Slide 25 text

ネイティブアプリとソーシャルログイン YAPC::Asia Tokyo 2014 25 User Native App IdP Backend Server 「○○でログイン」認証処理、アクセス権限への同意などトークンなどをやりとり Backend Serverに送信ログイン情報などユーザー識別子を要求

Slide 26

Slide 26 text

連携方法は各サービスによって異なる • SDKなどで取得したAccess Tokenを送信 • (UI)WebViewでWebアプリ向けのAuthorization Codeを取得して送信 YAPC::Asia Tokyo 2014 26

Slide 27

Slide 27 text

SDKなどで取得したAccess Tokenを送信 • 大手BaaSでも採用されている方式 • SDKやOSネイティブ機能でAccess Tokenを受け取る • 「Token Replace Attack(置換攻撃)」のリスク • 他のアプリ向けのAccess Tokenによりアカウントののっとりが行われる可能性がある • バックエンドサーバーは必ずそのAccess Tokenが自らのアプリに対して発行されたことを確認する • 通信路が云々… YAPC::Asia Tokyo 2014 27

Slide 28

Slide 28 text

SDKなどで取得したAccess Tokenを送信 YAPC::Asia Tokyo 2014 28 User Native App IdP Backend Server 「○○でログイン」（SDK）認証処理、アクセス権限への同意など Access Token要求 Backend Serverに Acess Tokenを送信ログイン情報など Access Tokenの発行先を確認ユーザー識別子を要求

Slide 29

Slide 29 text

(UI)WebViewでWebアプリ向けの Authorization Codeを取得して送信 • 昔から行われている方式の一つ • Client Credential(Client Secret)をアプリで持つ必要がないことは良い • Authorization Code -> Access Tokenの変換はバックエンドサーバーが行う • WebViewで外部サービスの画面表示するのはフィッシングなどの面から良くない YAPC::Asia Tokyo 2014 29

Slide 30

Slide 30 text

(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と交換ユーザー識別子を要求

Slide 31

Slide 31 text

ネイティブアプリで気をつけること • Access Tokenを送信する場合は検証が必要 • Authorization Codeを送る方法は安全だが、 (UI)WebViewにて認証画面や同意画面を出すのは良くないすっきりしないのは、ソーシャルログインを提供する側がネイティブアプリ + バックエンドの利用を想定していないから… YAPC::Asia Tokyo 2014 31

Slide 32

Slide 32 text

Googleの場合 • GoogleではProjectに複数Clientがぶら下がる • Webアプリ • iOSアプリ • Androidアプリ • ネイティブアプリ向けSDKからWebアプリ向けの Authorization Codeを取得可能 • バックエンドサーバーがAuthorization CodeからAccess Tokenに変換 • (おまけ)ユーザー識別子の取得だけならID Tokenを利用するのが便利(OpenID Connect仕様をサポート) YAPC::Asia Tokyo 2014 32

Slide 33

Slide 33 text

Googleの場合 YAPC::Asia Tokyo 2014 33 User Native App IdP Backend Server 「○○でログイン」（SDK）認証処理、アクセス権限への同意など Authorization Code取得 Backend ServerにAuthorization Codeを送信ログイン情報など Access Tokenと交換ユーザー識別子を要求

Slide 34

Slide 34 text

パスワード認証しているサービスへのソーシャルログインの導入 • どの外部サービスを利用？ • ソーシャルログインによりどの機能を省略(代替)する？ • どの機能から？ • どのデバイスから? YAPC::Asia Tokyo 2014 34

Slide 35

Slide 35 text

どの外部サービスを利用？ • サービスの特性 • 利用できる属性情報 • プロフィール情報 • メールアドレス • ニックネーム YAPC::Asia Tokyo 2014 35

Slide 36

Slide 36 text

ソーシャルログインによりどの機能を省略(代替)する？ • 認証 • 全ての認証 • 最初のログインで全ての機能が使える • 強度の低い認証 • 最初のログインである程度までの機能が使える • 重要な処理の前に二段階認証や、パスワード確認 • メールアドレス確認 • Googleが自社で提供しているGmailのメアド • Facebookが確認済みのメアド • 属性情報の入力 • 姓名、ニックネームなど YAPC::Asia Tokyo 2014 36

Slide 37

Slide 37 text

どの機能から？ • 既存アカウントとの連携 & ログイン • 既存ユーザーの利便性向上 • 新規登録より先に実装しても問題ない • 新規登録 • 新規ユーザーの利便性向上 YAPC::Asia Tokyo 2014 37

Slide 38

Slide 38 text

どのデバイスから? • スマートフォン向けWebアプリ • 文字入力が面倒 • PCより新規登録時のハードルが高い(?) • PC向け Webアプリ • ネイティブアプリ • ログアウトの機会は比較的少ない YAPC::Asia Tokyo 2014 38

Slide 39

Slide 39 text

導入事例 YAPC::Asia Tokyo 2014 39

Slide 40

Slide 40 text

mixiとGoogleアカウント • 2014/08/04 プレスリリース http://mixi.co.jp/press/2014/0804/12248/ YAPC::Asia Tokyo 2014 40

Slide 41

Slide 41 text

Googleアカウントでログイン/登録が可能 YAPC::Asia Tokyo 2014 41

Slide 42

Slide 42 text

未連携＆キャンセル YAPC::Asia Tokyo 2014 42

Slide 43

Slide 43 text

mixiのユーザー登録/認証 • 登録時の確認項目 • メールアドレス : 確認用メールの送信 • 電話番号の確認 : SMS/IVR • メールアドレス/パスワードで認証 • 各種設定変更やセンシティブな処理の前にパスワード確認 YAPC::Asia Tokyo 2014 43

Slide 44

Slide 44 text

mixiのユーザー登録/認証 • 登録時の確認項目 • メールアドレス : 確認用メールの送信 • 電話番号の確認 : SMS/IVR • メールアドレス/パスワードで認証 • 各種設定変更やセンシティブな処理の前にパスワード確認 • ↑パスワード撤廃失敗 YAPC::Asia Tokyo 2014 44

Slide 45

Slide 45 text

実装順序 • 機能 • 既存アカウントとの連携/ログイン -> 新規登録 • デバイス • スマートフォンブラウザ -> ??? YAPC::Asia Tokyo 2014 45

Slide 46

Slide 46 text

まとめ • UI/UXのちょっと改善できそうな点と、セキュリティ面で気をつけてほしい点を紹介した • 既存のサービスに導入する際には、ソーシャルログインによりどの機能を置き換えられるかを考慮すべき • mixiがGoogleアカウントに対応したことを紹介 YAPC::Asia Tokyo 2014 46

Slide 47

Slide 47 text

終わり • 気になった点があれば声をかけてください • Twitterで @ritou 宛のメンションでもかまいません • 「社内勉強会に講師を派遣します」 • http://www.openid.or.jp/blog/2014/06/oidfj-supports- internal-tech-seminar.html YAPC::Asia Tokyo 2014 47