Firebase Auth：概要、認証方法、サインインプロバイダー

Firebase Authとは

Firebase Authは、Firebase SDKの一部として提供されるGoogleのバックエンド認証サービスです。パスワードハッシュの保存、JWTトークンの生成、OAuth 2.0およびOpenID Connectフローの処理など、サーバーサイドのアカウント管理ロジック全体を処理します。開発者は独自の認証サーバーをデプロイしたり、更新トークンを管理したり、検証プロトコルを実装したりする必要はありません — Firebaseがすべてを行います。

サービスアーキテクチャ

Firebase Authは、統合ユーザーストアを備えたフェデレーションアーキテクチャを使用します。各ユーザーは、サインインプロバイダーに依存しない一意の識別子（UID）を取得します。Googleとメールで登録すると、2つのリンクされたアカウント（プロバイダー）を持つ単一のユーザーが作成されます。Firebaseは追加のサーバーリクエストなしでクライアント側でアカウントリンクを自動的に処理します。

Firebase AuthのトークンはJWT（JSON Web Token）で、ペイロードにはUID、発行時間、有効期限、カスタムclaimsが含まれます。アクセストークンは1時間有効で、更新トークンは無制限です（ただし管理コンソールで取り消し可能）。SDKはFirebaseサービスへのHTTPリクエストのたびにトークンを自動的に更新します。Google（2026年）によると、Firebase Authは1日あたり5億回以上の認証を処理しています。

料金と制限

Firebase Authは、Sparkプラン（無料）とBlazeプラン（従量課金制）の両方で完全に無料です。唯一の制限は、Sparkでは1日あたり1万件の匿名認証です（Blazeでは無制限）。メール/電話およびOAuth認証に制限はありません。電話認証の場合、Sparkは月1万件の認証を提供し、Blazeは従量課金です（最初の1万件以降、認証1件あたり$0.01）。これにより、Firebase Authは市場で最も手頃なソリューションの1つとなっています。

Firebase Authの認証プロバイダー

Firebase Authは12の認証プロバイダーを標準でサポートしています。各プロバイダーは、所定のフローを持つ個別のIDサービスとして実装されています — 開発者はCredentialオブジェクトを作成してsignInWithCredentialに渡すだけです。Firebaseはユーザーが新規か既存かを自動的に判別し、メールが重複した場合はアカウントのリンクを提案します。

メールとパスワード

Email/Passwordは、Firebaseサーバーに保存されたパスワードハッシュ（bcrypt）を使用する基本的な認証方法です。登録、サインイン、メールによるパスワードリセット、メール確認をサポートしています。Firebaseは自動的にパスワードの強度をチェックし（最小6文字）、N回の失敗した試行後にサインインをブロックできます（ブルートフォース対策）。

ソーシャルプロバイダー

Google、Apple、Facebook、Twitter、Microsoft、Yahoo、GitHub — すべてのOAuth 2.0プロバイダーはFirebaseコンソールから5分で設定できます。各プロバイダーについて、プロバイダー自身のコンソールからClient IDとClient Secretを取得する必要があります。Apple Sign InはApp Storeアプリケーションに必須です（2020年からのAppleの要件）。Firebase AuthはJWT検証によるApple Sign Inフローを完全にサポートしています。

電話認証

Phone Authは、ユーザーの電話番号に送信されるSMSコードによる認証です。FirebaseはSilent APN（iOS）またはSMS Retriever API（Android）を使用して、キーボード入力を必要とせずにコードを自動的に読み取ります。Androidでは、SMS Retriever APIはGoogle Playサービスがインストールされたデバイスでのみ動作します。SMSが利用できない地域では、FirebaseはフォールバックとしてreCAPTCHA認証をサポートしています。電話認証は、電話番号のバインドが必要なアプリ（フードデリバリー、配車、銀行）にとって重要です。

AndroidへのFirebase Authの統合

AndroidへのFirebase Authの追加には、build.gradleにfirebase-auth-ktx依存関係を追加し、Firebase Appを初期化する必要があります（Google Servicesプラグインにより自動的に行われます）。その後、FirebaseAuthオブジェクトは静的メソッドgetInstance()を介して利用可能になります — アプリ全体でシングルトンです。追加の設定は必要ありません。

// build.gradle (app-level)
dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-auth-ktx")
    implementation("com.google.android.gms:play-services-auth:21.0.0")
}

メールによるユーザー登録

createUserWithEmailAndPasswordは登録の主要なメソッドです。メールとパスワードを受け取り、Firebase Authにユーザーを作成し、UIDを含むAuthResultオブジェクトを返します。このメールのユーザーがすでに存在する場合、FirebaseはERROR_EMAIL_ALREADY_IN_USEエラーを返します。登録が成功すると、SDKは自動的にトークンをSharedPreferencesに保存し、次回のアプリ起動時にsignInを呼び出さずにセッションを復元します。

class AuthViewModel {
    private val auth = FirebaseAuth.getInstance()

    suspend fun register(email: String, password: String): Result<User> {
        return try {
            val result = auth.createUserWithEmailAndPassword(email, password).await()
            Result.success(result.user?.toUser() ?: throw Exception("User is null"))
        } catch (e: FirebaseAuthException) {
            Result.failure(e)
        }
    }
}

Googleサインイン

Google Sign Inでは、2段階のプロセスが使用されます：Credential Manager（Android）またはGoogle Sign-In SDKを介してID Tokenを取得し、そのトークンをFirebase認証情報に渡します。Firebaseはサーバー側でトークンを検証し（GoogleのRSAキーで署名を確認）、既存のユーザーを作成または返します。このプロセスではクライアントに秘密情報を保存する必要はありません — すべての認証は暗号化トークン検証によって行われます。

