MODULE 10 · LESSON 10.2
Add Entra sign-in to your application
Map Entra sign-in to stable application principals.
Lesson 54 of 86 · FabrCore 2.0
Overview
Application sign-in, downstream delegated consent and Insights operator sign-in are distinct. Use immutable identifiers to map the authenticated user to a FabrCore principal; display email can change. Blazor server state must be scoped to that signed-in user.
Login establishes the application session
Entra sign-in returns a validated identity to the application through its configured authentication handler. Map stable tenant/object identifiers to the FabrCore principal. The visible email address is useful UI text but can change. A Blazor circuit should retain the current user's scoped context rather than reading another request's identity from a shared singleton.
Login does not grant every downstream permission
A successful session lets the user access your application according to your policy. Calling Graph may require different consent and a resource-specific token. The same distinction applies to cloud-console operators: their administrative identity cannot be reused as the user's delegated grant. The example configuration belongs to your application's auth integration.
Map signed-in users to principals
- Register the application and exact development/deployed redirect URIs. Configure ASP.NET Core OpenID Connect through a supported Entra integration.
- Validate tenant/issuer/audience and map the authenticated identity to the Surface/Host principal context. Keep proxy forwarding inside the trusted boundary.
- For MAUI, use a public-client browser sign-in flow and supported redirect handling. Store credentials using platform-protected facilities and clear account-specific state on sign-out.
"Microsoft365Copilot": {
"UserAuthorization": {
"DefaultHandlerName": "graph",
"AutoSignIn": true,
"PassUserTokenToAgent": true,
"Handlers": {
"graph": {
"Settings": {
"AzureBotOAuthConnectionName": "<oauth-connection-name>",
"OBOConnectionName": "ServiceConnection",
"OBOScopes": [ "https://graph.microsoft.com/.default" ]
}
}
}
}
}
public override async Task<AgentMessage> OnMessage(AgentMessage message)
{
if (message.Args?.TryGetValue("Microsoft365Copilot:UserToken", out var userToken) == true)
{
// Call Microsoft Graph / your API with Bearer userToken — acting as the user.
}
...
}
Verify sign-in and account separation
- Configure the actual application registration, authority and callback for the development app, then sign in as a test user. Inspect the resulting FabrCore principal mapping without displaying tokens.
- Sign in as a second test user and confirm a distinct workspace/agent owner. Sign out and back in; the first user's stable mapping should remain stable.
- Attempt the downstream feature before completing its required consent. Expect an actionable missing-consent/auth result rather than assuming application login authorized the resource.
This verifies application identity and scope. Resource consent is handled explicitly in lesson 10.4.
If the result is different
Do not put a confidential web-app secret into Android code. A valid ID token for one audience is not automatically a valid downstream API assertion.
Go deeper
Explore the related documentation.