この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の16日目です。
筆者は現在、AirREGIの海外展開プロジェクトに携わっています。その中で、いわゆるAirシリーズのIdentity Providerとなるサービスを開発しているのですが、車輪の再発明感が半端ないと思い、世の中の解決策を調べたところGoogle Identity Tool Kitなるものを見つけて試してみたので、今回はその紹介です。(これを採用したという話ではありません)
TL;DR
- GITKitを使ってみた
- アカウント管理なんていらんかったやー(^o^)/
- 面倒なところは任せてユーザに価値を届けられるところに集中しよう
Google Identity ToolKitとは
Google Identity Toolkit(以下GITkit)のページには以下のように紹介されています。
Identity Toolkit gives you a robust, secure authentication system in a box that helps you do sign-in the right way, no matter what account your users want to use
とあります。なんかよさそう。GITkitはAndroid, iOS, Webの三つのプラットフォームで利用することができるのですが、今回はWebを試してみようと思います。さっそく、Webへ行っています。
すると、まず全体概要として以下のアーキテクチャの図が出てきました。
なるほど、わからない。この雲はグーグルさんということだろうか。どこでどんな情報が管理されるのか、どういう仕組みになっているのか、実際に動かしてみることにしましょう。
Getting started with GITKit
GITKitを実際に試してみるのに、コードを書く必要はありません。Quickstart AppがPython,PHP,Java,Go,Node.js,そしてRubyで用意されています。Google Developers Consoleで必要な設定を行って、サンプルコードの設定を変更すれば利用可能になります。
Step by stepのtutorialはgoogleのサイトにお任せするとして、最低限必要な設定をまとめると以下のようなものになります。
-
Google Developers Consoleでプロジェクトを作成し、GITKitのAPIを有効にする。
-
OAuth2クライアント登録をする。(他のIDPを利用する場合はそちらでもOAuth2クライアントとして自分のアプリを登録をする)
- これによって、エンドユーザが選択できる認証手段(Google、 Facebook、 etc)を追加することができます。
-
Browser API Keyを発行する。JavascriptでGoogleのAPIを叩けるようにします。
-
IDPKit APIに以下のURLを登録する。(パスはサンプルアプリでの設定です)
- widget URL:
/widget- sign-inボタンを設置するページであり、OAuth2のcallback URLでもあります。
- Sign-in Success URL:
/- Sign-inに成功した後にユーザを連れてきて欲しいURLを登録します。必要であれば、このURLに遷移してきたときに、session cookieを作成したりなどします。
- Sign-out URL:
/- (User Card widgetを利用する場合) ユーザがsign-outをした時に, 遷移させるURLです。
- Send email URL:
/- パスワード忘れや、アカウント忘れなどのときにメールを送ることってありますよね。そうしたケースに、 GoogleさんがこのURLに送り先と内容を送りつけてくるようです。Googleから送りつけるとemail source verificationでspam判定されてしまうそうな。。。
- widget URL:
-
(Optional) Facebookなどの他サービスのclient_id、client_secretをGoogleに登録します。
- 他のIDPで登録したアプリのid, secretを登録する必要が有ります。secretとはなんだったのか。あの雲はgoogleさんだった模様。GITKitを利用するサービスに変わって、アクセストークンの発行とかも肩変わりしちゃうよということだったようです。
認証のフロー
実際に動かしてみて認証フローを調べてみました。動きを見る限りだと以下のようなフローが基本になっているようです。(OpenIDのaccount chooserが入るパターンもありますが、基本は多分こんな感じ)
注: 動かした結果の解釈なので, 異なっている可能性もあります. 特に8-11は動かしてみた結果の推察です.
基本はGoogleが提供しているJavascriptとwidgetで済むようになっていて、そのJSが然るべくGITKitのAPIを叩きながら認証のフローを完了させJWTをクッキーに埋め込むところまでやってくれて、その後は御自由にどうぞ、という作りになっているようです。
JWTの中にはLocal UserID(自サービス内でユニーク)、有効期限が入っているので、その期限に合わせたサービスの提供でもよいですし、あるいはその有効期限とは別の有効期限を独自で設定したりなど、そこからの実装は自由に選択できそうです。
まとめ
- IDPKitを利用すれば、認証周りの機能やアカウントの管理をGoogle先生に任せられる(依存できる)
- 自サービスでアカウント持つ必要なんてなかったんやー(^o^)/
- 面倒な部分は任せてしまって、ユーザに価値を届けられるところに集中しよう