ユーザー管理とセッション

Firebase Authはセッションのライフサイクルを自動的に管理します。サインイン後、SDKは更新トークンをローカルストレージに保存し、アプリが再起動されるたびにサイレントサインインを介してセッションを復元します。開発者はトークンストレージ、有効期限の処理、更新を実装する必要はありません — Firebase Auth SDKがすべてを行います。

現在のユーザー

FirebaseAuth.getInstance().currentUserは、セッションがアクティブな場合はFirebaseUserオブジェクトを返し、ユーザーがサインアウトした場合はnullを返します。FirebaseUserには、UID、メール、displayName、photoUrl、phoneNumber、providerData、およびclaimsのリストが含まれます。プロフィールの更新（updateProfile）後、変更は自動的にサーバーと同期されます。FirebaseUserオブジェクトはメモリにキャッシュされ、認証操作のたびに更新されます。

匿名認証

signInAnonymouslyは、登録なしで一時的なユーザーを作成します。匿名ユーザーにはUIDがありますが、メール、名前、プロバイダーはありません。これは、登録前にコンテンツが利用可能なアプリ（カート、お気に入り、履歴）に役立ちます。ユーザーが登録を決定すると、匿名アカウントはlinkWithCredentialを介して永続アカウントにリンクされます。Sparkプランでは、1日あたり1万件の匿名認証に制限があります。

Google（2026年）によると、約40%のユーザーが匿名でアプリの使用を開始し、そのうち25%が後で匿名アカウントを永続アカウントにリンクします。つまり、匿名認証はユーザーを登録ユーザーに変換する際にデータを失いません。

サインアウトとアカウント削除

signOut()メソッドはローカルセッションをクリアし、保存されたトークンを削除します。signOutを呼び出した後、currentUserはnullになります。delete()メソッドはFirebase Authからユーザーアカウントを完全に削除します — リンクされたすべてのプロバイダーが切断され、Firebaseサービスへのアクセスがブロックされます。ユーザー削除は元に戻せず、不正なアカウント削除から保護するために再認証が必要です。

カスタムClaimsとロール管理

Custom Claimsは、Firebase AuthがユーザーのJWTトークンに追加するカスタム属性です。標準のプロフィールフィールド（メール、displayName）とは異なり、claimsはサーバー側でのみ利用可能です — Admin SDKを介して、またはFirestoreおよびRealtime DatabaseのFirebase Security Rulesのルールを通じて。claimsはクライアントから直接見えませんが、user.getIdTokenResult()を介して読み取ることができます。

典型的なユースケース

ロールとアクセス権は、claimsの最も一般的なユースケースです。Admin SDKを使用すると、サーバー上のマップを介して「admin」「moderator」「premium_user」のロールを割り当てることができます。これらのclaimsは自動的にトークンに含まれ、アクセス制御のためにFirestore Security Rulesで使用できます。Google（2026年）によると、Firebaseプロジェクトの65%は、個別のロールサーバーの代わりにカスタムclaimsをデータアクセス管理に使用しています。

// Admin SDK (Node.js) — ユーザーへのclaims割り当て
const admin = require("firebase-admin")

await admin.auth().setCustomUserClaims(uid, {
    role: "premium",
    tier: "pro",
    maxProjects: 50
})

// クライアントでのclaimsの読み取り
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Claimsの制限

カスタムclaimsには制限があります：ユーザーあたりのclaims JSONオブジェクト全体で最大1000バイト、オブジェクト内のキーは20個までです。claimsは動的データの保存用には設計されていません — Admin SDKを介してのみ更新され、リアルタイムでは同期されません。claimsを更新した後、ユーザーはトークンを更新する（getIdTokenResult(true)）か、アプリに再ログインする必要があります。claimsはクライアントにキャッシュされません — 新しいログインのたびにサーバーから最新のトークンを取得します。

認証セキュリティ

Firebase Authは多層的なアカウント保護を実装しています：トラフィック暗号化（TLS 1.3）、パスワードハッシュ化（bcrypt、コスト10）、Adaptive Pricingによるブルートフォース対策（不審なアクティビティ時の自動応答遅延）、およびウェブサインインのためのreCAPTCHA統合。さらに、Firebase Authは不審なアクティビティ（異なるIPからの大量ログイン、誤ったパスワードでのログイン試行、不審なメールアドレス）があった場合にアカウントを無効化します。

保護方法

Account Lockout — 一定回数のログイン失敗後、自動的にアカウントをロックします。しきい値はFirebaseコンソールで設定可能です（デフォルトは10回）。Email Enumeration Protection — メールアドレスの列挙に対する保護。有効にすると、Firebaseは既存のメールと存在しないメールの両方に対して同じエラーを返します。Trusted Domains — 設定で指定されたメールドメインを持つユーザーのみにサインインを制限します。

カスタムトークンのセキュリティ

追加のカスタム認証は、Firebaseサービスアカウントによって署名されたJWTであるカスタムトークンを使用して構築できます。クライアントはカスタムトークンをsignInWithCustomToken()に渡し、Firebaseが署名を検証してセッションを作成します。これにより、ユーザーデータベースを複製することなく、Firebase Authを既存のサーバーサイド認証（独自のOAuth 2.0サーバーなど）と統合できます。トークンは1時間有効で、その後SDKはFirebase更新トークンを介して自動的にセッションを更新します。