Google Sign-Inとは：GoogleログインとOAuth 2.0 SDK

Google Sign-Inとは

Google Sign-Inは、サードパーティアプリケーションでのユーザー認証のためにGoogleが提供するシングルサインオン（SSO）サービスです。SDKにより、開発者は独自の登録システムを作成せずにGoogleアカウントによるログインを統合できます。この技術はOAuth 2.0プロトコルとOpenID Connectに基づいており、ユーザーの名前、メール、アバター、一意のIDなどの識別情報を提供します。

従来のメールとパスワードによる認証とは異なり、Google Sign-Inはパスワードを覚えたり登録手続きを行う必要がありません。ユーザーはデバイスでGoogleアカウントを選択し、権限を確認すると、アプリがアクセストークンを受け取ります。Google Identity Platform（2025年）によると、Google Sign-Inを導入したアプリは、メール/パスワード形式と比較して52%多くの登録成功数を示しています。

Google Sign-Inは3つの使用シナリオをサポートしています：ユーザー認証（ID Tokenの取得）、Google APIへのアクセス承認（Access Tokenの取得）、および既に認可されたユーザーのためのシームレスな認証（Silent Sign-In）です。各シナリオには異なるスコープセットが必要で、異なるタイプのトークンが返されます。

Google Sign-InにおけるOAuth 2.0の仕組み

OAuth 2.0は、アプリがユーザーの資格情報を開示せずにユーザーリソースへの制限付きアクセスを取得できるようにする認可プロトコルです。Google Sign-Inのコンテキストでは、プロトコルは次のように機能します：アプリはGoogleを通じてユーザーに認可を要求し、一時的な認可コードを受け取り、それをアクセストークンと交換し、そのトークンを使用してGoogle APIを呼び出します。

OAuth 2.0の以前のプロトコルとの主な違いは、リソース所有者（ユーザー）、クライアント（アプリ）、認可サーバー（Google）、リソースサーバー（Google API）間の役割の分離です。アプリはユーザーのパスワードを決して受け取らず — 取り消し可能なトークンのみを受け取ります。Google Identity PlatformはOAuth 2.0の上でOpenID Connect仕様を使用し、JWT形式の標準化されたID Tokenを追加します。

ID TokenとAccess Tokenの違い

// Credential Manager経由でID Tokenを取得する例
val googleIdOption = GoogleIdCredentialOption.Builder()
    .setServerClientId(serverClientId)
    .build()

val credentialManager = CredentialManager.create(this)
val request = GetCredentialRequest.Builder()
    .addCredentialOption(googleIdOption)
    .build()

credentialManager.getCredential(request)
    .addOnSuccessListener { result ->
        val credential = result.credential as GoogleIdCredential
        Log.d("SignIn", credential.idToken)
    }

ID Token（JWT）には3つのセグメントがあります：署名アルゴリズムを含むヘッダー、ユーザーデータ（sub、email、name、picture）を含むペイロード、および検証用の署名です。アプリのサーバー側はGoogleの公開鍵を使用してID Tokenの署名を検証し、ユーザー識別子を抽出します。このアプローチにより、クライアントアプリが侵害された場合でも、攻撃者はGoogleの秘密鍵にアクセスできなければトークンを偽造できないことが保証されます。

Credential Manager：Androidの新しいログイン方法

Credential Managerは2023年に導入された最新のAndroid APIで、すべての認証方法（Google Sign-In、パスワードログイン、Passkeys）を単一のユーザーインターフェースに統合します。古いGoogleSignInClientとは異なり、Credential ManagerはログインにWebViewを必要とせず — ネイティブのBottom Sheetを使用するため、認証が高速化され、ユーザーエクスペリエンスが向上します。

Credential Managerの主な利点は、すべての資格情報タイプに対する統一されたUXです。ユーザーは1つのダイアログで、Googleでログイン、Passkeyの使用、パスワードの入力から選択できます。開発者は異なる認証フローを管理する必要がなく — Credential ManagerがGoogle Sign-In、Smart Lock、Passkeysとのやり取りを抽象化します。GoogleはAndroid 14+向けのGoogle Sign-In統合の主要な方法としてCredential Managerを推奨しています。

GoogleSignInClientからCredential Managerへの移行

移行 GoogleSignInClientからCredential Managerへの移行には、クライアント側のロジックの変更が必要です：GoogleSignInOptionsの代わりにGoogleIdCredentialOptionを使用し、GoogleSignIn.getSignedInAccountFromIntentの代わりにGetCredentialResponseを通じて結果を処理します。ID Tokenは同じJWT形式を維持するため、サーバー側の変更は必要ありません。Google I/O 2024によると、Google Play上のアプリの約40%がすでにCredential Managerに移行しています。

