How to Deploy Logto as a GCP Identity Platform Alternative
Google Cloud Identity Platform is Google's managed CIAM service for web and mobile applications. It provides user account management, customizable authentication flows, social and enterprise identity federation, multi-factor authentication, and integration with Google Cloud services. It removes the need to operate an identity store, but it bills per monthly active user (MAU) in provider tiers, where email, phone, anonymous, and social sign-in are free to 50,000 MAU while OIDC and SAML federation are free only to 50 MAU before per-user charges begin, meters phone and multi-factor messages separately, and ties the user store and its flows to a Google Cloud project.
Logto is an open-source Customer Identity and Access Management (CIAM) platform built on the OAuth 2.1 and OpenID Connect (OIDC) standards, and it covers the same ground on self-hosted infrastructure without per-user billing or cloud provider API dependencies. It provides a branded sign-in experience, social and enterprise Single Sign-On (SSO) federation, multi-factor authentication (MFA), role-based access control (RBAC), organizations for multi-tenancy, and webhooks, and it stores every user, application, and role in a PostgreSQL database you control. Because it implements the OIDC specification rather than a proprietary protocol, standard client libraries integrate with it unchanged. A self-hosted deployment also gives you direct control over the token lifetimes, the user schema, the connector set, and the data residency of the identity store.
This article explains how to deploy Logto as an alternative to Google Cloud Identity Platform. It covers the Docker Compose deployment with Traefik as the reverse proxy, automatic HTTPS with Let's Encrypt, the admin console, the sign-in experience and brand identity, email and social login connectors, enterprise SSO, MFA, RBAC and API resources, organizations for multi-tenancy, application registration, webhooks, deployment verification, and migration from Google Cloud Identity Platform.
Understanding Logto Architecture
Logto covers most Identity Platform components through a self-hosted, OIDC-standard platform. The following table maps each Identity Platform feature to its Logto counterpart and notes where no equivalent exists.
The Logto Core service (auth.example.com) exposes the OIDC endpoints, Management API (/api), and the user-facing sign-in experience. The Admin Console (admin.example.com) is a separate frontend that manages tenant configuration through the Management API.
Prerequisites
Before you begin:
- Have access to a Linux-based server (with at least 2 CPU cores and 8 GB of RAM) as a non-root user with sudo privileges.
- Install Docker and Docker Compose.
- Create DNS A records pointing to your server's IP address for the following subdomains:
auth.example.com(Logto Core API and sign-in experience) andadmin.example.com(Admin Console).
Deploy Logto with Docker Compose
Logto requires PostgreSQL 14 or later to store users, configuration, and session data. This section deploys Logto for production on a Linux server using Docker Compose, Traefik for automatic HTTPS with Let's Encrypt, and PostgreSQL for durable storage.
Create the project directory structure.
CONSOLENavigate to the project directory.
CONSOLECreate the Logto environment file.
CONSOLEAdd the following configuration:
INISave and close the file.
Replace:
auth.example.com: Your Logto Core API subdomain.admin.example.com: Your Admin Console subdomain.admin@example.com: Your email address for Let's Encrypt certificate notifications.DB-PASSWORD: A strong password for the PostgreSQL database.1.40.1: The Logto release version to deploy. Check the Logto releases page for the latest stable version when upgrading.
Download the Logto Docker Compose file for the pinned release.
Note
Pin the compose file URL to the same release tag as
TAGin the environment file. The followingdocker-compose.ymlfile is maintained by Logto.CONSOLEUpdate the
docker-compose.ymlfile for production use. The official compose file ships with hardcoded database credentials and is labeled for demonstration; replace those defaults before deployment.CONSOLEFind the
appservice and update theDB_URLunder theenvironmentsection as follows:YAMLFind the
postgresservice and update thePOSTGRES_PASSWORDvalue in theenvironmentsection:YAMLPin the PostgreSQL image to a specific release for reproducible deployments:
YAMLSave and close the file.
Create the Traefik Docker Compose override file.
CONSOLEAdd the following configuration:
YAMLSave and close the file.
Traefik routes HTTPS traffic to Logto on subdomain-based host rules. Port 3001 serves the Core API and sign-in experience; port 3002 serves the Admin Console. Let's Encrypt certificates are provisioned automatically once DNS resolves to this server. This stack pins
svhd/logtoto theTAGvalue in.env,traefiktov3.7.0, and PostgreSQL to17.5-alpinefor reproducible production deployments.Start the Logto stack.
CONSOLEVerify the containers are running.
CONSOLEThe output displays running containers for Traefik, Logto, and PostgreSQL.
Verify HTTPS on the Admin Console.
CONSOLEThe output returns
HTTP/2 302withlocation: /console/welcomeon first boot.Verify the OIDC discovery endpoint.
CONSOLEThe output returns JSON containing
authorization_endpointandissuervalues scoped to yourauth.example.comdomain.
Access the Admin Console
The Admin Console is the central management interface for configuring the Logto tenant.
- Open a web browser and navigate to the Logto Admin Console at
https://admin.example.com. - Follow the on-screen instructions to create the initial administrator account.
- Log in to the dashboard using the new credentials.
- Review the sidebar to confirm access to Applications, Sign-in & account, Multi-factor auth, Connectors, Enterprise SSO, API resources, Roles, Organizations, Webhooks, and Audit logs.
Configure Sign-in Experience
The sign-in experience defines the look, feel, and authentication flow for your users. Logto allows you to customize the interface to match your brand identity.
Set the Brand Identity
- Navigate to Sign-in & account in the left sidebar and select Branding.
- Upload the company logo (for example,
https://example.com/logo.png) and set the primary brand color (for example,#6139F6). - Click Done.
Configure the Email Connector
To verify user identities via email and enable password resets, configure an email connector with your SMTP provider credentials.
- Navigate to Connectors and select the Email and SMS connectors tab.
- Click Set up under the Email connector and select SMTP.
- Obtain the SMTP credentials from your email provider. You need the host, port, username, and password.
- Return to the Logto Console and enter the following SMTP settings. Replace the placeholder values with your provider's credentials.
- host:
SMTP-HOST - Port:
SMTP-PORT - Auth:
- type:
login - user:
SMTP-USERNAME - pass:
SMTP-PASSWORD
- type:
- From email:
SENDER-EMAIL-ADDRESS - Reply to:
REPLY-TO-EMAIL-ADDRESS
- host:
- Toggle Secure to On if your provider requires TLS.
- Send a test email to verify the connection.
- Click Save and Done.
Define Sign-up Identifiers and Sign-in Methods
Select the primary methods users can use to create an account and sign in. Logto supports username, email, and phone-based authentication.
- Navigate to Sign-in & account and select the Sign-up and sign-in tab.
- Select the Sign-up identifiers:
- Username: A unique public identifier.
- Email address: Recommended for communication and password recovery.
- Phone number: Enables SMS-based authentication for mobile-first applications.
- Configure the Sign-in methods to allow users to sign in with their chosen identifiers.
- Click Save Changes.
Enable Passwordless Sign-in
Passwordless authentication reduces friction by allowing users to sign in with one-time codes instead of a password.
- Remain on the Sign-up and sign-in tab.
- Under Sign-in methods, enable Email verification code or SMS verification code as a sign-in option.
- Ensure the corresponding email or SMS connector is configured under Connectors by selecting the Email and SMS connectors tab.
- Click Save Changes.
Preview the Sign-in UI
- Click the Live preview button on the right side of the Sign-up and sign-in page.
- Test the branded interface and enabled sign-in methods before applying changes to production traffic.
Note
While this article focuses on email via SMTP, Logto also supports SMS-based registration and sign-in via third-party providers such as Twilio or Vonage. To use phone numbers, configure an SMS connector under Connectors by selecting the Email and SMS connectors tab. Users access the hosted sign-in UI through a registered application with a valid client_id and redirect URI, not by visiting auth.example.com directly. Direct navigation without an application context returns an unknown-session page.
Set Up Social Login Connectors
Social login allows users to authenticate using their existing accounts from third-party identity providers, reducing friction during the registration process.
- Navigate to Connectors in the left sidebar and select the Social connectors tab.
- Click Add social connector and select Google from the list.
- Follow the on-screen instructions to create a project in the Google Cloud Console:
- Create a new project.
- Navigate to APIs & Services, then select OAuth consent screen.
- Configure the consent screen and add the domain (for example,
example.com) as an authorized domain. - Go to Credentials, click Create Credentials, and select OAuth client ID.
- Select Web application as the application type.
- Add the Logto Callback URI (for example,
https://auth.example.com/callback/google) to the Authorized redirect URIs.
- Copy the Client ID and Client Secret provided by Google.
- Paste the credentials into the corresponding fields in the Logto social connector configuration.
- Configure the Scope field in Logto. By default, Logto requests
openid,profile, andemail. If the application requires additional Google API access (such as Calendar or Drive), append the respective scope URLs separated by spaces. - Click Save and Done.
- Repeat the process for GitHub and Apple by selecting those providers from the Add social connector list and following each provider's OAuth configuration instructions.
- Navigate to Sign-in & account and select Sign-up and sign-in.
- Under Social sign-in, click Add social connector and select the connectors you configured.
- Click Save Changes and use the Live preview to test the social sign-in flow.
Configure Enterprise SSO
Enterprise Single Sign-On (SSO) enables corporate users to authenticate via their own Identity Provider (IdP), such as Okta or Microsoft Entra ID.
- Navigate to Enterprise SSO in the left sidebar.
- Click Add enterprise connector and select Okta (or SAML / OIDC for a generic enterprise connector).
- Refer to the Connection guide button within the Logto Console for a direct link to the provider-specific setup instructions.
- Follow the on-screen steps to create an OIDC application in your Okta dashboard:
- Register a new OIDC application.
- Set the Login redirect URI to the value provided in the Logto console.
- Obtain the Client ID, Client Secret, and Issuer URL.
- Enter these details into the Logto connector configuration.
- Click Save to save the connector credentials.
- For SAML connectors, exchange IdP metadata with Logto by uploading the SAML metadata file or entering the metadata URL provided by your IdP.
- Navigate to the SSO Experience tab in the connector settings.
- Add the email domains associated with the organization (for example,
example.com).Note
Users with matching email domains are automatically routed to the enterprise IdP login page. Other sign-in methods like social login or local passwords are disabled for these domains to enforce corporate security policies.
- Enable JIT provisioning to create users automatically on first SSO sign-in.
- Click Save changes.
Enable Multi-Factor Authentication
Multi-factor Authentication (MFA) adds an extra layer of security by requiring secondary verification during the sign-in process.
- Navigate to Multi-factor auth in the left sidebar.
- Toggle the desired MFA methods to On:
- Authenticator app (TOTP): Standard time-based codes from apps like Google Authenticator.
- WebAuthn / Passkeys: High-security biometric (TouchID, FaceID) or hardware key (YubiKey) authentication.
- Backup codes: One-time use recovery codes for account fallback.
- SMS or Email OTP: Requires the corresponding connector configured under Connectors by selecting the Email and SMS connectors tab.
- Configure the MFA Policy to determine when users are prompted (for example, optional MFA or required on every login).
- Click Save changes.
Configure RBAC and API Resources
Role-Based Access Control (RBAC) securely limits access to specific backend resources and endpoints based on a user's assigned role.
- Navigate to API Resources and click Create API resource.
- Enter an API Name and a unique API Identifier (for example,
https://api.example.com/orders). - Define Permissions (Scopes) such as
read:ordersandwrite:orders. - Navigate to Roles and click Create role.
- Assign the API permissions to the role and click Save.
- On the Assign user screen, select users from the list and click Assign user, or click Skip to assign them later from the User management tab.
- Navigate to Custom JWT in the left sidebar if global roles must appear in access tokens. Configure an access token script to inject role claims into issued JWTs.
- Navigate back to API Resources and open the API resource you created.
- Click Check guide in the top-right corner. The console displays a Select a tutorial dialog with framework options such as Express, Python, and Spring Boot.
- Select the framework that matches your application. The console tutorial displays step-by-step integration code for initializing the Logto SDK, protecting API routes, and validating the access token against your API identifier.
Set Up Organizations for Multi-Tenancy
Organizations offer multi-tenant isolation, allowing you to build B2B applications where users belong to different corporate entities. An organization template serves as a blueprint, defining a consistent set of roles and permissions available to every organization in your Logto tenant.
- Navigate to Organization template in the left sidebar.
- Create Organization permissions. These are fine-grained, non-API actions that define business logic or UI features within an organization.
- Click Create organization permission.
- Enter a Permission name (for example,
read:resource) and Description. - Repeat the process to create other permissions such as
edit:resourceanddelete:resource.
- Create Organization roles. These are collections of organization permissions or API resource permissions that you can assign to members.
- Click Create organization role.
- Enter a name (for example,
AdminorMember) and a description. - Map the previously created organization permissions and any relevant API resource permissions to the role.
- Navigate to Organizations and click Create organization to provision a new tenant.
- Select the organization and navigate to the Members tab.
- Click Add Members and select users from the list.
- Assign an organization role to each member from the role dropdown. Logto scopes JWT tokens to include the organization context when organization-scoped tokens are requested.
- Click Check guide in the top-right corner to view integration tutorials for implementing multi-tenant features and org-scoped tokens in your application.
Register Applications
Register your frontend and backend services as applications within Logto to authenticate users and obtain tokens.
Note
Specific steps vary depending on the application type, such as Single-Page App, Traditional Web App, Native App, or Machine-to-Machine. Use the framework-specific tutorial provided in the console for detailed instructions.
- Navigate to Applications in the left sidebar.
- Initial Setup: If no applications exist, the console displays a grid of supported frameworks and languages (for example, React, Next.js, Node.js). Select your preferred framework to view the integration tutorial and click Start building to create the application.
- Subsequent Applications: If you have already registered an application, click Create application in the top-right corner to add another.
- Enter your application name and click Create application.
- Follow the Jumpstart guide to integrate Logto with your application.
- Configure the Redirect URIs, which dictate where Logto sends users after a successful sign-in.
- Configure the Post Sign-out Redirect URIs to determine where users land after logging out.
- Note the App ID and integration endpoint to initialize the Logto SDK in the application code.
- Click Save changes.
Register at least three application types to cover common architectures:
- Single-Page App (SPA): For React, Vue, or Angular frontends.
- Traditional Web App: For server-rendered applications with a backend session.
- Machine-to-Machine (M2M): For backend services that call the Management API or protected APIs without user interaction.
Open the application sign-in URL or use the Logto SDK in a test client to confirm the redirect-based sign-in flow completes successfully.
Configure Webhooks
Webhooks offer real-time notifications for identity events, allowing your backend systems to react asynchronously to changes within Logto without continuous polling.
- Navigate to Webhooks in the left sidebar and click Create webhook.
- Enter the backend Endpoint URL and assign a descriptive name.
- Select the specific Webhook events to monitor (for example,
User.Created,PostSignIn, orUser.Data.Updated). - Add optional Custom headers if the receiving endpoint requires authentication tokens or other metadata in the request.
- Click Create webhook.
- Secure the webhook. Logto provides a Signing Key in the webhook settings. Use this key to cryptographically verify that incoming payloads originated from the Logto instance and have not been tampered with.
- Send a test payload to confirm the endpoint receives and processes webhook events.
Verify the Deployment
After configuration, run the following checks to confirm the deployment is healthy end to end.
- Infrastructure: Confirm all containers are running with
docker ps. Traefik, Logto, and PostgreSQL should report anUpstatus. - TLS: Open
https://admin.example.comandhttps://auth.example.comin a browser. Both should load with valid Let's Encrypt certificates. - OIDC discovery: Run
curl -s https://auth.example.com/oidc/.well-known/openid-configurationand confirm theissuermatcheshttps://auth.example.com/oidc. - Admin Console: Create the initial admin account and confirm the dashboard loads with all sidebar sections (Applications, Sign-in & account, MFA, Connectors, Enterprise SSO, API resources, Roles, Organizations, Webhooks, Audit logs).
- User registration and sign-in: Register a test user through the application you created in the Register Applications section. Confirm password-based sign-in works.
- Social login: If configured, test Google, GitHub, or Apple sign-in through the Live preview or application redirect flow.
- MFA: Enable TOTP for a test user and confirm the second factor is enforced on the next sign-in.
- RBAC claims: Request an access token for an API resource and verify the token contains the expected scopes after role assignment.
- Organization-scoped login: Add a user to an organization, sign in, and confirm organization context appears in the token or session as documented in the organization integration tutorial.
- Audit logs: Navigate to Audit logs in the Admin Console and confirm sign-in and configuration events are recorded.
Migrate from GCP Identity Platform to Logto
Migrating from GCP Identity Platform to Logto involves mapping Identity Platform Users and Tenants to Logto Organizations and Users, replacing Firebase / GCP Admin SDK calls with Logto SDKs and the Management API, and converting Blocking Functions to webhooks or Custom JWT scripts. Because Identity Platform does not export password hashes or MFA secrets, most migrations follow a bulk user import with mandatory re-authentication strategy. The guidance below assumes you completed Deploy Logto with Docker Compose, Access the Admin Console, and Register Applications earlier in this article.
User Migration
GCP Identity Platform bundles user directories, authentication flows, OAuth client configurations, and tenant isolation into a single managed service. Logto splits these responsibilities across users, the sign-in experience, applications, roles, and organizations within a self-hosted tenant.
- Export: Retrieve user profiles from Identity Platform using the Firebase Admin SDK (
listUsers()) or the Identity Toolkit API. For multi-tenant projects, iterate through each tenant to export tenant-scoped users. - Import: Iterate over the exported data and create users through the Logto Management API on the Core endpoint (
POST /api/usersathttps://auth.example.com/api). Authenticate with an access token from a Logto Machine-to-Machine application. - Passwords: Identity Platform does not expose password hashes. Import users with temporary credentials and trigger a password reset or forgot-password flow on first login.
- MFA enrollments: Store the original Identity Platform / Firebase
localId(UID) in LogtocustomData(for example,legacy_firebase_uid) during import to preserve linkages in downstream application databases and Cloud Firestore documents.
Application Migration
Application changes depend on how clients currently integrate with Identity Platform.
If applications use the Firebase Authentication SDK, replace Firebase Auth APIs with the Logto SDK for your framework:
signInWithEmailAndPassword/signInWithPopup/ embedded forms: Redirect-based Universal Login through the Logto hosted sign-in experience.- Firebase API Key / OAuth Client ID: Logto Application ID (
client_idin OIDC). - Authorized Domains / Callback URLs: Redirect URIs and Post Sign-out Redirect URIs configured in the Logto Console.
- Token Refresh: Logto SDK session management or standard OIDC refresh token flows.
If applications call the Identity Platform API directly via the Identity Toolkit REST API or the Firebase Admin SDK, replace those calls with Logto SDK methods or direct OIDC endpoints:
verifyPassword/verifyCustomToken/signUp: OIDC authorization code flow with PKCE (browser apps) or client credentials flow (M2M).- getAccountInfo: OIDC UserInfo endpoint or Management API user lookup.
- Firebase ID tokens: Validate against the Logto JWKS endpoint (
https://auth.example.com/oidc/jwks) with issuerhttps://auth.example.com/oidc.
In both cases, update backend middleware to validate Logto-issued JWTs instead of Firebase ID tokens. Refer to the Logto protect-your-api documentation for framework-specific examples.
Role and Group Migration
Identity Platform does not provide a native group primitive. Instead, developers typically assign roles through custom claims (via the Firebase Admin SDK setCustomUserClaims) or isolate users by tenant. Logto offers two mapping paths depending on whether your existing structure represents global permissions or tenant-scoped membership.
- Identity Platform Custom Claims → Logto Roles: Custom claims that gate API access or admin capabilities map to global Roles. Create each role (
POST /api/roles), define API resource permissions, and assign users (POST /api/users/{userId}/roles). Global roles are not included in access tokens by default; configure a Custom JWT access token script in the Admin Console to inject role claims. - Identity Platform Tenants → Logto Organizations: Tenant-scoped users that represent B2B customers or corporate entities map to Organizations. Create the organization (
POST /api/organizations), define organization roles in the Organization template, and add members (POST /api/organizations/{id}/users). If you previously stored tenant membership in Firestore or custom claims, import that relational data into Logto organization memberships. - Authorization Enforcement: Update backend route guards and policy engines to parse the claims your Custom JWT script emits rather than Firebase custom claims (for example, replacing
decodedToken.adminordecodedToken.tenant_idwith Logtorolesororganization_rolesclaims).
Blocking Function Migration
Identity Platform's Blocking Functions and Asynchronous Functions run during the authentication lifecycle. Logto does not support synchronous blocking hooks; each trigger type maps to a different replacement with distinct operational characteristics.
- Post-confirmation / Post-authentication (async): Map to Logto Webhooks for events such as
User.Created,PostSignIn, orUser.Data.Updated. Webhooks deliver HTTP payloads asynchronously after the auth flow completes. Refer to the Logto webhook documentation. - Custom Claims / Token Enrichment: Map to Custom JWT access token scripts in the Admin Console. In Identity Platform, custom claims are typically set via the Firebase Admin SDK (
setCustomUserClaims) or within blocking functions to embed roles and permissions into Firebase ID tokens. Logto scripts run in a sandbox during token issuance to inject roles, organization memberships, or custom attributes into the JWT. - Pre-authentication / Pre-sign-up (sync, blocking): Map to application middleware, API gateway rules, or a custom authentication proxy. Logto webhooks cannot block or reject an in-progress sign-in or sign-up synchronously.
- Custom message: Map to email or SMS connectors configured under Connectors, or handle notification logic in a webhook consumer that calls your messaging provider.
Unlike Cloud Functions, which scale per invocation and run only during auth events, Custom JWT scripts execute on every token issuance and webhook consumers run as always-on services. Account for this operational difference when planning capacity.
Data Storage Considerations
For environments with existing identity data and active sessions:
- Session invalidation: Session invalidation: Identity Platform sessions and refresh tokens become invalid at cutover. Force re-authentication across all client applications and clear local Firebase SDK session state (
onAuthStateChangedlisteners will fire withnull). - Downstream identity references: Applications that store Identity Platform
localIdvalues in their own databases rely on thelegacy_identity_platform_uidmapping in LogtocustomDatauntil those references are updated. - Management API integration: Replace calls to the Identity Toolkit / Firebase Admin SDK (
getUser,listUsers,updateUser) with the Logto Management API athttps://auth.example.com/api. Authenticate M2M clients with a Logto Machine-to-Machine application. - Federation metadata: If Identity Platform federates external IdPs through SAML or OIDC, recreate those federation relationships as Logto Enterprise SSO connectors or social connectors rather than attempting to migrate Identity Platform's internal provider configuration directly.
Things to Take Care During Migration
- Firebase SDK to Logto SDK: Embedded sign-in forms (
signInWithEmailAndPassword,signInWithPopup) and direct Identity Toolkit API calls must move to redirect-based OIDC flows. This is the largest application-code change in most migrations. - Blocking Functions: Identity Platform supports synchronous, blocking functions during sign-up and sign-in. Logto webhooks are asynchronous only; blocking validation requires application middleware or an API gateway.
- GCP Resource Access: Identity Platform does not grant end users direct access to cloud resources via IAM roles — there is no equivalent feature to migrate away from. If your application separately uses Workload Identity Federation for backend services, that's unrelated to end-user auth and isn't affected by this migration.
- Account Defender: Identity Platform's built-in compromised-credential and threat-signal detection has no direct Logto OSS equivalent. Implement rate limiting, WAF rules, or bot protection at the reverse proxy layer.
- MFA Re-enrollment: TOTP secrets and enrolled phone numbers cannot be extracted from Identity Platform. Users must re-enroll authenticator apps, passkeys, or SMS factors after cutover.
- Token Format Differences: Identity Platform ID tokens nest provider and tenant metadata under a
firebaseclaim (sign_in_provider,tenant) alongside any custom claims. Logto issues standard OIDC claims (sub,email,scope,organization_id). Update API parsers and authorization middleware accordingly. - Cost Model Change: Identity Platform charges per monthly active user (MAU) with tiered pricing above a free allotment, plus separate SMS/phone-auth charges. Logto OSS costs are infrastructure-based, covering compute, storage, and operational overhead. Calculate total cost of ownership before cutover.
- Cutover Sequencing: Run a phased migration with dual-write or read-replica validation where possible. Import users first, validate token flows in a staging tenant, then redirect production traffic to Logto and disable sign-in through the Identity Platform project or tenant.
Conclusion
You have deployed Logto behind a Traefik reverse proxy, configured the sign-in experience, social and enterprise SSO, MFA, RBAC, organizations, applications, and webhooks, and verified the deployment end to end. The migration section also covers the key steps and considerations for migrating users, applications, and authentication flows from Google Cloud Identity Platform to Logto. For additional deployment options, advanced configuration, and SDK integrations, refer to the official Logto documentation.
0 Comments
Be the first to comment and share your perspective with the community.