本記事は『Firebase Authenticationで学ぶ ソーシャルログイン入門 ID管理の原則にそった実装のベストプラクティス』の「Chapter 1 IDaaSを使ったソーシャルログイン」から一部を抜粋したものです。掲載にあたって編集しています。
ソーシャルログインとは
ソーシャルログインとは普段利用しているSNSやその他のウェブサービスのユーザー認証を使ってアプリやウェブサイトに登録、ログインする仕組みのことです。
図1.7に示すような、ソーシャルログインのボタンを見たことがある人も多いはずです。
アプリに対してソーシャルログインを提供するサービスのことをアイデンティティプロバイダ（IdP ： Identity Provider）と呼びます。図1.7中にあるIdPの他にも、たくさんのユーザーを抱える以下のようなサービスがIdPとしてソーシャルログインを提供しています。
- Apple
- Microsoft
- Amazon
- LINE
- Yahoo!（Yahoo! JAPAN）
さまざまなIdPが提供するものをまとめて「ソーシャルログイン」と呼んでいますが、仕組みについてはそれぞれ微妙な差があります。
ID（アイデンティティ）とリライングパーティ
アプリのログインにソーシャルログインを採用することで、ユーザー認証をIdPに肩代わりしてもらうことができます。アプリがユーザー認証に関してやるべきことは、IdPから受け取った「今、このアプリを利用しようとしているのは誰か」という情報を検証するだけです。
また、ユーザーのログイン後であれば、アプリは任意のタイミングでユーザー名、メールアドレス、プロフィール画像などの属性情報（アイデンティティ、ID）をIdPから取得することができます。ソーシャルログインという名前でありながら、ログインのための仕組みというよりはアイデンティティ情報を活用する仕組みとして、アイデンティティ連携（ID連携）と呼ぶこともあります。そうしてID連携を受けるアプリのことをリライングパーティと呼びます。ソーシャルログインにおいてはアプリがリライングパーティになります。
「ID」という用語
本書では「ID」という用語を頻繁に使うため、ここで「ID」という言葉について整理しておきましょう。「IdP」「ID連携」におけるIDはIDentity（アイデンティティ）の略です。「アプリのユーザーのアイデンティティ」という文脈に限定して考えるとアイデンティティとは「ユーザーの属性情報」を指します。例えば、「名前」「住所」「メールアドレス」「ユーザー識別子」「パスワード」「IDトークン」などが、アイデンティティになります。
もう1つよく使われる「ID」としては、「ユーザーID」「クライアントID」といった用語で使われる「ID」があります。このIDはIDentifier（アイデンティファイア）の略であり、翻訳すると「識別子」となります。すなわち「ユーザーID」は複数のユーザーの中から一意にユーザーを識別するための識別子を意味します。
本書では混乱を避けるためアイデンティファイアについては「識別子」という言葉を使い、「アイデンティティ」という意味においてのみ「ID」という略称を使います。
ユーザー視点からのメリット
ソーシャルログインには、利用するユーザーとアプリ開発者の双方にメリットがあります。そのうち、ここではまずユーザー視点でのメリットを整理しましょう。ユーザー視点でのメリットは以下の2つです。
- 新しいパスワードが必要ない
- 初期登録の手間が少ない
新しいパスワードが必要ない
ソーシャルログインを使えば、使い慣れたSNSやウェブサービスのパスワードでログインできます。アプリのために新しいパスワードを用意し、覚える必要がありません。
初期登録の手間が少ない
多くの場合、新規登録のフォームに、IdPの属性情報が初期値として設定されているので、そのまま登録する場合は入力する手間が省けます。また、場合によっては登録フォームすらなく、いきなりアプリを使い始めることができます。
開発者視点からのメリット
一方、ソーシャルログイン機能を実装する開発者視点からのメリットは以下の3つです。
- 自前で一からユーザー認証を実装する必要がなくなる
- IdPの高度な認証方式を取り込める
- 登録時の離脱率を低減できる
自前で一からユーザー認証を実装する必要がなくなる
先に述べたように、さまざまな攻撃に対応するためのユーザー認証を自前で実装するのは開発コストがかかります。しかし、ソーシャルログインを採用することで、ユーザー認証をIdPにおまかせできるので、開発コストを格段に低減できます。
IdPの高度な認証方式を取り込める
多くの大手のサービスでは2要素認証やFIDO認証など高度な認証方式に対応しています。ユーザーがそれらを利用している場合、ソーシャルログインを採用するアプリ側でも実質的に高度な認証方式でユーザー認証をしているといえます。
登録時の離脱率を低減できる
一般的に、新規登録の手間は、離脱率の向上につながります。特にメールアドレスや電話番号の所持確認での離脱が多いことが知られています。
この離脱を避けるために、未確認状態のまま登録を完了させるアプリもありますが、他人のメールアドレスや電話番号を利用した攻撃が存在するため、確認は必須にするべきです。
ソーシャルログインを採用した場合、多くのIdPでは、ユーザーの属性情報に所持確認結果を含んでいるため、それを信用すればアプリ側での確認をスキップできます。また、IdPから取得した属性情報をフォームの初期値として設定することで、ユーザー入力の手間の低減につながります。
ソーシャルログイン実装時の注意点
ここでは、ソーシャルログイン実装における、以下の3つの注意点について説明します。
- IdPごとに仕組みが微妙に異なる
- ソーシャルログインが使えなくなった場合のリカバリーの実装が必要
- ID管理の各種機能の実装が必要になる
IdPごとに仕組みが微妙に異なる
1つ目の注意点はIdPごとに仕組みが微妙に異なる点です。複数のIdPによるソーシャルログインを提供する場合、それぞれの仕様に合わせて実装する必要があります。
ソーシャルログインが使えなくなった場合のリカバリーの実装が必要
2つ目の注意点は、ソーシャルログインができなくなった場合のリカバリーの準備です。例えば、SNSユーザーが利用停止された場合はアプリへのソーシャルログインもできなくなります。そのような状況に備えてリカバリーが必要になるので、ソーシャルログインとは別にもう1つのユーザー認証を用意する必要があります。
ID管理の各種機能の実装が必要になる
最後の注意点はアイデンティティ管理機能の実装です。これはソーシャルログインに限った話ではなく、ユーザー登録が必要なアプリ全般にいえることです。ユーザー登録があるということは、ユーザーの属性情報をアプリで管理する必要があります。しかし、「ユーザーの属性情報管理」といわれても、どのような機能が必要なのか、どのように実装すればよいのかを意識したことがない人も多いのではないでしょうか。
これらの注意点をふまえたうえで、本書のもう1つの提案としてIDaaSの利用をおすすめします。
IDaaSとは
IDaaSとは「Identity as a Service」の略であり、「アイダース」「アイディーアース」と読みます。IDaaSは以下の機能を提供するクラウドサービスのことです。
- ユーザーのログイン機能
- ユーザーのID管理機能
- 外部サービスとのID連携機能
- ユーザーの権限や状態に応じたアクセス制御
IDaaSには大きく分けて2つの種類があります。1つは企業システム向け、もう1つはコンシューマーアプリ向けのIDaaSです。この2つは上記の機能を提供するという意味では共通しているものの、利用する目的とID連携における役割が異なります。
まず、企業システム向けのIDaaSと関連要素との関係を図1.8に示します。
このタイプのIDaaSを利用することで、業務で利用する複数のサービスにおいて、共通のユーザー識別子とパスワードの利用が可能になります。ID連携機能を利用する場合、IdPになるのはActive Directoryなどの社員ID管理サービスです。この場合、リライングパーティは各企業向けサービスであり、IDaaSはIdPと企業向けサービスを中継する役割を担います。なお、このタイプのIDaaSではセキュリティ監査に対応するために、アクセス履歴や管理者の作業履歴などのレポート機能を有するものが多く見られます。
次に、コンシューマーアプリ向けのIDaaSと関連要素との関係を図1.9に示します。
コンシューマーアプリに先ほどの1.から4.の機能を組み込むことがこのタイプのIDaaSの目的です。一般的に、IDaaSのSDKが提供されており、そのSDKを使って開発することで実装コストを格段に下げることができます。ID連携の関係に注目すると、IdPはSNSやウェブサービスなどの外部サービスになります。リライングパーティはコンシューマーアプリだともいえるし、IDaaSだともいえます。この関係については第3章で詳しく解説します。
以降、本書で「IDaaS」という言葉を使ったときはこちらの「コンシューマーアプリ向けのIDaaS」を指します。このタイプのIDaaSとしてはFirebase Authentication、Auth0、AWSCognito、Azure Active Directory BtoCなどがあります。1.から4.の機能を自分で実装するのではなく、このタイプのIDaaSにおまかせしよう、というのが本書の提案です。
IDaaSをおすすめする理由
先にソーシャルログイン実装時の注意点として以下の3つを挙げました。
- IdPごとに仕組みが微妙に異なる
- ソーシャルログインが使えなくなった場合のリカバリーの実装が必要
- ID管理の各種機能の実装が必要になる
これらはすべてIDaaSにおまかせすることで解決できます。
「IdPごとに仕組みが微妙に異なる」の解決
IDaaSを採用した場合、IdPと直接やり取りするのはアプリではなく、IDaaSになります。したがって、アプリ自身が各IdPの仕様に対応した実装を行う必要はありません。また、IdPの仕様変更があった際も、IDaaS側で対応できればアプリ側で追従する必要がありません。
「ソーシャルログインが使えなくなった場合のリカバリーの実装が必要」の解決
リカバリーのためには何らかのユーザー認証を用意する必要があります。IDaaSはソーシャルログイン以外にも、パスワード認証、メールやSMSを使った認証をサポートしており、開発者が利用したい認証方式を選択できます。それらの機能を利用すれば、アプリのセキュリティポリシーに応じた認証方式で比較的容易にリカバリーを実装できます。
また、1人のユーザーが複数のIdPとID連携する機能も備えています。そのため1つのIdPでのソーシャルログインが使えなくなっても、もう1つのIdPでログインできる状態を保てます。
「ID管理の各種機能の実装が必要になる」の解決
IDaaSはID管理機能も提供します。IDaaSを利用することで、ID管理機能の実装コストをおさえつつ、セキュアな実装が可能になります。ID管理機能の詳細は本書の第3章で解説します。
Firebaseとは
本書ではIDaaSの1つであるFirebase Authenticationを使って、サンプルアプリを作りながらソーシャルログインとID管理の各種機能について学んでいきます。
Firebaseはモバイルアプリ、Webアプリの開発プラットフォームであり、アプリケーションのバックエンドに必要な機能を提供するサービスであることからBackend as a service（BaaS）と呼ばれます。2011年にFirebase社がサービスを開始し、2014年にGoogle社が買収しました。現在はGoogle社のクラウドコンピューティングサービスであるGoogle Cloudと一部統合されて提供されています。
Firebaseの提供するサービス群の一部を図1.11に示します。また、図に示す以外にもさまざまなサービスがあり、全部で19個のサービスがあります。
Firebaseを使うことで、バックエンドに必要なサーバーやネットワークの構築と運用の必要がなくなります。さらに、バックエンドの開発も最小限におさえることができるので、開発者はモバイルアプリやウェブアプリの開発に専念できます。
Firebase Authentication とは
Firebase Authentication（ 以下、Firebase Auth） はFirebaseのサービスの1つであり、IDaaSとしての機能を提供します。ログインに関してはパスワードによるログイン、各種ソーシャルログイン、メールアドレス、電話番号を使ったログイン、既存のログインとの統合といったことが可能です。また、Firebase Authはアイデンティティ管理に必要な各種機能も提供します。Firebase Authにかかわる要素を図1.12に示します。
図の点線で囲まれた部分がFirebase Authであり、内部には3つの要素があります。1つはモバイルアプリやウェブアプリから呼び出すFirebase Auth API、もう1つがウェブのGUIをもつ管理画面であるFirebaseコンソール、そして最後の要素が、それらからリクエストを受けて動作するクラウド側のバックエンドです。
開発者はFirebase Authのバックエンドを意識することはありません。クライアントアプリのコードの中でFirebase Auth APIを利用して、ログイン機能、ID管理機能を実装していきます。Firebase コンソールはFirebaseサービス全体の設定画面です。Firebase Authに関する設定もここで行います。Firebase Authに関していうと、例えば、利用するログイン方式の有効化や、そのオプションの設定、メールの確認の際の送信元アドレスの設定、管理者としてユーザーの有効化、無効化、削除などが行えます。
図6にはその他に2つの要素があります。1つはFirebase UIです。Firebase UIはFirebase Authをもとに作成されたUIライブラリであり、あらかじめ決められた設定項目に値を入力していくだけで、ログインのUIおよびフローのベストプラクティスを実現できます。
もう1つの要素は、Admin Auth APIです。Admin Auth APIはバックエンドからFirebase Authの機能を利用するためのAPIです。Firebase Auth APIが操作できるユーザー情報は、ログインしたユーザー自身の情報に対してのみであるのに対して、Admin Auth APIはアプリの管理者権限で全ユーザーへの情報の操作が可能です。Admin Auth APIの詳細は第7章で解説します。
Firebase Authを選択した理由
本書ではサンプルアプリを作りつつ、ソーシャルログインとID管理機能の設計のポイントを学んでいきます。本書では以下の理由でFirebase Authを選択しました。
- 利用のハードルが低い
- 豊富なAPIで自由度が高い
- Firebase Auth 単体でも利用可能
理由①：利用のハードルが低い
Firebaseはトップ画面（https://firebase.google.com/）からGoogleアカウントでログインすることで使い始められます。利用に際して必要なものはGoogleアカウントのみです。入力時のフォーム入力やクレジットカードなど支払いに関する登録もなく、すぐに利用を開始できます。Firebaseの利用プランには無料で使えるSparkプランと従量課金制のBlazeプランがあります（https://firebase.google.com/pricing）が、Sparkプランでも十分な利用枠があるので、利用料の心配をする必要がありません。例えば、SparkプランにおけるFirebase Authの制限は「電話認証は月1万回まで」だけです。
また本書ではサンプルアプリの動作確認のためにFirebase Hostingも利用しますが、無料でストレージ容量10GB、転送量も1日あたり360MBまで利用できるため、サンプルアプリの動作確認には十分といえます。
理由②：豊富なAPIで自由度が高い
本書では、ログインとID管理の基本的な考え方をサンプルアプリを作りながら学ぶというスタイルを取っています。したがって、「自由度は低いが、いくつかの設定さえすればベストプラクティスが実現できる」という方針のIDaaSよりも、Firebase Authのように各種機能の豊富なAPIが提供されており、自由度の高いものが適していると考えました。
理由③：Firebase Auth単体での利用も可能
Firebaseの他のサービス、例えばCloud FirestoreやCloud Functions for Firebaseなどのサービスは使わず、Firebase Authだけをアプリに組み込むことが可能です。
すなわち、DBは別のサービスのRDBを使って、ユーザー認証はFirebase Authを使う、といったことが可能であり、読者が今後、アプリを作成する際にも採用しやすいと考えました。
