アプリでは、メールアドレスとパスワード、フェデレーション ID プロバイダ、カスタム認証システムなど、複数の方法でユーザーのログインを行うことができます。また、ユーザーには複数のログイン方法を関連付けることができます。たとえば、ユーザーがメールアドレスとパスワード、または Google ログインを使って同じアカウントにログインするといったことができます。
ユーザーがアプリにログインすると、Identity Platform によって作成されます。これらのトークンは、 Google Cloudプロジェクトのユーザーを安全に識別する署名済みの JWT です。このトークンには、 Google Cloudプロジェクト内で一意のユーザー ID 文字列など、ユーザーの基本的なプロフィール情報が格納されています。ID トークンの整合性は検証可能なため、ID トークンをバックエンド サーバーに送信して、現在ログインしているユーザーを識別できます。
ID プロバイダ トークン
Google や Facebook などのフェデレーション ID プロバイダによって作成されます。
形式が異なることもありますが、多くは OAuth 2.0 アクセス トークンです。アプリはこれらのトークンを使用して、ユーザーが ID プロバイダによって正常に認証されたかどうかを確認し、Identity Platform サービスで使用可能な認証情報に変換します。
Identity Platform のカスタム トークン
ユーザーが認証システムを使用してアプリにログインできるようにするため、カスタム認証システムによって作成されます。カスタム トークンは、サービス アカウントの秘密鍵を使って署名された JWT です。アプリは、フェデレーション ID プロバイダから返されたトークンと同じように Firebase カスタム トークンを使用します。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eIdentity Platform's user object represents a user account in a Google Cloud project, and each project shares a user database across all its apps.\u003c/p\u003e\n"],["\u003cp\u003eUser objects have fixed properties like a unique ID, email, name, and photo URL, which can be updated by the user, and additional properties can be stored in external services.\u003c/p\u003e\n"],["\u003cp\u003eUsers can sign in using various methods, including email and password, federated identity providers, or a custom auth system, and can associate multiple sign-in methods with a single account.\u003c/p\u003e\n"],["\u003cp\u003eIdentity Platform manages the current user's state, persisting it across page refreshes or app restarts, but this state is cleared upon sign-out, although the user instance remains functional.\u003c/p\u003e\n"],["\u003cp\u003eIdentity Platform distinguishes between trusted and untrusted identity providers for email verification and automatically links user accounts when users sign in with different trusted providers using the same email, while requiring manual linking for untrusted provider combinations.\u003c/p\u003e\n"]]],[],null,["# Identity Platform users in projects\n===================================\n\nThe Identity Platform **user** object represents a user account that has signed\nup for an app in your\nGoogle Cloud\nproject. Apps usually have many registered users, and every app in a\nGoogle Cloud\nproject shares a user database.\n\nUser instances are independent from Identity Platform instances, so you can have\nseveral references to different users within the same context and still call any\nof their methods.\n\nUser properties\n---------------\n\nIdentity Platform users have a fixed set of basic properties---a unique\nID, a primary email address, a name and a photo URL---stored in the\nproject's user database, that can be updated by the user\n([iOS](https://firebase.google.com/docs/auth/ios/manage-users#update_a_users_profile),\n[Android](https://firebase.google.com/docs/auth/android/manage-users#update_a_users_profile),\n[web](https://firebase.google.com/docs/auth/web/manage-users#update_a_users_profile)).\nYou cannot add other properties to the user object directly; instead, you can\nstore the additional properties in any other storage services, like Google Cloud\nFirestore.\n\nThe first time a user signs up to your app, the user's profile data is populated\nusing the available information:\n\n- If the user signed up with an email address and password, only the primary email address property is populated\n- If the user signed up with a federated identity provider, such as Google or Facebook, the account information made available by the provider is used to populate the user's profile\n- If the user signed up with your custom auth system, you must explicitly add the information you want to the user's profile\n\nOnce a user account has been created, you can reload the user's information to\nincorporate any changes the user might have made on another device.\n\nSign-in providers\n-----------------\n\nYou can sign in users to your apps using several methods:\nemail address and password, federated identity providers, and your custom auth\nsystem. You can associate more than one sign-in method with a user: for example,\na user can sign in to the same account using an email address and a password, or\nusing Google Sign-In.\n\nUser instances keep track of every provider linked to the user. This allows you\nto update empty profile's properties using the information given by a provider.\nSee Managing Users\n([iOS](https://firebase.google.com/docs/auth/ios/manage-users#get_a_users_provider-specific_profile_information),\n[Android](https://firebase.google.com/docs/auth/android/manage-users#get_a_users_provider-specific_profile_information),\n[web](https://firebase.google.com/docs/auth/web/manage-users#get_a_users_provider-specific_profile_information)).\n\nThe current user\n----------------\n\nWhen a user signs up or signs in, that user becomes the current user of the\nAuth instance. The instance persists the user's state, so that refreshing the\npage (in a browser) or restarting the application doesn't lose the user's\ninformation.\n\nWhen the user signs out, the Auth instance stops keeping a reference to the user\nobject and no longer persists its state; there is no current user. However, the\nuser instance continues to be completely functional: if you keep a reference to\nit, you can still access and update the user's data.\n\nThe user lifecycle\n------------------\n\nThe recommended way to track the current state of the Auth instance is by using\nlisteners (also called \"observers\" in JavaScript). An Auth listener gets\nnotified any time something relevant happens to the Auth object. See Managing\nUsers\n([iOS](https://firebase.google.com/docs/auth/ios/manage-users#get_the_currently_signed-in_user),\n[Android](https://firebase.google.com/docs/auth/android/manage-users#get_the_currently_signed-in_user),\n[web](https://firebase.google.com/docs/auth/web/manage-users#get_the_currently_signed-in_user)).\n\nAn Auth listener gets notified in the following situations:\n\n- The Auth object finishes initializing and a user was already signed in from a previous session, or has been redirected from an identity provider's sign-in flow\n- A user signs in (the current user is set)\n- A user signs out (the current user becomes null)\n- The current user's access token is refreshed. This case can happen in the following conditions:\n - The access token expires: this is a common situation. The refresh token is used to get a new valid set of tokens.\n - The user changes their password: Identity Platform issues new access and refresh tokens and renders the old tokens expired. This automatically expires the user's token and/or signs out the user on every device, for security reasons.\n - The user re-authenticates: some actions require that the user's credentials are recently issued; such actions include deleting an account, setting a primary email address, and changing a password. Instead of signing out the user and then signing in the user again, get new credentials from the user, and pass the new credentials to the reauthenticate method of the user object.\n\nUser self-service\n-----------------\n\nBy default, Identity Platform enables users to sign-up and delete their accounts\nwithout administrative intervention. In many circumstances, this enables\nend-users to discover your application or service and onboard (or offboard) with\nminimal friction.\n\nThere are situations, however, where you want users to be manually or\nprogrammatically created by an administrator, either using the Admin SDK or\nGoogle Cloud console. In these cases, you can disable user actions from the\nIdentity Platform settings page, which prevents account creation and deletion by\nan end-user. If you use multi-tenancy, you need to make an HTTP request\n[to disable](/identity-platform/docs/reference/rest/v2/projects.tenants/patch)\nthese features on a per-tenant basis.\n\nIf an end-user attempts to create or delete an account within your system, the\nIdentity Platform service will return an error code:\n`auth/admin-restricted-operation` for Web API calls, or `ERROR_ADMIN_RESTRICTED_OPERATION` for Android and iOS. You should gracefully\nhandle the error on your front-end by asking the user to take the appropriate\nactions for your service.\n\nAuth tokens\n-----------\n\nWhen you perform authentication with Identity Platform, there are three\nkinds of auth tokens you might encounter:\n\nVerified email addresses\n------------------------\n\nIdentity Platform considers an email verified if it meets two conditions:\n\n1. The user completes the Identity Platform verification flow\n2. The email is verified by a trusted Identity Provider, or IdP for short.\n\nIdPs that verify email once, but then allow users to change email addresses without requiring re-verification, are not trusted. IdPs that either own the domain or always require verification are considered trusted.\n\nTrusted providers:\n\n- Google (for @gmail.com addresses)\n- Yahoo (for @yahoo.com addresses)\n- Microsoft (for @outlook.com and @hotmail.com addresses)\n- Apple (always verified, because accounts are always verified and multi-factor-authenticated)\n\nUntrusted providers:\n\n- Facebook\n- Twitter\n- GitHub\n- Google, Yahoo, and Microsoft for domains not issued by that Identity Provider\n- Email / Password without email verification\n\nIn some situations, Identity Platform will automatically link accounts when a user signs in with different providers using the same email address. This can only happen when specific criteria are met, however. To understand why, consider the following situation: a user signs in using Google with a @gmail.com account and a malicious actor creates an account using the same @gmail.com address, but signing in via Facebook. If these two accounts were automatically linked, the malicious actor would gain access to the user's account.\n\nThe following cases describe when we automatically link accounts and when we throw an error requiring user or developer action:\n\n- User signs in with an untrusted provider, then signs in with another untrusted provider with the same email (for example, Facebook followed by GitHub). This throws an error requiring account linking.\n- User signs in with a trusted provider, then signs in with untrusted provider with the same email (for example, Google followed by Facebook). This throws an error requiring account linking.\n- User signs in with an untrusted provider, then signs in with a trusted provider with the same email (for example, Facebook followed by Google). The trusted provider overwrites the untrusted provider. If the user attempts to sign in again with Facebook, it will cause an error requiring account linking.\n- User signs in with a trusted provider, then signs in with a different trusted provider with the same email (for example, Apple followed by Google). Both providers will be linked without errors.\n\nYou can manually set an email as verified by using the Admin SDK, but we recommend only doing this if you know the user really does own the email."]]
