Authentication Patterns

Overview

Your Copilot Studio agent can answer questions and perform actions. But should it do those things for every user without knowing who they are? In government environments, the answer is almost always no. Authentication tells your agent who the user is, which determines what data they can access, what actions they can perform, and what gets recorded in the audit trail.

This video covers the authentication patterns you need for government agents: end-user authentication, single sign-on, service-to-service authentication for backend APIs, and secure credential management.

What You’ll Learn

• User authentication: Configuring Entra ID sign-in for your agent
• SSO: Eliminating extra sign-in prompts in Teams and web channels
• Service-to-service: Authenticating your agent to backend APIs
• Credential management: Storing, rotating, and monitoring secrets securely

Script

Hook: Identity matters for your agent

Your agent can answer questions. But should it answer every question for every user?

An agent that shows case details should only show cases the user is authorized to see. An agent that creates support tickets should know who submitted the request. An agent that accesses personnel records must verify the user’s identity before returning a single field.

Authentication tells your agent who the user is—and that changes everything about what the agent can do. It enables personalized responses, access control, and audit trails that tie every action to a specific person.

In the next ten minutes, you will configure the authentication patterns your government agent needs.

Authenticating users in your agent

User authentication serves three purposes. First, it enables personalized responses—greeting the user by name, showing their specific data, tailoring the conversation to their role. Second, it enforces access control—the agent only shows data the user is authorized to see, because downstream services receive the user’s identity and apply their own permission checks. Third, it creates audit trails—every action the agent takes is tied to a specific user, which is essential for compliance in government environments.

Copilot Studio offers three authentication settings. “No authentication” means the agent is public and has no user identity—suitable only for general informational agents with no access to sensitive data. “Authenticate with Microsoft” means users sign in with their Microsoft Entra ID account—the standard for government. “Authenticate manually” lets you configure a custom OAuth 2.0 provider, which is less common in government since most agencies already use Entra ID.

For government agents, “Authenticate with Microsoft” is the standard choice. Your users already have Entra ID accounts in your government tenant. Single sign-on is available when the agent runs in Teams or a configured web channel. Once authenticated, the agent receives user claims—name, email, user principal name, and group memberships—that you can use in your topics.

To set it up, open your agent settings and go to the Authentication section. Select “Authenticate with Microsoft.” Then choose between required and optional authentication. Required authentication means the user must sign in before the conversation starts—the agent will not respond until identity is confirmed. Optional authentication means the agent can function without sign-in but can prompt the user to authenticate when a specific topic or action requires it.

The government recommendation: use required authentication for any agent that handles sensitive data, accesses systems of record, or performs actions on behalf of the user. Use optional authentication only for public-facing informational agents where user identity is not needed for every interaction.

OAuth and SSO configuration

Single sign-on in Teams is the smoothest authentication experience. Users are already authenticated in Teams, so when they interact with your agent, there is no additional sign-in prompt. The agent silently acquires a token using the user’s existing Teams session.

To configure SSO, register your agent as an application in Entra ID within your government tenant. Create an app registration and configure the redirect URIs for your Copilot Studio agent—the documentation provides the exact URIs to use. Add API permissions, at minimum User.Read, so the agent can access basic profile information. Grant admin consent for these permissions—in government tenants, only a tenant admin can do this. Finally, link the app registration in Copilot Studio by entering the application ID and tenant ID in the authentication settings.

SSO in web chat channels requires more configuration. Your web application authenticates the user through its own sign-in flow, then performs a token exchange to pass the authenticated identity to the agent. This is more work than Teams SSO, but it enables single sign-on for agents embedded in custom government portals or intranet sites.

For custom identity providers—such as federating with another agency’s identity system—use the “Authenticate manually” option. Configure the client ID, client secret, authorization URL, token URL, and scope from the external identity provider. This is less common in government since most agencies use Entra ID, but it is available when cross-agency federation requires it.

Government-specific endpoint configuration is critical and is one of the most common sources of authentication failures. For GCC, the authority URL is login.microsoftonline.com with your GCC tenant ID. For GCC High, the authority URL is login.microsoftonline.us with your GCC High tenant ID. For DoD, the authority URL is login.microsoftonline.us with your DoD tenant ID. Token endpoints follow the same pattern. Using commercial endpoints—login.microsoftonline.com—in a GCC High or DoD environment will cause authentication to fail, often silently with no clear error message.

Multi-factor authentication policies in your Entra ID tenant apply to the agent’s sign-in flow. If your tenant requires MFA, users will be prompted during authentication. Conditional Access policies also apply—location restrictions, device compliance requirements, and risk-based policies all take effect. Most government tenants have strict MFA requirements, so test your agent’s authentication flow with MFA enabled to confirm the user experience is acceptable.

