The simplest way to make Cloud Run Microsoft Entra ID work like it should

Every engineer has wrestled with identity at least once. You set up your containerized app on Cloud Run, only to spend hours wiring tokens, scopes, and service accounts. Then someone asks for single sign-on with Microsoft Entra ID, and the coffee goes cold. This guide shows how the two can actually play nice.

Cloud Run handles scalable container execution without servers or maintenance. Microsoft Entra ID (formerly Azure AD) rules authentication and access with enterprise-grade identity control. Together they form a clean zero-trust perimeter—Cloud Run exposes endpoints, Entra ID decides who gets in. What makes this combination powerful is how identity flows through workloads with no exposed credentials.

Here’s the logic. Cloud Run supports OpenID Connect, so Entra ID can act as the identity provider directly. Tokens are issued through Entra ID, verified by Cloud Run, and mapped to internal roles via IAM or workload identity federation. No need to copy secrets between environments. Authorization becomes a policy question, not a configuration nightmare. Once mapped correctly, both sides speak OIDC fluently.

Common setup patterns start with registering the Cloud Run app in Entra ID as an external service. That registration defines the redirect URI and client ID used to exchange tokens. Then, Cloud Run validates those tokens using its built‑in identity-aware proxy. The effect is tight authentication with minimal latency—each user or service call is verified against Entra ID before any container wakes up.

Quick answer: How do you connect Cloud Run with Microsoft Entra ID?
You register Cloud Run as a web application in Entra ID, enable OIDC, and point the redirect URI to your Cloud Run endpoint. Entra ID issues secure tokens, Cloud Run validates those tokens on each request, and IAM assigns permissions based on claims. The result is unified identity without manually managed secrets.

Use these best practices to keep it tidy:

• Rotate Entra ID credentials automatically using workload identity federation.
• Map users to roles inside Cloud Run IAM to simplify audits.
• Log token issuance events for SOC 2 or ISO 27001 compliance.
• Prefer group-based claims to cut down policy sprawl.
• Validate token expiration aggressively to prevent stale sessions.

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of stitching YAML together, you declare who can reach what, and hoop.dev applies the identity logic at runtime. That’s the difference between access control and access choreography.

This integration also speeds up developer onboarding. New engineers sign in via Entra ID, Cloud Run handles permissions, and everything works from the first deploy. No waiting for manual account creation, no dark corners of IAM. More velocity, fewer Slack messages begging for access.

When AI agents start interacting with these endpoints, consistent identity becomes mandatory. Entra ID tokens can constrain scope for autonomous workflows, reducing risk from prompt injection or data leakage. Cloud Run verifies every call, even from bots, ensuring a stable audit trail through automated infrastructure.

Done right, Cloud Run and Microsoft Entra ID form a quiet powerhouse: invisible security, faster deployment, and human-friendly control. Once you see it working, you stop worrying about who’s logging in and start focusing on what’s being built.

See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.