独自パスワードでやってきたサービスがGoogle、Facebookのようなアカウントと連携する際の基本的な考え方
今までメアド/パスワードで認証させてきたところが、確認済メアドを提供する外部アカウントを用いて登録/既存ユーザーのUXを改善させようと思った時の基本的な考え方を載せておく。
外部アカウントの使いどころ
ここでは新規アカウント登録機能や認証機能との連携を対象としている。
使う情報は以下の3点となる。
- ユーザー識別子
- 確認済メールアドレス
- プロフィール情報
ユーザー識別子
- 自社のユーザー識別子と組み合わせて管理する
- 実際に行われる処理
- 新規登録時 : 紐づいている自社のアカウントが存在しないことを確認する
- 既存のアカウントとの連携時 : 紐づいている自社のアカウントが存在しないことを確認する
- ログイン時 : 紐づいている自社のアカウントが存在することを確認する
確認済メールアドレス
- 既存機能で手動のメールアドレス確認を行っている場合、確認済メールアドレスを取得することでその確認処理をスキップできることもある
- 確認済メールアドレスにも厳密には2種類あるかもしれない
- 手動で確認されたメールアドレス : Facebookのログインメールアドレス、実はmixiもログインメールアドレスを提供している
- サービス提供のメールアドレス : GoogleのGmailアドレスのようなもの
- 使い方はサービスのポリシーによるところが多いので、そこはよしなに扱う
- ログインメールアドレスとして使っているので、ユーザーに対して一意なものとして扱う
- 確認済の連絡先として、１ユーザーに対して複数の確認済メアドが登録可能、重複を許す などもあるだろう
- 実際に行われる処理(上述のとおり、柔軟な使い方があるのであくまで一般例)
- 新規登録時 : 手動のメールアドレス確認をスキップする。ユニーク制約の有無によって細かいところは変わる
- 既存のアカウントとの連携時 : 基本的には利用しなくて良さそう。複数の確認済メアドを所持するときは、このタイミングで確認済メアドのリストに加えても良いかも
- ログイン時 : 利用しなくて良いのでは
プロフィール情報
- プロフィール情報を登録させる場合は、初期値や入力フォームの補完に利用する
- 値が返ってこない可能性も考える
- 必ず取得できる情報とそうでないものもあるので、値がとれずにエラーになることは避けるようにする
- 実際に行われる処理
- 新規登録時
- 全ての必要な情報が取得できる場合(ニックネームと画像程度)、デフォルト値として利用して登録を完了させても良さそう
- 足りない情報がある場合や公開される情報が多い場合など、入力フォームの互換的に使うのが良さそう
パスワードの撤廃
外部アカウントの利用によって既存のパスワードの利用を全て撤廃できるかというのは難しいところである。
ログイン状態であれば基本的に全ての機能をノンストップで利用できるようなサービスの場合は、問題ないだろう。
問題になるのは、課金などのセンシティブな処理の前にパスワード確認をしているようなサービスである。
理想としては、連携している外部アカウントが下記の項目を満たすことが重要になると考える。
- いつログインしたかがわかる
- どのような認証方式でログインしたかがわかる
- 利用するサービス側から再認証を要求できる
Googleで5分以内にログイン済のユーザーがいた場合、それは本人とみなしてもよいかもしれない。
ソフトウェアトークンによる多要素認証を利用したユーザーとそうではないユーザーでは処理を変えてもよいかもしれない。
利用する側から再認証を要求できれば、重要な処理の前にGoogleに戻り再認証をさせて処理を続けることができるかもしれない。
しかし、Googleは現在そのような値を提供していない。
これらの機能が提供されない場合は、(個人的には非常に不本意ではあるが)独自パスワードを残して課金前などに確認させるという実装になってしまうことがあるかもしれない。
実装
OAuthとかの話になるのでまた別の機会に。