Service-to-service authentication

User authentication tells the agent who the user is. Service-to-service authentication tells backend APIs who the agent is. Both may be needed simultaneously: the user’s identity determines what data they can access, and the agent’s service identity authenticates it to the API.

Create a dedicated app registration in Entra ID for your agent’s backend calls. Assign application permissions—not delegated permissions—for service-to-service authentication. Generate a client secret or, preferably, a certificate for authentication.

The client credentials flow is the simplest service-to-service pattern. The agent’s backend call includes the client ID and client secret. Entra ID issues an access token with application-level permissions. The token is sent to the backend API in the Authorization header. The backend API validates the token and processes the request. This flow does not include user context—the API sees the application identity only.

The on-behalf-of flow is more sophisticated. The agent receives the user’s access token from the authentication step and exchanges it for a new token to call the backend API. The backend API receives a token that contains both the application identity and the user identity. This is the preferred flow when the backend needs to enforce per-user authorization—the API can check the user’s permissions before returning data.

In government environments, use certificates instead of client secrets when possible. Certificates are more secure and easier to rotate systematically. App registrations must be created in your government tenant—not in a commercial tenant. Permissions must be granted by a government tenant administrator. Service principal access should follow least-privilege principles: grant only the permissions the agent actually needs.

Here is the practical pattern. The agent authenticates the user via SSO in Teams. When the agent needs to call a backend API, it uses the on-behalf-of flow to exchange the user’s token for an API-specific token. The backend API validates the token, checks the user’s permissions, and returns only the data that user is authorized to see. The agent displays the result. The user sees only their data, the API call is authenticated, and everything is logged.

Managing credentials securely

Your agent’s integrations involve multiple types of credentials. Client secrets for app registrations. API keys for external services. Connection credentials for Power Platform connectors. Each one is a potential security risk if mismanaged.

For storage, client secrets live in Entra ID app registrations, and API keys live in Power Platform connection settings. Never store credentials in topic variables, in environment variables as plain text, or in source code. These locations are not designed for secret storage and may be visible to users or developers who should not have access.

Azure Key Vault provides the right solution. Store secrets and certificates in Key Vault within your government Azure subscription. Reference Key Vault secrets from Power Automate flows so your agent’s integrations pull credentials at runtime without hardcoding them. Key Vault enables automated rotation—you can update a secret in Key Vault without modifying the agent or its flows.

Establish a credential rotation strategy. Set expiration dates on all client secrets and certificates at creation time. A common schedule is 90 days for client secrets and one year for certificates. Document the rotation procedure and assign an owner—someone specific must be responsible for rotating each credential before it expires. Test the rotation process in a non-production environment first to confirm that updating the credential does not break the agent.

Monitor credential health proactively. Set up alerts for expiring secrets and certificates in Entra ID. Entra ID can send email notifications before credentials expire—ensure someone on your team is configured to receive them. Track credential usage in Entra ID sign-in logs to detect anomalies.

For government compliance, follow NIST 800-63 guidelines for credential management. Maintain a credential inventory that documents what secrets exist, where they are stored, who owns them, and when they expire. Include credential rotation in your security operations runbook so it is part of regular operations, not an afterthought.

Close: Authentication as a foundation

Here is what you covered. User authentication tells your agent who the user is—use “Authenticate with Microsoft” for government agents with required or optional sign-in based on the sensitivity of the data. SSO eliminates extra sign-in prompts for users in Teams and configured web channels. Service-to-service authentication secures your agent’s backend API calls using client credentials or on-behalf-of flows. Credential management keeps secrets rotated, stored securely in Key Vault, and monitored for expiration.

Authentication works in layers. User identity determines what data the user can see. Service identity authenticates the agent to backend APIs. DLP policies control which connectors can be combined. Row-level security in Dataverse enforces data access at the database level. Each layer reinforces the others.

Three things to do next. Enable “Authenticate with Microsoft” on your development agent and test the sign-in experience. Configure SSO for Teams using an app registration in your government tenant. Create a dedicated app registration for your agent’s backend API calls with least-privilege permissions.

Authentication is not a feature you add later. It is the foundation. Build it in from the start.

Sources & References

• Configure end-user authentication in Copilot Studio — Authentication options, SSO setup, and required vs. optional authentication
• Configure Azure AD authentication in Copilot Studio — Detailed guide for Entra ID app registration and configuration
• Copilot Studio documentation — Main documentation hub for agent building, topics, and platform capabilities
• Microsoft Entra ID on-behalf-of flow — Service-to-service authentication with user context