{"id":534,"date":"2026-04-14T10:14:22","date_gmt":"2026-04-14T10:14:22","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-identity-platform-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/"},"modified":"2026-04-14T10:14:22","modified_gmt":"2026-04-14T10:14:22","slug":"google-cloud-identity-platform-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-identity-platform-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/","title":{"rendered":"Google Cloud Identity Platform Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Access and resource management"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Access and resource management<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p><strong>What this service is<\/strong><br\/>\nIdentity Platform is Google Cloud\u2019s managed <strong>Customer Identity and Access Management (CIAM)<\/strong> service for adding authentication and user identity features to your applications\u2014without building and operating your own identity system.<\/p>\n\n\n\n<p><strong>Simple explanation (one paragraph)<\/strong><br\/>\nIf you have a website, mobile app, or API and you need users to sign up, sign in, reset passwords, or use federated login (like Google, SAML, or OIDC), Identity Platform provides those capabilities as a hosted service. Your app receives secure tokens after login and can use them to authorize requests to your backend.<\/p>\n\n\n\n<p><strong>Technical explanation (one paragraph)<\/strong><br\/>\nIdentity Platform is a Google Cloud service that builds on the same core technology as <strong>Firebase Authentication<\/strong>, adding enterprise\/production-ready CIAM capabilities (notably <strong>multi-tenancy<\/strong>, enterprise federation, and stronger operational controls). Clients authenticate using standard flows and receive <strong>OpenID Connect-compatible ID tokens<\/strong> (JWTs). Backends validate these tokens (for example, using the Firebase Admin SDK) and implement authorization based on user identity, claims, and tenancy context.<\/p>\n\n\n\n<p><strong>What problem it solves<\/strong><br\/>\nIt solves the \u201cidentity layer\u201d problem for customer-facing applications: secure sign-in\/sign-up, federated identity, session\/token issuance, user lifecycle operations, tenant isolation (for B2B SaaS), and integration with Google Cloud security and observability\u2014while reducing the risk and effort of implementing authentication correctly.<\/p>\n\n\n\n<blockquote>\n<p>Service status and naming note: <strong>Identity Platform<\/strong> is an active Google Cloud product. It is closely related to <strong>Firebase Authentication<\/strong> (same family\/SDKs in many cases), but Identity Platform is the Google Cloud offering targeted at CIAM needs (including multi-tenancy). Always confirm feature availability and limits in the official docs because capabilities can vary by provider, plan, and release.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Identity Platform?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Identity Platform is designed to help you <strong>authenticate and manage external users<\/strong> (customers, partners, citizens, students, etc.) for your applications. It provides identity federation and token-based authentication so your apps and APIs can trust who a user is.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>At a high level, Identity Platform provides:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>User authentication<\/strong> for common sign-in methods (for example, email\/password and federated identity providers).<\/li>\n<li><strong>Token issuance<\/strong> (ID tokens) suitable for securing backends and APIs.<\/li>\n<li><strong>User account management<\/strong> (creating users, disabling users, managing user attributes).<\/li>\n<li><strong>Enterprise CIAM patterns<\/strong>, especially <strong>multi-tenancy<\/strong> for isolating users and identity providers per tenant (common for B2B SaaS).<\/li>\n<\/ul>\n\n\n\n<p>(Exact providers and advanced features can change\u2014verify in official docs for the latest supported providers and regional availability.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>Identity Platform solutions typically consist of:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Identity Platform configuration in a Google Cloud project<\/strong><\/li>\n<li>Providers (email\/password, federated providers, SAML\/OIDC)<\/li>\n<li>Authorized domains \/ application registrations (web, mobile)<\/li>\n<li>Multi-tenant settings (if used)<\/li>\n<li><strong>Client applications<\/strong><\/li>\n<li>Web app, iOS app, Android app, or other clients using supported SDKs<\/li>\n<li><strong>Backend services<\/strong><\/li>\n<li>Cloud Run, GKE, Compute Engine, or on-prem services verifying tokens and enforcing authorization<\/li>\n<li><strong>Admin tooling<\/strong><\/li>\n<li>Firebase Admin SDK (commonly used) or Google Cloud tooling\/APIs for managing users and tenants<\/li>\n<li><strong>Observability and governance<\/strong><\/li>\n<li>Cloud Logging \/ Audit Logs, Monitoring, IAM, and policy controls<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed CIAM \/ authentication service<\/strong> (identity for your application users)<\/li>\n<li>Not a general replacement for workforce identity (for that, see <strong>Cloud Identity<\/strong> \/ Google Workspace identity)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: project and global behavior<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity Platform is configured <strong>per Google Cloud project<\/strong>.<\/li>\n<li>Authentication endpoints are <strong>global<\/strong> in nature (users can sign in from anywhere), but your compliance requirements may depend on where your backends run and where you export\/store logs and user-related data. Validate data residency requirements in the official documentation and your compliance program.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Identity Platform is part of Google Cloud\u2019s <strong>Access and resource management<\/strong> landscape, but it targets <strong>application end users<\/strong> (customers) rather than administrators. Common integrations include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Run \/ GKE \/ Compute Engine<\/strong>: secure APIs by verifying Identity Platform ID tokens<\/li>\n<li><strong>API Gateway \/ Apigee \/ Cloud Endpoints<\/strong>: front-door API management (token verification patterns vary\u2014verify supported integrations)<\/li>\n<li><strong>Cloud Armor<\/strong>: DDoS and WAF controls for your app endpoints<\/li>\n<li><strong>Secret Manager<\/strong>: manage provider secrets safely (when needed)<\/li>\n<li><strong>Cloud Logging and Cloud Monitoring<\/strong>: operational visibility<\/li>\n<li><strong>IAM<\/strong>: control which admins\/operators can configure Identity Platform and access logs<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Identity Platform?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster time-to-market<\/strong>: avoid building login, password reset, federation, and token systems from scratch.<\/li>\n<li><strong>Lower operational burden<\/strong>: reduce ongoing maintenance and incident risk tied to authentication.<\/li>\n<li><strong>B2B SaaS enablement<\/strong>: multi-tenancy helps you support multiple customer organizations cleanly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standards-based auth<\/strong>: tokens and federation approaches align with OAuth 2.0 \/ OpenID Connect patterns.<\/li>\n<li><strong>Works across platforms<\/strong>: web and mobile support via common SDK patterns.<\/li>\n<li><strong>Backend-friendly<\/strong>: JWT ID tokens can be verified server-side and used to build robust authorization.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralized configuration<\/strong> for providers and tenants.<\/li>\n<li><strong>Auditability<\/strong> through Google Cloud logging\/auditing (exact logs depend on configuration\u2014verify in official docs).<\/li>\n<li><strong>Scales with your user base<\/strong> without provisioning identity servers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduces risk of common authentication implementation mistakes.<\/li>\n<li>Enables federated logins (SAML\/OIDC) to integrate with enterprise identity systems.<\/li>\n<li>Supports strong controls like disabling users, revoking access, and (where supported) multi-factor approaches.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Designed for large numbers of users and high auth traffic.<\/li>\n<li>Offloads credential handling and token issuance to Google-managed infrastructure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Identity Platform<\/h3>\n\n\n\n<p>Choose Identity Platform when you need one or more of the following:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>CIAM<\/strong> solution integrated with Google Cloud<\/li>\n<li><strong>Multi-tenant identity<\/strong> for B2B SaaS (separate tenants with their own IdPs and settings)<\/li>\n<li>Enterprise federation (SAML\/OIDC) for customer organizations<\/li>\n<li>A managed service with Google Cloud governance and operational tooling<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>workforce identity<\/strong> (employees\/admins) \u2192 evaluate <strong>Cloud Identity \/ Google Workspace<\/strong>, and for app access consider <strong>IAP<\/strong> or enterprise SSO patterns.<\/li>\n<li>You need <strong>very custom identity flows<\/strong> requiring deep customization of login UI\/UX hosted by the identity provider itself (you may prefer dedicated CIAM vendors or self-hosted IAM like Keycloak).<\/li>\n<li>You must meet <strong>strict data residency<\/strong> constraints that Identity Platform cannot satisfy for your regulatory context (verify in official docs and with Google Cloud compliance resources).<\/li>\n<li>You are deeply invested in a different identity ecosystem (for example, Azure AD B2C, Okta\/Auth0) and want to avoid cross-cloud operational complexity.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Identity Platform used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and B2B platforms (multi-tenant customer organizations)<\/li>\n<li>E-commerce and marketplaces<\/li>\n<li>Media and consumer apps<\/li>\n<li>Education platforms (student logins, alumni portals)<\/li>\n<li>Healthcare portals (patient\/caregiver access\u2014subject to compliance)<\/li>\n<li>Financial services apps (often combined with additional fraud controls)<\/li>\n<li>Government digital services (citizen portals\u2014subject to compliance)<\/li>\n<li>Gaming communities and platforms<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Product engineering teams building customer apps<\/li>\n<li>Platform teams standardizing authentication across multiple apps<\/li>\n<li>Security engineering teams implementing secure-by-default auth patterns<\/li>\n<li>SRE\/operations teams responsible for identity availability and incident response<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Web apps (SPA + backend APIs)<\/li>\n<li>Mobile apps (iOS\/Android) with API backends<\/li>\n<li>API-only products using bearer tokens<\/li>\n<li>B2B SaaS platforms with tenant-specific sign-in methods<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SPA + Cloud Run microservices<\/li>\n<li>Mobile + API Gateway + GKE<\/li>\n<li>Multi-tenant SaaS with separate tenant configs and identity providers<\/li>\n<li>Hybrid systems where legacy apps rely on a centralized token issuer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production: strict IAM controls, multiple environments (dev\/stage\/prod), monitoring and auditing, incident response runbooks<\/li>\n<li>Dev\/test: single provider (email\/password), relaxed quotas, minimal federation, low-cost Cloud Run backend<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic Identity Platform use cases. Each includes the problem, why Identity Platform fits, and a scenario.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Add email\/password sign-in to a new web app<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need basic sign-up, sign-in, and password reset quickly and securely.<\/li>\n<li><strong>Why it fits<\/strong>: Identity Platform provides managed credential storage, authentication flows, and token issuance.<\/li>\n<li><strong>Scenario<\/strong>: A startup launches a React SPA and secures Cloud Run APIs using verified ID tokens.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Implement Google sign-in (federated login) for a consumer app<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Users want one-click login; you want fewer password resets.<\/li>\n<li><strong>Why it fits<\/strong>: Supports common federation patterns and token handling.<\/li>\n<li><strong>Scenario<\/strong>: A content platform allows Google sign-in for faster onboarding, while still supporting email\/password.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) B2B SaaS multi-tenancy with tenant-specific IdPs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Each business customer wants to use its own SAML\/OIDC provider; users must be isolated per tenant.<\/li>\n<li><strong>Why it fits<\/strong>: Identity Platform supports <strong>multi-tenancy<\/strong> patterns suitable for B2B SaaS.<\/li>\n<li><strong>Scenario<\/strong>: \u201cAcme Analytics\u201d onboards 200 enterprise customers, each with its own SSO settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Secure APIs for mobile apps using ID tokens<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You must authenticate mobile users and secure API access reliably.<\/li>\n<li><strong>Why it fits<\/strong>: Mobile clients get ID tokens; backends verify tokens and apply authorization.<\/li>\n<li><strong>Scenario<\/strong>: An Android app calls Cloud Run endpoints with bearer tokens; backend verifies tokens with Admin SDK.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Centralize authentication across multiple apps and environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple teams build apps with inconsistent auth implementations.<\/li>\n<li><strong>Why it fits<\/strong>: A shared Identity Platform approach standardizes providers, policies, and operational controls per project\/environment.<\/li>\n<li><strong>Scenario<\/strong>: A platform team defines a reference auth architecture and shared libraries for token verification.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Partner portal with enterprise SSO<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Partners expect SSO integration via SAML\/OIDC.<\/li>\n<li><strong>Why it fits<\/strong>: Identity Platform can federate with enterprise IdPs (verify supported IdPs in docs).<\/li>\n<li><strong>Scenario<\/strong>: A manufacturing company builds a partner portal with SSO + role-based authorization in the backend.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Step-up authentication (where supported) for sensitive actions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Some actions require stronger assurance than initial login.<\/li>\n<li><strong>Why it fits<\/strong>: Depending on available features, you can implement multi-factor or re-auth patterns (verify current support).<\/li>\n<li><strong>Scenario<\/strong>: A fintech app requires additional verification before changing payout settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Identity for serverless backends<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need authentication for Cloud Run \/ Cloud Functions without managing sessions.<\/li>\n<li><strong>Why it fits<\/strong>: Token-based auth aligns well with stateless serverless services.<\/li>\n<li><strong>Scenario<\/strong>: Each request includes a bearer token; Cloud Run verifies and enforces scope\/claims.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Controlled user lifecycle management via Admin SDK<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Support teams need to disable accounts, investigate suspicious activity, or migrate users.<\/li>\n<li><strong>Why it fits<\/strong>: Admin tooling supports user management operations (verify API coverage in docs).<\/li>\n<li><strong>Scenario<\/strong>: An internal admin portal lets support disable accounts and force sign-out.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Gradual migration from a legacy auth system<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You have an existing user database and want to migrate without a \u201cbig bang\u201d.<\/li>\n<li><strong>Why it fits<\/strong>: Identity Platform supports modern token-based auth and can be introduced behind a compatibility layer (migration details vary\u2014verify in docs).<\/li>\n<li><strong>Scenario<\/strong>: A legacy monolith moves to microservices; Identity Platform becomes the central token issuer over time.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Below are key Identity Platform features, why they matter, and practical notes. Capabilities may vary depending on provider types and configuration\u2014<strong>verify in official docs<\/strong> for the latest details.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Managed authentication (sign-up\/sign-in)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Handles user registration and authentication flows for supported methods (for example, email\/password).<\/li>\n<li><strong>Why it matters<\/strong>: Correctly implementing password handling, reset flows, and account security is hard.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster implementation and fewer vulnerabilities than homegrown auth.<\/li>\n<li><strong>Caveats<\/strong>: You still must implement secure UI, rate limiting, and abuse protections at the app layer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Federated identity (social and enterprise providers)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets users sign in with external identity providers (e.g., Google, and enterprise SAML\/OIDC providers where supported).<\/li>\n<li><strong>Why it matters<\/strong>: Reduces password fatigue and supports enterprise SSO requirements.<\/li>\n<li><strong>Practical benefit<\/strong>: Streamlined onboarding and improved user experience.<\/li>\n<li><strong>Caveats<\/strong>: Provider setup requires correct redirect URIs, domain verification, and secret management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Token issuance (ID tokens as JWTs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Issues ID tokens after authentication that clients send to your backend.<\/li>\n<li><strong>Why it matters<\/strong>: Enables stateless, scalable backend authentication.<\/li>\n<li><strong>Practical benefit<\/strong>: Backends verify tokens and authorize actions without session storage.<\/li>\n<li><strong>Caveats<\/strong>: You must validate tokens properly (signature, issuer, audience, expiry) and handle revocation strategies as documented.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) User management (admin operations)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Create\/disable users, update profiles, manage custom claims (where supported), and perform administrative actions.<\/li>\n<li><strong>Why it matters<\/strong>: Essential for support workflows, policy enforcement, and automation.<\/li>\n<li><strong>Practical benefit<\/strong>: Automate provisioning\/deprovisioning and build admin tools safely.<\/li>\n<li><strong>Caveats<\/strong>: Strongly restrict admin credentials and service accounts (least privilege).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Multi-tenancy (B2B SaaS patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows multiple tenants with isolated identity configurations (tenant-specific providers, settings, and user namespaces).<\/li>\n<li><strong>Why it matters<\/strong>: Multi-tenant identity is difficult to implement safely.<\/li>\n<li><strong>Practical benefit<\/strong>: Cleaner separation and onboarding for B2B customers.<\/li>\n<li><strong>Caveats<\/strong>: Requires careful tenant routing logic in your app (e.g., tenant selection by domain\/email or explicit tenant ID). Also consider data isolation beyond identity (DB, storage, logging).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Custom domains (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows hosting auth-related endpoints on your own domain (feature availability varies\u2014verify in docs).<\/li>\n<li><strong>Why it matters<\/strong>: Branding, phishing resistance, and alignment with enterprise security expectations.<\/li>\n<li><strong>Practical benefit<\/strong>: More consistent login experience and fewer third-party domain surprises.<\/li>\n<li><strong>Caveats<\/strong>: Domain verification, TLS certificates, and DNS changes add operational steps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) MFA \/ step-up options (feature availability varies)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Adds additional verification factors for higher assurance (verify currently supported factors and rollout status).<\/li>\n<li><strong>Why it matters<\/strong>: Reduces account takeover risk.<\/li>\n<li><strong>Practical benefit<\/strong>: Stronger protection for high-risk users\/actions.<\/li>\n<li><strong>Caveats<\/strong>: MFA can impact UX; SMS-based MFA has known security limitations\u2014consider alternatives when available.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Integration with Google Cloud IAM for administration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Google Cloud IAM to control who can configure Identity Platform and access related resources\/logs.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents unauthorized configuration changes or provider hijacking.<\/li>\n<li><strong>Practical benefit<\/strong>: Centralized access governance and audit.<\/li>\n<li><strong>Caveats<\/strong>: IAM must be designed carefully across environments and admin roles.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Observability (logging and auditing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides operational visibility through Google Cloud logging\/audit infrastructure (verify exact log types available).<\/li>\n<li><strong>Why it matters<\/strong>: Authentication is security-critical; you need traceability.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster troubleshooting and stronger incident response.<\/li>\n<li><strong>Caveats<\/strong>: Logging can incur cost; also treat identity logs as sensitive.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>Identity Platform acts as the identity provider for your application users:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A user attempts to sign in from a client (web\/mobile).<\/li>\n<li>The client uses Identity Platform-supported authentication flows.<\/li>\n<li>Identity Platform returns tokens to the client (commonly an ID token).<\/li>\n<li>The client calls your backend API with the token.<\/li>\n<li>The backend verifies the token and authorizes the request.<\/li>\n<li>Your backend accesses data\/services (databases, storage, other APIs).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: Admins configure providers, tenants, domains, and policies in a Google Cloud project (IAM protected).<\/li>\n<li><strong>Data plane<\/strong>: End users authenticate; tokens and related metadata are exchanged between clients, Identity Platform, and your backends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common production integrations include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Run \/ GKE<\/strong>: verify tokens in middleware; attach user identity to request context<\/li>\n<li><strong>API Gateway \/ Apigee<\/strong>: enforce auth at the edge (implementation differs; verify supported JWT validation patterns)<\/li>\n<li><strong>Secret Manager<\/strong>: store IdP client secrets\/keys<\/li>\n<li><strong>Cloud KMS<\/strong> (optional): manage encryption keys for your application data (Identity Platform token signing keys are Google-managed)<\/li>\n<li><strong>Cloud Armor<\/strong>: protect login endpoints and APIs from abuse<\/li>\n<li><strong>Cloud Logging\/Audit Logs<\/strong>: trace administrative changes and relevant events<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud project + billing<\/strong> (Identity Platform is a billable service)<\/li>\n<li><strong>Identity-related APIs<\/strong> enabled in the project (console typically handles this; you can confirm in APIs &amp; Services)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Users authenticate to Identity Platform using configured providers.<\/li>\n<li>Identity Platform issues signed tokens.<\/li>\n<li>Your backends must validate tokens on every request (or via a trusted gateway layer).<\/li>\n<li>Authorization is your responsibility: token verification proves identity; <strong>you must implement role\/permission checks<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Clients communicate with Identity Platform over the public internet.<\/li>\n<li>Backends should be exposed via HTTPS endpoints (Cloud Run, load balancer, API gateway).<\/li>\n<li>Use standard network protections: TLS everywhere, WAF (Cloud Armor), and rate limiting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor:<\/li>\n<li>error rates in sign-in flows<\/li>\n<li>backend token verification failures (401\/403 spikes)<\/li>\n<li>latency and availability of login endpoints<\/li>\n<li>Govern:<\/li>\n<li>IAM roles for admins<\/li>\n<li>change management for provider configuration<\/li>\n<li>separate projects for dev\/stage\/prod<\/li>\n<li>logging retention and access controls<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User] --&gt; C[Web\/Mobile Client]\n  C --&gt;|Sign-in \/ Sign-up| IDP[Identity Platform]\n  IDP --&gt;|ID Token (JWT)| C\n  C --&gt;|Authorization: Bearer ID_TOKEN| API[Backend API (Cloud Run)]\n  API --&gt;|Verify token| IDP\n  API --&gt; DATA[(App Data \/ Services)]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Internet\n    U[End User]\n  end\n\n  subgraph Edge\n    LB[HTTPS Load Balancer]\n    WAF[Cloud Armor (WAF\/DDoS)]\n    GW[API Gateway \/ Apigee (optional)]\n  end\n\n  subgraph GoogleCloudProject[\"Google Cloud Project (prod)\"]\n    IDP[Identity Platform]\n    CR[Cloud Run Services]\n    SEC[Secret Manager]\n    LOG[Cloud Logging + Audit Logs]\n    MON[Cloud Monitoring]\n    DB[(Database)]\n  end\n\n  U --&gt; LB --&gt; WAF --&gt; GW --&gt; CR\n  U --&gt;|Auth flows| IDP\n  CR --&gt;|Verify ID tokens| IDP\n  CR --&gt; SEC\n  CR --&gt; DB\n  IDP --&gt; LOG\n  CR --&gt; LOG\n  LOG --&gt; MON\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before starting the hands-on lab and using Identity Platform in production, ensure you have:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project\/billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud account<\/strong><\/li>\n<li>A <strong>Google Cloud project<\/strong> for the lab (recommended: dedicated project)<\/li>\n<li><strong>Billing enabled<\/strong> on the project (Identity Platform is billable; some usage may fall under free tier\u2014verify on pricing page)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Enable\/configure Identity Platform\n&#8211; Enable APIs\n&#8211; Deploy Cloud Run services\n&#8211; View logs<\/p>\n\n\n\n<p>Typical roles that work for a lab (principle of least privilege still applies):\n&#8211; <code>Owner<\/code> (broad; convenient for labs but not recommended for production)\n&#8211; Or a combination such as:\n  &#8211; Identity Platform admin permissions (verify the exact predefined roles in official docs)\n  &#8211; <code>Cloud Run Admin<\/code> and <code>Service Account User<\/code>\n  &#8211; <code>Logs Viewer<\/code><\/p>\n\n\n\n<blockquote>\n<p>In enterprises, use least privilege and separate admin roles for identity configuration vs. app deployment.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud CLI (<code>gcloud<\/code>)<\/a><\/li>\n<li>Node.js 18+ (for the sample backend)<\/li>\n<li>A code editor<\/li>\n<li>A modern browser<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run is regional; choose a region near your users.<\/li>\n<li>Identity Platform itself is a global service from an application perspective, but confirm any compliance\/residency constraints in official documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity Platform has quotas around operations and possibly tenants\/providers (verify in official docs).<\/li>\n<li>Cloud Run has request and concurrency limits per region (view quotas in the Google Cloud console).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run API enabled<\/li>\n<li>Artifact Registry (if using container builds) or Cloud Build (optional)<\/li>\n<li>Identity Platform enabled and configured<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Identity Platform pricing is <strong>usage-based<\/strong>. Exact SKUs, free tier thresholds, and rates can change and may differ by sign-in method and region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing sources (use these)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity Platform pricing page: https:\/\/cloud.google.com\/identity-platform\/pricing  <\/li>\n<li>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical model)<\/h3>\n\n\n\n<p>Common pricing drivers include (verify current SKUs on the pricing page):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Monthly Active Users (MAU)<\/strong>: users who authenticate during a month<\/li>\n<li><strong>Authentication method\/provider<\/strong>: some providers or enterprise federation may be priced differently<\/li>\n<li><strong>Phone\/SMS verification<\/strong> (if used): often billed per verification\/SMS (and can vary by country\/route)<\/li>\n<li><strong>Tenant count \/ advanced features<\/strong>: multi-tenancy itself may not be billed \u201cper tenant,\u201d but your usage patterns (MAU, federation) drive costs\u2014verify details<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<p>Identity Platform commonly offers a free tier for a certain number of MAUs for some sign-in methods, but <strong>do not assume<\/strong> thresholds\u2014confirm on the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MAU growth<\/strong>: the biggest direct cost driver in many CIAM setups<\/li>\n<li><strong>SMS verification<\/strong>: can spike unexpectedly due to bot traffic or abuse<\/li>\n<li><strong>High authentication frequency<\/strong>: users signing in repeatedly can increase MAU counts depending on definitions (MAU is per active user, but your login patterns matter)<\/li>\n<li><strong>Operational logging volume<\/strong>: Cloud Logging ingestion and retention costs can add up if logs are verbose<\/li>\n<li><strong>Backend costs<\/strong>: Cloud Run\/DB costs are separate, but auth design affects them (e.g., token verification overhead, user profile reads)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Abuse and fraud<\/strong>: credential stuffing, SMS pumping, and bot signups can drive MAU\/SMS usage<\/li>\n<li><strong>Support and compliance<\/strong>: auditing, log retention, and incident response processes<\/li>\n<li><strong>Custom domain and certificate operations<\/strong> (if used)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity Platform endpoints are internet-facing; your clients will call them over the public internet.<\/li>\n<li>Your backend traffic (Cloud Run egress\/ingress) and any cross-region data access can incur network charges depending on architecture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>non-SMS<\/strong> MFA options if\/when available and suitable (SMS can be costly and less secure).<\/li>\n<li>Implement <strong>rate limiting<\/strong> and abuse prevention at the edge (Cloud Armor) and in-app.<\/li>\n<li>Use <strong>progressive profiling<\/strong> and avoid unnecessary sign-in churn.<\/li>\n<li>Keep Cloud Logging at an appropriate level; set <strong>retention<\/strong> thoughtfully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated prices)<\/h3>\n\n\n\n<p>A low-cost starter setup typically includes:\n&#8211; Identity Platform with email\/password sign-in\n&#8211; A small Cloud Run backend under free tier or minimal traffic\n&#8211; Minimal logging retention\n&#8211; No SMS verification<\/p>\n\n\n\n<p>Your cost may be close to zero <strong>if<\/strong> you remain within free tiers and avoid SMS usage\u2014but <strong>verify<\/strong> your MAU counts and the current free tier in the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production:\n&#8211; Model MAU by segment (consumer vs. enterprise tenants)\n&#8211; Forecast MAU growth and seasonality\n&#8211; If using enterprise federation (SAML\/OIDC), validate any distinct pricing SKUs\n&#8211; Add budget for:\n  &#8211; Cloud Armor (WAF)\n  &#8211; Logging retention and exports (BigQuery\/Cloud Storage)\n  &#8211; On-call operations and security reviews<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds a simple, real authentication flow:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A web page lets users sign up\/sign in with <strong>email\/password<\/strong> using Identity Platform.<\/li>\n<li>A Cloud Run backend verifies the user\u2019s <strong>ID token<\/strong> and returns a protected response.<\/li>\n<\/ul>\n\n\n\n<p>This demonstrates the most important production concept: <strong>your backend must verify tokens<\/strong> and enforce authorization.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Implement Identity Platform email\/password authentication for a web client and secure a Cloud Run API by verifying Identity Platform ID tokens with the Firebase Admin SDK.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create and configure a Google Cloud project.\n2. Enable Identity Platform and turn on the Email\/Password provider.\n3. Register a web application to obtain client configuration.\n4. Run a local static web page that signs up\/signs in users and prints an ID token.\n5. Deploy a Cloud Run service that validates the ID token and returns user identity.\n6. Validate end-to-end and clean up resources.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create or select a Google Cloud project<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open the Google Cloud console: https:\/\/console.cloud.google.com\/<\/li>\n<li>Select an existing project or create a new one (recommended for a lab).<\/li>\n<li>Ensure <strong>Billing<\/strong> is enabled for the project.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have a project ID and billing is active.<\/p>\n\n\n\n<p>Verify with CLI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud projects list\ngcloud config set project YOUR_PROJECT_ID\ngcloud billing projects describe YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs (Cloud Run, Identity)<\/h3>\n\n\n\n<p>Enable Cloud Run and supporting services:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable run.googleapis.com \\\n  cloudbuild.googleapis.com \\\n  artifactregistry.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>Identity Platform enablement is often done via console, and it may enable required identity APIs automatically. You can still review enabled APIs in <strong>APIs &amp; Services<\/strong>.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Cloud Run API is enabled and you\u2019re ready to deploy.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Enable and configure Identity Platform (Email\/Password)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the Google Cloud console, go to <strong>Identity Platform<\/strong>.\n   &#8211; Direct link (may prompt to pick project): https:\/\/console.cloud.google.com\/customer-identity<\/li>\n<li>Click <strong>Enable Identity Platform<\/strong> (if not already enabled).<\/li>\n<li>Go to <strong>Providers<\/strong>.<\/li>\n<li>Enable <strong>Email\/Password<\/strong> authentication.\n   &#8211; If there is a separate toggle for email link\/passwordless, enable only what you need for the lab.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: Email\/Password provider is enabled.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; You should see Email\/Password marked as enabled in the Identity Platform Providers list.<\/p>\n\n\n\n<p><strong>Common issue<\/strong>\n&#8211; If you don\u2019t see Identity Platform in the console menu, use the direct link above and confirm you\u2019re in the correct project.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Register a Web application and collect client config<\/h3>\n\n\n\n<p>Identity Platform client apps typically use Firebase-style configuration (API key, auth domain, etc.). The console UX may vary, but you need the <strong>web app configuration<\/strong>.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In <strong>Identity Platform<\/strong>, find <strong>Applications<\/strong> (or an equivalent section for app registration).<\/li>\n<li>Add a <strong>Web<\/strong> application.<\/li>\n<li>Copy the configuration values displayed (commonly includes fields like <code>apiKey<\/code>, <code>authDomain<\/code>, <code>projectId<\/code>, etc.).<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have a set of web config values to use in your client.<\/p>\n\n\n\n<blockquote>\n<p>If the console flow differs, follow the official \u201cget started\u201d guide for Identity Platform web sign-in and obtain the equivalent configuration for the client SDK. Verify in official docs.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Run a local web client (static HTML) for sign-up\/sign-in<\/h3>\n\n\n\n<p>Create a new folder:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir identity-platform-lab\ncd identity-platform-lab\n<\/code><\/pre>\n\n\n\n<p>Create <code>index.html<\/code> with the following content (Firebase Web SDK is commonly used for this flow; Identity Platform is closely aligned with it):<\/p>\n\n\n\n<pre><code class=\"language-html\">&lt;!doctype html&gt;\n&lt;html&gt;\n  &lt;head&gt;\n    &lt;meta charset=\"utf-8\" \/&gt;\n    &lt;title&gt;Identity Platform Lab&lt;\/title&gt;\n    &lt;style&gt;\n      body { font-family: system-ui, Arial, sans-serif; max-width: 820px; margin: 40px auto; }\n      input { display:block; margin: 8px 0; padding: 8px; width: 320px; }\n      button { margin: 8px 8px 8px 0; padding: 8px 12px; }\n      pre { background: #f6f8fa; padding: 12px; overflow: auto; }\n      .row { margin-top: 16px; }\n    &lt;\/style&gt;\n  &lt;\/head&gt;\n  &lt;body&gt;\n    &lt;h2&gt;Google Cloud Identity Platform - Email\/Password Lab&lt;\/h2&gt;\n\n    &lt;div class=\"row\"&gt;\n      &lt;label&gt;Email&lt;\/label&gt;\n      &lt;input id=\"email\" type=\"email\" placeholder=\"user@example.com\" \/&gt;\n      &lt;label&gt;Password&lt;\/label&gt;\n      &lt;input id=\"password\" type=\"password\" placeholder=\"Minimum length depends on policy\" \/&gt;\n\n      &lt;button id=\"signUp\"&gt;Sign Up&lt;\/button&gt;\n      &lt;button id=\"signIn\"&gt;Sign In&lt;\/button&gt;\n      &lt;button id=\"signOut\"&gt;Sign Out&lt;\/button&gt;\n      &lt;button id=\"getToken\"&gt;Get ID Token&lt;\/button&gt;\n    &lt;\/div&gt;\n\n    &lt;h3&gt;Status&lt;\/h3&gt;\n    &lt;pre id=\"status\"&gt;Not signed in&lt;\/pre&gt;\n\n    &lt;h3&gt;ID Token (JWT)&lt;\/h3&gt;\n    &lt;pre id=\"token\"&gt;(click \"Get ID Token\")&lt;\/pre&gt;\n\n    &lt;script type=\"module\"&gt;\n      import { initializeApp } from \"https:\/\/www.gstatic.com\/firebasejs\/10.12.5\/firebase-app.js\";\n      import {\n        getAuth,\n        createUserWithEmailAndPassword,\n        signInWithEmailAndPassword,\n        onAuthStateChanged,\n        signOut\n      } from \"https:\/\/www.gstatic.com\/firebasejs\/10.12.5\/firebase-auth.js\";\n\n      \/\/ TODO: Paste your web app config from Identity Platform here:\n      const firebaseConfig = {\n        apiKey: \"YOUR_API_KEY\",\n        authDomain: \"YOUR_AUTH_DOMAIN\",\n        projectId: \"YOUR_PROJECT_ID\",\n        appId: \"YOUR_APP_ID\"\n      };\n\n      const app = initializeApp(firebaseConfig);\n      const auth = getAuth(app);\n\n      const statusEl = document.getElementById(\"status\");\n      const tokenEl = document.getElementById(\"token\");\n\n      function setStatus(obj) {\n        statusEl.textContent = typeof obj === \"string\" ? obj : JSON.stringify(obj, null, 2);\n      }\n\n      onAuthStateChanged(auth, (user) =&gt; {\n        if (user) {\n          setStatus({ signedIn: true, uid: user.uid, email: user.email });\n        } else {\n          setStatus(\"Not signed in\");\n          tokenEl.textContent = \"(click \\\"Get ID Token\\\")\";\n        }\n      });\n\n      document.getElementById(\"signUp\").addEventListener(\"click\", async () =&gt; {\n        const email = document.getElementById(\"email\").value;\n        const password = document.getElementById(\"password\").value;\n        try {\n          const cred = await createUserWithEmailAndPassword(auth, email, password);\n          setStatus({ signedUp: true, uid: cred.user.uid, email: cred.user.email });\n        } catch (e) {\n          setStatus({ error: e.code, message: e.message });\n        }\n      });\n\n      document.getElementById(\"signIn\").addEventListener(\"click\", async () =&gt; {\n        const email = document.getElementById(\"email\").value;\n        const password = document.getElementById(\"password\").value;\n        try {\n          const cred = await signInWithEmailAndPassword(auth, email, password);\n          setStatus({ signedIn: true, uid: cred.user.uid, email: cred.user.email });\n        } catch (e) {\n          setStatus({ error: e.code, message: e.message });\n        }\n      });\n\n      document.getElementById(\"signOut\").addEventListener(\"click\", async () =&gt; {\n        await signOut(auth);\n        setStatus(\"Not signed in\");\n      });\n\n      document.getElementById(\"getToken\").addEventListener(\"click\", async () =&gt; {\n        const user = auth.currentUser;\n        if (!user) {\n          tokenEl.textContent = \"No user is signed in.\";\n          return;\n        }\n        const token = await user.getIdToken(\/* forceRefresh *\/ true);\n        tokenEl.textContent = token;\n      });\n    &lt;\/script&gt;\n  &lt;\/body&gt;\n&lt;\/html&gt;\n<\/code><\/pre>\n\n\n\n<p>Now serve it locally. If you have Python:<\/p>\n\n\n\n<pre><code class=\"language-bash\">python3 -m http.server 8080\n<\/code><\/pre>\n\n\n\n<p>Open:\n&#8211; http:\/\/localhost:8080\/<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>:\n&#8211; You can sign up with an email and password.\n&#8211; Clicking <strong>Get ID Token<\/strong> prints a JWT.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; After sign-in, the Status pane shows <code>{ signedIn: true, uid: ..., email: ... }<\/code>.<\/p>\n\n\n\n<p><strong>Common errors and fixes<\/strong>\n&#8211; <code>auth\/invalid-api-key<\/code> or <code>auth\/configuration-not-found<\/code>:\n  &#8211; Confirm you pasted the correct config from the Identity Platform application registration.\n&#8211; <code>auth\/operation-not-allowed<\/code>:\n  &#8211; Email\/Password provider might not be enabled in Identity Platform.\n&#8211; <code>auth\/unauthorized-domain<\/code>:\n  &#8211; You must add <code>localhost<\/code> (or your dev domain) to <strong>Authorized domains<\/strong> (location varies in console; verify in docs).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Build a token-verifying backend and deploy to Cloud Run<\/h3>\n\n\n\n<p>Create a backend folder:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir backend\ncd backend\nnpm init -y\nnpm install express firebase-admin\n<\/code><\/pre>\n\n\n\n<p>Create <code>server.js<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-js\">import express from \"express\";\nimport admin from \"firebase-admin\";\n\nconst app = express();\napp.use(express.json());\n\n\/\/ On Cloud Run, Application Default Credentials (ADC) are available automatically.\n\/\/ This initializes Firebase Admin using the Cloud Run service account identity.\nadmin.initializeApp();\n\napp.get(\"\/healthz\", (req, res) =&gt; res.status(200).send(\"ok\"));\n\napp.get(\"\/private\", async (req, res) =&gt; {\n  try {\n    const authz = req.header(\"authorization\") || \"\";\n    const match = authz.match(\/^Bearer (.+)$\/i);\n    if (!match) return res.status(401).json({ error: \"Missing Bearer token\" });\n\n    const idToken = match[1];\n\n    \/\/ Verify signature, expiry, issuer\/audience as per Admin SDK.\n    const decoded = await admin.auth().verifyIdToken(idToken);\n\n    \/\/ Example: return safe identity info\n    res.json({\n      ok: true,\n      uid: decoded.uid,\n      email: decoded.email || null,\n      auth_time: decoded.auth_time,\n      issuer: decoded.iss,\n      audience: decoded.aud,\n    });\n  } catch (err) {\n    res.status(401).json({\n      error: \"Invalid token\",\n      message: err?.message || String(err),\n    });\n  }\n});\n\nconst port = process.env.PORT || 8080;\napp.listen(port, () =&gt; console.log(`Listening on ${port}`));\n<\/code><\/pre>\n\n\n\n<p>Create <code>package.json<\/code> to enable ES modules (or keep CommonJS\u2014either is fine). Replace your <code>package.json<\/code> with:<\/p>\n\n\n\n<pre><code class=\"language-json\">{\n  \"name\": \"identity-platform-backend\",\n  \"version\": \"1.0.0\",\n  \"type\": \"module\",\n  \"private\": true,\n  \"main\": \"server.js\",\n  \"scripts\": {\n    \"start\": \"node server.js\"\n  },\n  \"dependencies\": {\n    \"express\": \"^4.19.2\",\n    \"firebase-admin\": \"^12.3.1\"\n  }\n}\n<\/code><\/pre>\n\n\n\n<p>Create a <code>Dockerfile<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-dockerfile\">FROM node:20-slim\n\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm ci --omit=dev\n\nCOPY server.js .\/\n\nENV PORT=8080\nCMD [\"npm\",\"start\"]\n<\/code><\/pre>\n\n\n\n<p>Deploy to Cloud Run (choose a region):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set run\/region us-central1\ngcloud run deploy identity-platform-api \\\n  --source . \\\n  --allow-unauthenticated\n<\/code><\/pre>\n\n\n\n<p><strong>Why <code>--allow-unauthenticated<\/code>?<\/strong><br\/>\nThis lab uses application-level auth (bearer token verification). In production, you might still keep the service publicly reachable but protected by Identity Platform tokens, or you may put it behind a gateway. You can also restrict ingress and use additional controls.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Deployment succeeds.\n&#8211; You get a Cloud Run URL like <code>https:\/\/identity-platform-api-xxxx-uc.a.run.app<\/code>.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -sS https:\/\/YOUR_CLOUD_RUN_URL\/healthz\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Call the protected endpoint with an ID token<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In your local web page, sign in and click <strong>Get ID Token<\/strong>.<\/li>\n<li>Copy the JWT.<\/li>\n<li>Call the Cloud Run endpoint:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">export TOKEN=\"PASTE_ID_TOKEN_HERE\"\ncurl -sS \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  https:\/\/YOUR_CLOUD_RUN_URL\/private | jq .\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You receive JSON with <code>ok: true<\/code> and identity fields such as <code>uid<\/code> and <code>email<\/code>.<\/p>\n\n\n\n<p>If you omit the token:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i https:\/\/YOUR_CLOUD_RUN_URL\/private\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: HTTP 401 with \u201cMissing Bearer token\u201d.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have validated:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity Platform can authenticate users via email\/password.<\/li>\n<li>The client can retrieve an ID token (JWT).<\/li>\n<li>Cloud Run can verify the token using Firebase Admin SDK and return identity claims.<\/li>\n<\/ul>\n\n\n\n<p>A minimal success checklist:\n&#8211; [ ] Email\/password provider enabled\n&#8211; [ ] Able to sign up\/sign in from local client\n&#8211; [ ] JWT token printed\n&#8211; [ ] <code>\/private<\/code> returns identity JSON when token is present\n&#8211; [ ] <code>\/private<\/code> returns 401 when token is missing\/invalid<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues:<\/p>\n\n\n\n<p>1) <strong><code>auth\/unauthorized-domain<\/code> in the browser<\/strong>\n&#8211; Fix: Add <code>localhost<\/code> to authorized domains in Identity Platform settings (exact location can vary).<\/p>\n\n\n\n<p>2) <strong>Cloud Run returns <code>Invalid token<\/code><\/strong>\n&#8211; Causes:\n  &#8211; Token expired (refresh and retry)\n  &#8211; Token copied incorrectly (missing characters)\n  &#8211; Project mismatch (client config points to a different project than Cloud Run)\n&#8211; Fix:\n  &#8211; Ensure the web config is from the same Google Cloud project where Cloud Run is deployed.\n  &#8211; Force refresh token (<code>getIdToken(true)<\/code> already does this in the sample).<\/p>\n\n\n\n<p>3) <strong>Deployment fails due to permissions<\/strong>\n&#8211; Fix: Ensure your user has <code>Cloud Run Admin<\/code> and <code>Service Account User<\/code> (or broader lab roles).<\/p>\n\n\n\n<p>4) <strong>Unexpected billing<\/strong>\n&#8211; Fix:\n  &#8211; Confirm Cloud Run stays within free tier (where applicable).\n  &#8211; Avoid phone\/SMS sign-in methods in this lab.\n  &#8211; Review Identity Platform pricing SKUs and your MAU counts.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges:<\/p>\n\n\n\n<p>1) Delete the Cloud Run service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services delete identity-platform-api --region us-central1\n<\/code><\/pre>\n\n\n\n<p>2) Optionally delete the project (most complete cleanup):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects delete YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<p>3) If keeping the project:\n&#8211; Disable Identity Platform if appropriate (console)\n&#8211; Remove test users (via Identity Platform user management tools)\n&#8211; Review and reduce log retention if configured<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate environments<\/strong>: use distinct Google Cloud projects for dev\/stage\/prod.<\/li>\n<li><strong>Treat Identity Platform as the identity source<\/strong> and keep backend authorization logic centralized.<\/li>\n<li>For B2B SaaS:<\/li>\n<li>Implement <strong>tenant resolution<\/strong> carefully (email domain mapping, explicit tenant selection, or subdomain-based routing).<\/li>\n<li>Enforce tenant boundaries in <strong>every layer<\/strong> (identity, API authorization, database access).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege IAM<\/strong> for Identity Platform admins and operators.<\/li>\n<li>Require <strong>MFA<\/strong> for privileged Google accounts managing identity configuration.<\/li>\n<li>Store provider secrets (client secrets, SAML details if applicable) in <strong>Secret Manager<\/strong>.<\/li>\n<li>Protect administrative endpoints and support tooling with strong authentication and authorization.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor and alert on:<\/li>\n<li>MAU growth<\/li>\n<li>sign-in error spikes (may indicate abuse)<\/li>\n<li>SMS verification volume (if used)<\/li>\n<li>Add WAF\/rate-limiting controls (Cloud Armor) to reduce bot-driven costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep backend token verification efficient:<\/li>\n<li>Use supported libraries (Admin SDK) and avoid implementing JWT verification incorrectly.<\/li>\n<li>Avoid calling identity APIs redundantly on every request if you only need token verification.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure your backend is resilient to identity provider outages:<\/li>\n<li>If Identity Platform is temporarily unavailable, existing tokens may still verify (depending on verification method and caching)\u2014design graceful degradation.<\/li>\n<li>Keep token lifetimes and refresh strategies aligned with security requirements (verify defaults and best practices in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build runbooks for:<\/li>\n<li>sign-in outage<\/li>\n<li>provider misconfiguration<\/li>\n<li>suspicious login activity<\/li>\n<li>Centralize logs and metrics; restrict access to identity logs.<\/li>\n<li>Use <strong>infrastructure-as-code<\/strong> where possible (some Identity Platform configuration may be easier via console; verify automation options in official docs\/APIs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent naming:<\/li>\n<li>Projects: <code>myapp-dev<\/code>, <code>myapp-stg<\/code>, <code>myapp-prod<\/code><\/li>\n<li>Cloud Run services: <code>myapp-api<\/code><\/li>\n<li>Tenants: stable IDs and clear display names<\/li>\n<li>Apply labels\/tags to Cloud Run services and logging exports for chargeback.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>End-user identity<\/strong>: managed by Identity Platform (users, providers, tenants).<\/li>\n<li><strong>Admin access<\/strong>: controlled by Google Cloud IAM. Lock down who can:<\/li>\n<li>enable\/disable providers<\/li>\n<li>configure SAML\/OIDC settings<\/li>\n<li>manage tenants<\/li>\n<li>access logs and exports<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data in transit uses TLS.<\/li>\n<li>For data at rest and key management specifics, rely on Google Cloud\u2019s published security documentation and Identity Platform docs. Where you store user-related application data (DB, logs) is your responsibility.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Login endpoints are internet-facing by design.<\/li>\n<li>Your backend endpoints:<\/li>\n<li>should be HTTPS only<\/li>\n<li>should use WAF protections (Cloud Armor) and rate limiting<\/li>\n<li>should not trust the client; always verify tokens server-side<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not hardcode:<\/li>\n<li>IdP client secrets<\/li>\n<li>SAML certificates\/private keys<\/li>\n<li>Use <strong>Secret Manager<\/strong> and tight IAM.<\/li>\n<li>Rotate secrets and document rotation runbooks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and review <strong>Audit Logs<\/strong> for administrative actions.<\/li>\n<li>Restrict who can view identity-related logs and exports.<\/li>\n<li>Consider exporting relevant logs to BigQuery\/SIEM for detection\u2014ensure compliance with privacy requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Determine whether your application must comply with standards (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR).<\/li>\n<li>Identity is sensitive data. Ensure:<\/li>\n<li>data minimization<\/li>\n<li>clear retention policies<\/li>\n<li>lawful basis for processing (GDPR)<\/li>\n<li>Verify Identity Platform\u2019s compliance posture using official Google Cloud compliance resources and your legal\/compliance teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Failing to verify tokens on the backend<\/li>\n<li>Accepting tokens issued for a different project\/audience<\/li>\n<li>Over-privileged IAM for identity admins<\/li>\n<li>Leaving provider settings open (misconfigured redirect URIs)<\/li>\n<li>Allowing unlimited sign-up attempts without abuse controls<\/li>\n<li>Logging tokens or sensitive identity attributes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Implement layered defenses:<\/li>\n<li>Identity Platform for authentication<\/li>\n<li>Backend token verification + authorization checks<\/li>\n<li>WAF\/rate limiting<\/li>\n<li>Monitoring + alerts<\/li>\n<li>For B2B: enforce tenant checks in every request path.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Identity Platform evolves, confirm details in official docs. Common real-world gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Feature differences vs. Firebase Authentication<\/strong>: they are related but not identical. Some enterprise features are specific to Identity Platform.<\/li>\n<li><strong>Provider-specific complexity<\/strong>: SAML\/OIDC integrations require careful certificate\/metadata and claim mapping.<\/li>\n<li><strong>Authorized domains restrictions<\/strong>: local development and preview domains may fail until explicitly allowed.<\/li>\n<li><strong>Token verification pitfalls<\/strong>: writing your own JWT validation incorrectly can create vulnerabilities\u2014use Admin SDKs.<\/li>\n<li><strong>Revocation\/session management expectations<\/strong>: token lifetimes and revocation behavior can surprise teams (verify recommended patterns in docs).<\/li>\n<li><strong>Multi-tenancy design<\/strong>: tenant resolution logic must be deterministic and secure; avoid relying on user-controlled inputs without validation.<\/li>\n<li><strong>Pricing surprises<\/strong>:<\/li>\n<li>MAU growth can be faster than expected.<\/li>\n<li>SMS verification (if enabled) can be abused and become expensive.<\/li>\n<li><strong>Operational separation<\/strong>: mixing dev and prod users\/providers in the same project complicates incident response and compliance.<\/li>\n<li><strong>Log sensitivity<\/strong>: identity logs can contain sensitive identifiers; treat them as confidential data.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Identity Platform sits within Google Cloud\u2019s Access and resource management ecosystem but targets CIAM (customer identity). Here\u2019s how it compares.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud Identity Platform<\/strong><\/td>\n<td>CIAM for apps on Google Cloud; B2B SaaS multi-tenancy<\/td>\n<td>Managed auth, Google Cloud integration, multi-tenancy support, standard token flows<\/td>\n<td>Pricing tied to usage; some advanced identity customizations may require workarounds<\/td>\n<td>You want managed customer auth with Google Cloud-native ops and governance<\/td>\n<\/tr>\n<tr>\n<td><strong>Firebase Authentication<\/strong><\/td>\n<td>Smaller apps or Firebase-centric teams<\/td>\n<td>Very fast setup, strong client SDK ecosystem<\/td>\n<td>Enterprise\/multi-tenant requirements may push you to Identity Platform<\/td>\n<td>You\u2019re building a consumer app and don\u2019t need enterprise CIAM features<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Identity \/ Google Workspace identity<\/strong><\/td>\n<td>Workforce identity (employees)<\/td>\n<td>Central workforce IAM, device\/security policies<\/td>\n<td>Not intended as CIAM for external customers<\/td>\n<td>You need employee SSO and workforce management<\/td>\n<\/tr>\n<tr>\n<td><strong>Identity-Aware Proxy (IAP)<\/strong><\/td>\n<td>Protecting internal web apps\/admin UIs<\/td>\n<td>Simple app protection, integrates with Google identities<\/td>\n<td>Not a general CIAM for external customers; limited customization for customer auth<\/td>\n<td>You need to protect internal tools with Google sign-in<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Cognito<\/strong><\/td>\n<td>CIAM in AWS<\/td>\n<td>Managed user pools, federation, AWS integrations<\/td>\n<td>Cross-cloud complexity if your stack is on Google Cloud<\/td>\n<td>You are primarily on AWS and want native integration<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure AD B2C (External ID)<\/strong><\/td>\n<td>CIAM in Microsoft ecosystem<\/td>\n<td>Strong enterprise identity integrations, policies<\/td>\n<td>Cross-cloud complexity; different operational model<\/td>\n<td>You are primarily on Azure\/Microsoft identity stack<\/td>\n<\/tr>\n<tr>\n<td><strong>Auth0 \/ Okta Customer Identity<\/strong><\/td>\n<td>Advanced CIAM needs, extensive integrations<\/td>\n<td>Mature CIAM features, extensibility<\/td>\n<td>Additional vendor and cost; integration complexity<\/td>\n<td>You need deep CIAM features and are comfortable with a dedicated identity vendor<\/td>\n<\/tr>\n<tr>\n<td><strong>Keycloak (self-managed)<\/strong><\/td>\n<td>Custom identity, full control<\/td>\n<td>Highly customizable, self-hosted<\/td>\n<td>You operate and secure it; scaling and HA are on you<\/td>\n<td>You need maximum control and can run identity infrastructure<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Partner-facing B2B portal with tenant SSO<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A global manufacturer launches a portal for distributors and partners. Each partner wants SSO with its corporate identity provider. The portal must isolate partner users and enforce tenant-level access controls.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Identity Platform with <strong>multi-tenancy<\/strong><\/li>\n<li>Tenant-specific SAML\/OIDC provider configuration (per partner)<\/li>\n<li>Cloud Run microservices verifying tokens<\/li>\n<li>Data layer with tenant partitioning (separate schemas or separate databases depending on risk)<\/li>\n<li>Cloud Armor + HTTPS Load Balancer<\/li>\n<li>Centralized logging and audit exports to SIEM<\/li>\n<li><strong>Why Identity Platform was chosen<\/strong><\/li>\n<li>Google Cloud-native management and IAM controls<\/li>\n<li>Multi-tenant identity patterns<\/li>\n<li>Managed auth reduces operational risk<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Faster onboarding of new partners (configure a new tenant and IdP)<\/li>\n<li>Reduced password management burden<\/li>\n<li>Improved security posture through centralized token verification and auditing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS MVP with email\/password now, SSO later<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small SaaS team needs authentication for an MVP. They want email\/password today, but enterprise customers will later require SSO.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Identity Platform email\/password now<\/li>\n<li>Cloud Run backend verifying tokens<\/li>\n<li>Firestore\/Cloud SQL storing app data keyed by user ID<\/li>\n<li>Basic monitoring and alerting<\/li>\n<li><strong>Why Identity Platform was chosen<\/strong><\/li>\n<li>Quick start with email\/password<\/li>\n<li>Clear path to enterprise federation and multi-tenancy later (as needs grow)<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>MVP shipped quickly<\/li>\n<li>Minimal identity infrastructure to maintain<\/li>\n<li>Straightforward scale-up plan for B2B features<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Identity Platform the same as Firebase Authentication?<\/strong><br\/>\nThey are closely related and often use similar client\/server SDK patterns. Identity Platform is the Google Cloud CIAM offering that includes capabilities commonly associated with enterprise requirements (notably multi-tenancy). Verify exact feature differences in the official docs.<\/p>\n\n\n\n<p>2) <strong>Is Identity Platform for employees (workforce) or customers?<\/strong><br\/>\nPrimarily for <strong>customers\/external users<\/strong> (CIAM). For employees, consider Cloud Identity \/ Google Workspace identity, and IAP for protecting internal apps.<\/p>\n\n\n\n<p>3) <strong>Do I need a backend if Identity Platform already authenticates users?<\/strong><br\/>\nYes for most real apps. Identity Platform authenticates users and issues tokens, but your backend must verify tokens and enforce authorization to protect data and actions.<\/p>\n\n\n\n<p>4) <strong>What token should my SPA\/mobile app send to my API?<\/strong><br\/>\nTypically an <strong>ID token<\/strong> (JWT) in the <code>Authorization: Bearer<\/code> header. Use official SDKs and backend verification libraries.<\/p>\n\n\n\n<p>5) <strong>Can I use Identity Platform with Cloud Run?<\/strong><br\/>\nYes. A common pattern is Cloud Run verifying Identity Platform-issued tokens using the Firebase Admin SDK.<\/p>\n\n\n\n<p>6) <strong>How do I prevent users from signing up with disposable emails or bots?<\/strong><br\/>\nUse layered abuse defenses: WAF\/rate limiting (Cloud Armor), sign-up throttling, email verification flows, and monitoring. Exact built-in features vary\u2014verify in docs.<\/p>\n\n\n\n<p>7) <strong>How does multi-tenancy work conceptually?<\/strong><br\/>\nYou create separate tenants and configure identity providers per tenant. Your app identifies the tenant (by domain\/subdomain or explicit choice) and directs authentication accordingly. You must still enforce tenant authorization in your backend and data layer.<\/p>\n\n\n\n<p>8) <strong>Can I integrate enterprise SAML providers (like Okta, ADFS, Azure AD)?<\/strong><br\/>\nIdentity Platform supports SAML\/OIDC federation patterns where available. Confirm the current setup guides and limitations in official docs.<\/p>\n\n\n\n<p>9) <strong>Does Identity Platform store user passwords?<\/strong><br\/>\nFor email\/password sign-in, the service manages credential handling. Your app should never store raw passwords.<\/p>\n\n\n\n<p>10) <strong>How do I implement roles (admin\/user) with Identity Platform?<\/strong><br\/>\nAuthentication proves identity; roles are typically implemented via application authorization logic. Some systems use custom claims\u2014verify current support and recommended approach in docs.<\/p>\n\n\n\n<p>11) <strong>What happens if I delete a user in Identity Platform?<\/strong><br\/>\nThey will no longer be able to authenticate. Consider impacts on application data and implement a data lifecycle process.<\/p>\n\n\n\n<p>12) <strong>Can I use custom domains for auth endpoints?<\/strong><br\/>\nIn some configurations this is supported. Confirm current availability and setup steps in the official documentation.<\/p>\n\n\n\n<p>13) <strong>How do I handle logout for JWT-based auth?<\/strong><br\/>\nLogout is usually client-side (delete tokens). For higher security, implement token revocation strategies per official guidance and keep token lifetimes appropriate.<\/p>\n\n\n\n<p>14) <strong>What are the most common production mistakes?<\/strong><br\/>\nNot verifying tokens server-side, over-privileged IAM for identity admins, and leaving sign-up endpoints unprotected against abuse.<\/p>\n\n\n\n<p>15) <strong>How do I estimate cost?<\/strong><br\/>\nEstimate MAU, provider mix (email\/password vs federation), and SMS usage (if any). Use the official pricing page and the Google Cloud Pricing Calculator.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Identity Platform<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Identity Platform docs: https:\/\/cloud.google.com\/identity-platform\/docs<\/td>\n<td>Primary source for features, setup steps, APIs, and limitations<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Identity Platform pricing: https:\/\/cloud.google.com\/identity-platform\/pricing<\/td>\n<td>Explains MAU\/SMS and other pricing dimensions<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Model costs for Identity Platform + Cloud Run + logging<\/td>\n<\/tr>\n<tr>\n<td>Official console entry<\/td>\n<td>Identity Platform console: https:\/\/console.cloud.google.com\/customer-identity<\/td>\n<td>Where you configure providers, tenants, and applications<\/td>\n<\/tr>\n<tr>\n<td>SDK documentation<\/td>\n<td>Firebase Authentication Web SDK docs: https:\/\/firebase.google.com\/docs\/auth\/web\/start<\/td>\n<td>Common client-side SDK patterns used with Identity Platform (verify alignment for your scenario)<\/td>\n<\/tr>\n<tr>\n<td>Server verification<\/td>\n<td>Firebase Admin SDK docs: https:\/\/firebase.google.com\/docs\/admin\/setup<\/td>\n<td>Standard approach to verify tokens in backends (Cloud Run, GKE, etc.)<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center: https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures and operational best practices (not Identity Platform-specific, but valuable)<\/td>\n<\/tr>\n<tr>\n<td>Security guidance<\/td>\n<td>Google Cloud security foundations: https:\/\/cloud.google.com\/security<\/td>\n<td>Broader security posture and governance patterns for Google Cloud<\/td>\n<\/tr>\n<tr>\n<td>Samples (GitHub)<\/td>\n<td>Firebase quickstarts (Auth): https:\/\/github.com\/firebase\/quickstart-js<\/td>\n<td>Practical examples for web auth flows; adapt carefully to Identity Platform<\/td>\n<\/tr>\n<tr>\n<td>Tutorials\/labs<\/td>\n<td>Google Cloud Skills Boost: https:\/\/www.cloudskillsboost.google\/<\/td>\n<td>Hands-on labs (search for Identity Platform \/ Firebase Auth patterns)<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Google Cloud Tech (YouTube): https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Talks and demos on identity patterns and Google Cloud security<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>Google Cloud identity patterns, DevSecOps, operational best practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>Cloud fundamentals, governance, and operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops teams<\/td>\n<td>Cloud operations, monitoring, reliability practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers<\/td>\n<td>SRE principles, production operations, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams adopting automation<\/td>\n<td>AIOps concepts, monitoring automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Engineers seeking guided learning<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tooling and practices<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Independent consulting\/training<\/td>\n<td>Teams needing tailored enablement<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources<\/td>\n<td>Ops teams and DevOps practitioners<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Architecture, migrations, operational readiness<\/td>\n<td>Designing CIAM + Cloud Run architecture; setting up IAM guardrails<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps enablement and consulting<\/td>\n<td>Platform engineering, DevSecOps practices<\/td>\n<td>Implementing secure token verification patterns; building deployment pipelines<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services<\/td>\n<td>Operations, reliability, automation<\/td>\n<td>Production hardening: logging\/monitoring, WAF\/rate limiting, incident readiness<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Identity Platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>HTTP fundamentals, cookies vs tokens, TLS basics<\/li>\n<li>OAuth 2.0 and OpenID Connect concepts (at least high-level)<\/li>\n<li>JWT structure and verification basics<\/li>\n<li>Google Cloud basics:<\/li>\n<li>projects, billing, IAM<\/li>\n<li>Cloud Run fundamentals<\/li>\n<li>Cloud Logging<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Identity Platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced authorization:<\/li>\n<li>RBAC\/ABAC design<\/li>\n<li>policy engines (where appropriate)<\/li>\n<li>API management:<\/li>\n<li>Apigee or API Gateway patterns<\/li>\n<li>Threat modeling for identity:<\/li>\n<li>credential stuffing defenses<\/li>\n<li>phishing-resistant MFA strategies<\/li>\n<li>Multi-tenant SaaS architecture:<\/li>\n<li>tenant isolation strategies at data and compute layers<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ solutions engineer<\/li>\n<li>Backend engineer building secure APIs<\/li>\n<li>Platform engineer<\/li>\n<li>DevOps \/ SRE<\/li>\n<li>Security engineer (application security, IAM governance)<\/li>\n<li>Solutions architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>There is no Identity Platform-only certification. Typical relevant Google Cloud certifications include:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud Security Engineer<\/p>\n\n\n\n<p>(Verify current certification names and requirements on Google Cloud\u2019s official certification site.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a multi-tenant SaaS demo:<\/li>\n<li>tenant selection by subdomain<\/li>\n<li>tenant-specific IdP (mock or real)<\/li>\n<li>enforce tenant isolation in a database<\/li>\n<li>Add authorization:<\/li>\n<li>custom roles stored in DB and enforced in middleware<\/li>\n<li>Add operational controls:<\/li>\n<li>alert on auth error spikes<\/li>\n<li>export logs to BigQuery and build a dashboard<\/li>\n<li>Implement abuse controls:<\/li>\n<li>Cloud Armor rate limiting on signup\/login endpoints<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CIAM<\/strong>: Customer Identity and Access Management\u2014identity for external users of your apps.<\/li>\n<li><strong>IdP (Identity Provider)<\/strong>: A system that authenticates users (Google, SAML provider, OIDC provider).<\/li>\n<li><strong>JWT (JSON Web Token)<\/strong>: A signed token format commonly used for ID tokens.<\/li>\n<li><strong>ID token<\/strong>: A token that asserts user identity (often a JWT) returned after authentication.<\/li>\n<li><strong>OAuth 2.0<\/strong>: Authorization framework often used with federated identity and tokens.<\/li>\n<li><strong>OpenID Connect (OIDC)<\/strong>: Identity layer on top of OAuth 2.0, defines ID tokens and user identity claims.<\/li>\n<li><strong>SAML<\/strong>: XML-based federation standard used for enterprise SSO.<\/li>\n<li><strong>MAU (Monthly Active Users)<\/strong>: Users who authenticate during a month; a common billing metric for CIAM.<\/li>\n<li><strong>Multi-tenancy<\/strong>: A design where multiple customer organizations (tenants) share the same application with isolation.<\/li>\n<li><strong>Tenant resolution<\/strong>: Determining which tenant a user belongs to (domain\/subdomain, explicit selection, etc.).<\/li>\n<li><strong>ADC (Application Default Credentials)<\/strong>: Google Cloud mechanism for workloads (like Cloud Run) to obtain credentials.<\/li>\n<li><strong>WAF<\/strong>: Web Application Firewall, used to block attacks and abuse.<\/li>\n<li><strong>Least privilege<\/strong>: Security principle of granting only the minimum permissions necessary.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Identity Platform is Google Cloud\u2019s managed CIAM service in the <strong>Access and resource management<\/strong> category, designed to add secure user authentication and federation to your applications. It issues tokens that your backends verify to protect APIs and data, and it supports enterprise patterns like multi-tenancy for B2B SaaS.<\/p>\n\n\n\n<p>Cost is primarily driven by <strong>monthly active users<\/strong> and any <strong>phone\/SMS verification<\/strong> usage (plus indirect costs like logging and abuse protection). Security success depends on backend token verification, strong IAM controls for identity configuration, and layered defenses (WAF\/rate limiting, monitoring, and careful tenant isolation).<\/p>\n\n\n\n<p>Use Identity Platform when you need a Google Cloud-native, managed customer identity layer\u2014especially if you anticipate enterprise SSO or multi-tenant requirements. Next, deepen your implementation by adding authorization (roles\/permissions), tenant isolation, and production-grade monitoring and incident runbooks, using the official docs and pricing guidance.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Access and resource management<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[52,51],"tags":[],"class_list":["post-534","post","type-post","status-publish","format-standard","hentry","category-access-and-resource-management","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/534","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=534"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/534\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=534"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=534"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=534"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}