AndroidプロジェクトでのGoogle Sign-In設定

Google Sign-InをAndroidアプリに統合するには、Google Cloud Consoleでプロジェクトを設定することから始めます。最初のステップは、Android用のOAuth 2.0 Client IDを作成することです：アプリのパッケージ名とSHA-1証明書フィンガープリントを指定します。Googleはこのデータを使用して、認証リクエストが偽のクライアントではなくあなたのアプリから来ていることを検証します。

Google Cloud Consoleでクライアントを作成した後、開発者はbuild.gradleにCredential Managerの依存関係を追加し、serverClientIdでGoogleIdCredentialOptionを構成します。重要：serverClientIdは同じGoogle CloudプロジェクトのウェブアプリケーションのClient IDであり、サーバー側がID Tokenを検証するために使用します。クライアントアプリはトークンを検証せず — 受信してサーバーに転送するだけです。

// build.gradle (app) dependencies
implementation("androidx.credentials:credentials:1.5.0")
implementation("androidx.credentials:credentials-play-services-auth:1.5.0")
implementation("com.google.android.libraries.identity.googleid:googleid:1.1.0")

// Credential Manager経由でGoogle Sign-Inをリクエスト
suspend fun requestGoogleSignIn(context: Context): String? {
    val credentialManager = CredentialManager.create(context)
    val googleIdOption = GoogleIdCredentialOption.Builder()
        .setServerClientId(BuildConfig.SERVER_CLIENT_ID)
        .setAutoSelectEnabled(true)
        .build()

    val result = credentialManager.getCredential(
        context as Activity,
        GetCredentialRequest.Builder()
            .addCredentialOption(googleIdOption)
            .build()
    )
    return (result.credential as GoogleIdCredential).idToken
}

クライアントでID Tokenを受信した後、アプリはそれをサーバーに送信し、そこで検証が実行されます。サーバーはGoogleの公開鍵（https://www.googleapis.com/oauth2/v3/certsで利用可能）、トークンの有効期限（exp）、およびaudフィールドの値を使用してJWT署名を検証します — serverClientIdと一致する必要があります。検証後、サーバーは独自のセッションを作成し、例えば内部JWTまたはSession Tokenを発行します。

iOSでのGoogle Sign-In：設定と特徴

iOSでのGoogle Sign-Inの統合は、CocoaPodsまたはSwift Package Managerを介して利用可能なGoogleSignIn-iOS SDKを通じて行われます。設定プロセスには、Google Cloud ConsoleでiOS用のClient IDを作成し（Bundle Identifierを指定）、コールバック用のURL Schemeを追加し、認証後にGoogleから返されるURLを処理するためのAppDelegateの設定が含まれます。

Google Sign-InのiOSバージョンのAndroidとの重要な違いは、URL SchemeとInfo.plistを設定する必要があることです。GoogleSDKはコールバックにUniversal Linksを使用しますが、フォールバックとして`com.googleusercontent.apps.[CLIENT_ID]`形式のURL Schemeが必要です。アプリの起動間でリフレッシュトークンを保存するために、Keychain Sharingの設定も必要です。Google Identityのドキュメントによると、iOS SDKはiOS 15以上をサポートしています。

// iOSでのGoogle Sign-In設定
import GoogleSignIn

class SignInManager: ObservableObject {
    func signIn(presenting viewController: UIViewController) {
        GIDSignIn.sharedInstance.signIn(
            withPresenting: viewController
        ) { signInResult, error in
            guard let result = signInResult else {
                print("Sign in failed: \(error)")
                return
            }
            let idToken = result.user.idToken.tokenString
            // ID Tokenをサーバーに送信
            sendTokenToBackend(idToken)
        }
    }
}

iOSでは、Google Sign-Inは以前に認可したユーザーに対してSilent Sign-Inをサポートしています。restorePreviousSignInメソッドは、リフレッシュトークンがKeychainに保存されている場合、自動的にセッションを復元します。これは、ユーザーが起動のたびに再ログインする必要がないアプリにとって特に重要です。Googleによると、アクティブなGoogleセッションがあるデバイスでは、Silent Sign-Inが85%のケースで成功します。

トークン管理とセキュリティ

Google Sign-Inのセキュリティは3つのレベルで構築されています：クライアント検証（SHA-1アプリ署名）、トランスポート暗号化（HTTPS/TLS）、および暗号化JWT署名です。Googleから受け取ったID Tokenは、RS256アルゴリズム（SHA-256を使用したRSA）で署名されています。アプリのサーバー側は、トークンの署名、有効期限、および発行者（iss）— accounts.google.comのみ — を検証する必要があります。

