# Firebase token in. No secret anywhere.

> Validate the token. Deploy with a managed identity.

- **Format:** short video, 9 steps, ~51 seconds
- **Topic:** Firebase Authentication in ASP.NET Core for a Microsoft Foundry agent API: issuer and audience checks, roles from custom claims, and deployment to Azure App Service with a managed identity so no secret exists.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Published:** 2026-05-30
- **Tags:** firebase, aspnetcore, azure, managedidentity, security, dotnet, microsoftfoundry, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/foundry-firebase-token-no-secrets/

---
## What you'll learn

- How to validate a Firebase ID token in .NET
- Where roles must come from
- How a managed identity removes secrets

## Understand it one step at a time

### 1. A real token

The Flutter app signs in with Firebase and gets an ID token.

### 2. Issuer and audience

Issuer securetoken.google.com/PROJECT_ID, audience the project ID.

### 3. The 401 that names nothing

A bare 401 hides the real mismatch. The exception message names it.

### 4. Roles from claims

Set with the Admin SDK. Never from a field the client sends.

### 5. No secret to leak

App Service gets a system-assigned managed identity.

### 6. Foundry User, for the app

The identity gets the Foundry User role on the project.

### 7. SQL without a password

CREATE USER FROM EXTERNAL PROVIDER. The local password stays local.

### 8. Smoke test

200 with a token, 401 without, and an answer from the agent.

### 9. Token in, no secret anywhere

Roles from custom claims, and a managed identity for Foundry and SQL.

---

## The takeaway

**Token in. No secret anywhere.**

Roles from custom claims, then a managed identity so no key exists to leak.