FirebaseUIでログイン機能を簡単実装!
FirebaseUI でログイン機能を簡単実装!
前回は、Google のユーザー認証を Firebase で利用する具体的な例を紹介しました。 Firebase は他にも大手のサービスのユーザー認証を利用して、あなたのサービスのユーザー認証機能(ログイン)機能に組み込める仕組みを提供しています。 この記事では、大手サービスのユーザー認証に加えて、FirebaseUI についても前回の記事より詳しく解説します。
目次 |
---|
FirebaseUI で開発時間の大幅短縮 |
利用できる大手のサービス |
大手のサービスの選び方 |
コードサンプル |
まとめ |
FirebaseUI で開発時間の大幅短縮!
前回の記事でも紹介していますが、Firebase はユーザー認証で簡単に利用できる UI(ユーザーインターフェース)を予め準備して提供しています。ユーザー認証機能(ログイン機能)の実装も自分でゼロから作ると面倒ですが、UI もゼロから作ると意外に時間がかかる物です。
この、予め用意された UI である「FirebaseUI」を利用すると、ユーザー認証(ログイン機能)の部分の実装は殆ど何もしなくても、あなたの Web サービスに組み込む事ができます。しかも、大手のサービスのロゴなどが含まれていて、他のサービスでよく見かけるイメージでの UI なので利用者にもわかりやすい UI の実現ができます。
特に特別な UI が必要でない場合、Firebase が予め用意している FirebaseUI を利用すれば、業界標準のログイン機能を開発時間「ゼロ」で実現できます。
利用できる大手のサービス
以前にも紹介していますが、Firebase のユーザー認証に利用できる大手のサービス(以下サービスプロバイダ)は、たくさんあります。インターネットのサービスを利用している場合、ほとんどの場合は、いずれかのアカウントを持っていると考えても問題はないと思います。
2021 年 3 月現在サポートしているユーザー認証は以下の通りです:
- E-Mail とパスワード(Firebase で管理)
- 電話番号
- Yahoo
- Microsoft
- Apple
- GitHub
- Play Games
- Game Center
です。Web のメールの利用者ならば、ほぼどれかのアカウントを持っていると思いますし、ソフトウエアなどの開発者であれば、GitHub などにもアカウントを持っていることを考えるとほぼカバーされていると言えます。
ただ、SNS などに関しては、Facebook と Twitter のみなので、場合によってはカバーできない場合もあるかと思います。
大手のサービスの選び方
Firebase はたくさんのサービスプロバイダをサポートしていますが、実際にあなたのサービスに組み込む場合は、利用するサービスプロバイダを絞った方が効果的です。
サービスプロバイダを選ぶ際のポイントはあなたのサービスの対象となる人を考える必要があります。例えば、最近のインターネットの利用はスマホやタブレットが中心になっているので、PC を利用しない利用者も増えています。そうした利用者の場合、E-Mail 自体を殆ど利用しないというのも最近では普通になっています。そのような場合は、「電話番号」の選択肢を入れておいた方が有利になる場合が多くなります。
あくまで、経験的な話ですが、例えば Microsoft のアカウントは、Windows の PC を利用する人は持っている可能性が高いですが、スマホやタブレット中心の利用者の場合、持っていないか、持っていても殆ど利用しない場合が多いように見えます。このようなユーザーを対象とした場合は、Microsoft でのユーザー認証は利用者にはあまりメリットがありません。一方で、Apple の iPhone や iPad を利用する人は必ず、Apple ID を持っています。
こうした事を考慮すると、利用するユーザー認証の方法を 3〜4 を上限に選んだ方が効果的な場合が多いようです。多すぎると、利用者が選択に困ってしまう場合も多いようなので、よくあるパターンとしては以下のような感じです。
- 誰でも利用できる方法(E-Mail アドレスや電話番号)
- Google や Yahoo!(所有者が多い)
- Facebook・Twitter(SNS の中では利用者が多い)
あとは、利用者がゲーマーならばゲーム関連のプロバイダー、開発者ならば GitHub を入れるなどという感じで選ぶと効果的です。
コードサンプル
実際の実装例は、前回に紹介した Google を利用した場合とほぼ同じです。
利用に際しては、幾つかの外部パッケージ(モジュール)の設定が必要です。
- CDN (Contents Delivery Network)
- npm
これも前回、取り上げていますが、ユーザー認証(ログイン)を利用するアプリやサービスはある程度の規模の物が多いため、React や Vue と言ったフロントエンドのフレームワークと併用して利用する場合が多いと思います。HTML ファイルから CDN(Contents Delivery Network)のリンクを呼び出して利用するの方法は手軽で便利ですが、この記事では npm を利用して組み込む方法を紹介します。
Firebase と FirebaseUI
前回は、一部省略しましたがご質問も多かったので改めて省略せずに紹介します。
FirebaseUI を利用すると、以下のような UI のボタンが表示されて、ボタンをクリックすると指定したサービスプロバイダを利用してログイン処理を行ってくれます。プログラムを書くというより、必要なモジュールの設定をして呼び出すという感じで実装できます。
まずは、Firebase と FirebaseUI をインストールします
$ npm install firebase firebaseui
次に、Firebase のプロジェクトを作成して、アプリを登録します。こちらは、Firebase のコンソールで行います。プロジェクトを作成したら、Authentication の設定で、利用するログインプロバイダを有効にします。(有効にしないで、そのプロバイダのユーザー認証を利用するとエラーになります。)
React や Vue などから Firebase を利用する場合は、このように Firebase のモジュール(パッケージ)をインストールした後に利用する Firebase のプロジェクト情報を基に初期化を行います。
よく行われる方法が、「firebase.ts」というファイルを用意して初期化します 以下は、仮のプロジェクト情報での初期化の例です。Firebase で作成したプロジェクトと登録したアプリの情報を基に以下の「firebaseConfig」の部分を置き換えて利用できます。
import firebase from "firebase/app";
import "firebase/auth";
import "firebase/firestore";
import "firebase/storage";
// Your web app's Firebase configuration
const firebaseConfig = {
apiKey: "AIzaSyA1J409Az5CwW6HKj2Rn_8noHRfS_xTnJc",
authDomain: "temp-374a3.firebaseapp.com",
projectId: "temp-374a3",
storageBucket: "temp-374a3.appspot.com",
messagingSenderId: "657624936524",
appId: "1:657624936524:web:93016b457f7532f07a04e9",
};
// Initialize Firebase
firebase.initializeApp(firebaseConfig);
export default firebase;
あとは、実際のログインの設定を記述しますが、サービスプロバイダによって設定が若干異なります。例えば、Facebook を利用してユーザー認証を行う場合には、Facebook の開発者として登録して、アプリの ID とアプリシークレットが必要になります。Twitter もほぼ同様で、Twitter の開発者として登録して、API キーと API シークレットを取得する必要があります。どちらも、サービスプロバイダ(Facebook や Twitter)の開発サイト側での設定も必要になります。
Apple を利用する場合は、さらに複雑で AppleID の認証の際、二段階認証が有効になっていて、Apple のデバイスで iCloud でログインしている必要があります。さらに、Apple の開発者として登録を行って、Firebase プロジェクトのログインプロバイダとして Apple を有効にするなど必要な設定が増えます。Apple の設定の詳細は、Firebase のドキュメントに詳しく書かれています。 (設定が面倒なので利用した事がありませんのでここでは紹介のみにしています)
この外部のサービスプロバイダを利用した認証は、基本的に「OAuth」という認証の仕組み(RFC6749 という標準仕様)に基づいて行われます。これは、セキュリティ上、認証を行ったサービスプロバイダがどこまでのアクセスの権限を渡すかということを決める仕組みです。簡単に言えば、予めどの情報を渡すか利用者の許可を得た上で渡すという仕組みです。標準設定では、最低限の情報のみ(氏名や E-Mail アドレスなど)ですが、要求して、利用者が許可すればそれ以上の情報も取得できます。
Firebase ではこうした、「エクストラの情報」はオプションになっていて、特に要求しなければ最低限のログインに必要な情報だけを取得するようになっています。サービスプロバイダは許可された情報にアクセスするためのアクセストークン(カギのようなもの)を Firebase に渡す仕組みになっています。
利用者に安心して利用してもらうためには、必要以上の情報のアクセスをしないことが大切です。インターネットのサービスを利用する際に、アカウントとパスワードの管理の手間を少なくするために、Google 認証を利用する場合が私の場合たくさんあります。しかし、サービスによっては、GMail、Google ドライブなどほぼ、全てのアクセスを要求する場合も多く Google 認証を諦めるケースもよくあるからです。
ログインのページの例です。
import * as firebaseui from "firebaseui";
import firebase from "../lib/firebase";
import * as React from "react";
import "firebaseui/dist/firebaseui.css";
class Login extends React.Component {
componentDidMount() {
const uiConfig = {
signInSuccessUrl: "/material",
signInOptions: [
firebase.auth.EmailAuthProvider.PROVIDER_ID,
firebase.auth.PhoneAuthProvider.PROVIDER_ID,
firebase.auth.GoogleAuthProvider.PROVIDER_ID,
firebase.auth.FacebookAuthProvider.PROVIDER_ID,
firebase.auth.TwitterAuthProvider.PROVIDER_ID,
],
credentialHelper: firebaseui.auth.CredentialHelper.GOOGLE_YOLO,
};
let ui = firebaseui.auth.AuthUI.getInstance();
if (ui) {
ui.start("#firebaseui-auth-container", uiConfig);
} else {
ui = new firebaseui.auth.AuthUI(firebase.auth());
ui.start("#firebaseui-auth-container", uiConfig);
}
}
render() {
return (
<React.Fragment>
<div id="firebaseui-auth-container"></div>
</React.Fragment>
);
}
}
export default Login;
Facebook や Twitter の認証の場合、上で書いた通り、それぞれ開発者としての登録を行って、アプリの ID の取得やトークン(アクセスのためのカギのような物)を取得して、利用するアプリの登録などが必要になります。その設定があれば、Web アプリ側の設定はほぼ同じようにできます。
Apple はセキュリティを特に重要視している会社なので、設定は他のサービスプロバイダーより複雑です。
credentialHelper: firebaseui.auth.CredentialHelper.GOOGLE_YOLO,
という記述がありますが、これは、必要なユーザー認証の処理やセッションの管理を行ってくれるもので、有効にするとコードをシンプルにできます。無効にしてセッションの管理を自分で記述することもできます。
まとめ
前回の記事で、予想以上に質問を頂いたので、Firebase のユーザー認証についてもう少し詳しい記事を書きました。
Firebase のユーザー認証で Google や Facebook といった外部のサービスを利用してユーザー認証を行う場合、「OAuth」という標準的な仕組みによって、認証を行う外部のサービスプロバイダからログイン情報を提供してもらいます。
通常取得する情報は、認証結果と、E-Mail アドレスや名前などですが、この仕組み上は利用者の許可があれば、それ以上の情報も入手は可能です。その場合、入手可能な情報は初回のログイン時に利用者の許可を求める仕組みになっています。
利用者はこの仕組みには余り詳しくない場合が多く、アカウントの情報やパスワードそのものが共有されると思われる方も少なくありません。このため、Google のログインを提供しても利用されない方も多くなっています。したがって、外部のサービスプロバイダのユーザー認証を提供する場合でも、必要以上の情報を要求しないことは重要かと思います。
さらに、どんな情報を取得しているのか丁寧に説明するだけでも利用者の印象は大きく変わリます。上手く、こうした機能を利用することで開発者、利用者共に便利なサービスが実現できます。