Access Tokenは一時的なトークン（有効期間1時間）で、Google API（Google Drive、Google Calendar、YouTubeなど）へのアクセスを提供します。ID Tokenとは異なり、Access Tokenにはユーザー情報は含まれず — Google APIサーバーがリクエストの認可に使用する不透明な文字列です。Refresh Tokenは長期有効なトークンで、ユーザーが再ログインすることなく新しいAccess Tokenを取得できます。Refresh Tokenは最初のログイン時のみ発行され、ユーザーはGoogleアカウント設定で取り消すことができます。

// サーバーでのID Token処理例（疑似コード）
fun verifyGoogleToken(idToken: String): User? {
    val verifier = GoogleIdTokenVerifier.Builder(
        NetHttpTransport(), GsonFactory.getDefaultInstance()
    ).setAudience(listOf(CLIENT_ID))
     .build()

    val token = verifier.verify(idToken) ?: return null
    val payload = token.payload

    return User(
        id = payload.subject,
        email = payload.email,
        name = payload.get("name") as String
    )
}

Refresh Tokenとセッション管理

セキュリティ推奨事項：ID Tokenを安全でないチャネルで送信しないでください。すべてのサーバーリクエストにHTTPSを使用し、トークンの有効期限（expフィールド）と発行者（iss）を確認してください。クライアント側では、暗号化なしでSharedPreferencesにトークンを保存しないでください — EncryptedSharedPreferencesまたはAndroid Keystoreを使用してください。Google Sign-Inはサーバー間認証を目的としておらず — その場合はService Accountsを使用してください。

コード例：KotlinでのGoogle Sign-In統合

Credential ManagerとViewModelを使用したAndroidアプリへのGoogle Sign-In統合の完全な例。アプリはサインインボタンを表示し、認証後にID Tokenをサーバーに送信し、ユーザー情報を表示します。コードはCredential Managerとの非同期処理にコルーチンを使用しています。

class SignInViewModel: ViewModel() {
    private val cm = CredentialManager.create(getApplication())

    private val googleOption = GoogleIdCredentialOption.Builder()
        .setServerClientId(BuildConfig.SERVER_CLIENT_ID)
        .build()

    suspend fun signIn(): SignInResult {
        return try {
            val response = cm.getCredential(
                GetCredentialRequest.Builder()
                    .addCredentialOption(googleOption)
                    .build()
            )
            val credential = response.credential as GoogleIdCredential
            SignInResult.Success(credential.idToken)
        } catch (e: GetCredentialCancellationException) {
            SignInResult.Cancelled
        }
    }
}

sealed class SignInResult {
    data class Success(val idToken: String) : SignInResult()
    data class Error(val message: String) : SignInResult()
    data class Cancelled : SignInResult()
}

認証が成功した後、アプリは検証とセッション作成のためにID Tokenをサーバーに送信する必要があります。HTTPSを使用し、POSTリクエストの本文にトークンを含めることを推奨します。サーバーは独自のセッショントークンを返し、クライアントはそれをEncryptedSharedPreferencesに保存します。サーバーへの後続のリクエストごとに、Google ID Tokenではなく内部トークンが使用されます。

よくある統合エラーとその解決策

最初のよくあるエラーはSHA-1証明書の不一致です。Google Cloud ConsoleはOAuth 2.0 Client IDをSHA-1証明書フィンガープリントにバインドします。アプリがデバッグキーでビルドされているが、Client IDがリリースキー用に作成された場合、Google Sign-Inはエラー12501（SIGN_IN_FAILED）を返します。解決策：Google Cloud Consoleに両方のSHA-1フィンガープリント（デバッグとリリース）を追加するか、開発用と本番用に別々のClient IDを使用します。

2番目に頻繁な問題は、serverClientIdの誤りです。開発者はしばしば、Credential ManagerのserverClientIdパラメーターにウェブアプリケーションのClient IDの代わりにAndroidのClient IDを使用します。Googleはサーバー検証用のID Tokenを生成するために、ウェブクライアントIDを正確に要求します。Android Client IDは認証中にアプリを識別するためだけに使用されます。serverClientIdがGoogle Cloud Consoleのウェブアプリケーションと一致することを確認してください。

3つ目のエラーはキャンセル処理の無視です。ユーザーは認証を完了せずにGoogle Sign-Inダイアログを閉じる可能性があります。Credential ManagerはGetCredentialCancellationExceptionをスローし、これは他のエラーとは別に処理する必要があります。多くの開発者はすべての例外をエラーとして処理し、ユーザーが単に操作をキャンセルしただけなのに “ログインに失敗しました” というメッセージを表示します。正しい処理：キャンセル時 — 何も表示せず、初期状態に戻ります。