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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

OAuth Dance
http://alpha.mixi.co.jp/entry/2013/12020/

View Slide

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

View Slide

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

View Slide

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

View Slide

連携キャンセル時の挙動
https://www.timeticket.jp

View Slide

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

View Slide

http://yapcasia.org/2014/login?error=access_denied

View Slide

未登録ユーザーの扱い
https://miil.me/

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

CSRFフロー

View Slide

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

View Slide

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

View Slide

CSRF対策により検知可能

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

SDKなどで取得したAccess Tokenを送信
User
Native
App
IdP
Backend
Server
（SDK）認証処理、アクセス権限への同意など
Access Token要求
Backend Serverに
Acess Tokenを送信
Access Tokenの発行先を確認

View Slide

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

View Slide

(UI)WebViewでWebアプリ向けの
Authorization Codeを取得して送信
User
Native
App
IdP
Backend
Server
(WebView)認証処理、アクセス権限への同意など
Authorization Code取得
Backend ServerにAuthorization Codeを送信
Access Tokenと交換

View Slide

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

View Slide

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

View Slide

Googleの場合
User
Native
App
IdP
Backend
Server
（SDK）認証処理、アクセス権限への同意など
Authorization Code取得
Backend ServerにAuthorization Codeを送信
Access Tokenと交換

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

導入事例

View Slide

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

View Slide

Googleアカウントでログイン/登録が可能

View Slide

未連携＆キャンセル

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

ritou

More Decks by ritou

Other Decks in Technology

Featured

Transcript