Google Identity ToolKitの紹介

この記事はリクルートライフスタイル 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判定されてしまうそうな。。。

• (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^)/
• 面倒な部分は任せてしまって、ユーザに価値を届けられるところに集中しよう