2.2 Plan Identity Strategy

2.2 Plan Identity Strategy

Quick Answer: Pick No authentication only for public, non-sensitive agents. Use Authenticate with Microsoft for Teams and Microsoft 365 Copilot with automatic Entra ID. Use Authenticate manually (Entra ID V2 preferred, or generic OAuth2) when you need tokens, external IdPs, multi-channel auth, or SSO on custom websites. Knowledge from SharePoint/Dataverse/connectors follows the user’s access; tools may use user or maker credentials—plan least privilege either way.

Identity strategy is how you decide who the agent believes the user is, what tokens the agent can present, and which service principals connections use. AB-620 treats this as an architecture skill, not a checkbox after go-live. Authentication changes apply only after you publish the agent—build that delay into release plans.

The three authentication options

Configure under Settings → Security → Authentication.

No authentication

Use only when the agent must be public and tools/knowledge need no restricted data. Microsoft cautions that anyone with the link can interact. Data policies in Power Platform admin center can force authentication and remove this option. Tools that require user credentials will not work if the agent has no authentication.

Authenticate with Microsoft

This is the default-friendly enterprise path for internal agents in Teams and Microsoft 365 Copilot. Entra ID authentication is set up automatically for those Microsoft surfaces. Users already signed into Teams are not re-prompted unless the agent needs expanded scopes. Trade-offs:

• Not the right choice when you must publish to many non-Microsoft channels and still enforce auth—switch to Authenticate manually.
• Not available for some Dynamics 365 Customer Service handoff scenarios as documented.
• You do not get User.AccessToken / User.IsLoggedIn for calling arbitrary APIs with the user’s token—use manual auth when topics need the access token.

Authenticate manually

Supported providers include:

• Microsoft Entra ID V2 with federated credentials (preferred modern pattern)
• Microsoft Entra ID V2 with certificates
• Microsoft Entra ID V2 with client secrets
• Microsoft Entra ID (older path)
• Generic OAuth 2 for Google, Facebook, or other standards-compliant IdPs

Manual auth is the foundation for SSO, custom scopes, and token exchange. Configure client ID/secret or certificate references carefully; store secrets in enterprise-approved vaults when flows retrieve them.

Require users to sign in

For manual authentication, Require users to sign in decides whether chat starts only after authentication. Turn it on when the agent touches sensitive data. Turning it on creates the read-only system topic Require users to sign in, which escalates if sign-in fails. If you leave it off, the agent can chat anonymously until a topic or tool demands auth.

Data policies that require authentication can force this behavior. Plan policy alignment with Power Platform admins before promising anonymous web chat that still reads SharePoint.

Microsoft Entra ID as the enterprise control plane

For most AB-620 solutions, Entra ID is the identity system of record:

• Employees and guests live in the tenant
• Conditional Access, MFA, and risk policies apply to sign-in
• App registrations define redirect URIs, exposed scopes, and API permissions
• Admin consent reduces per-user consent prompts for enterprise agents

App registration planning

When you need manual Entra auth and especially SSO on a custom website, plan two app registrations:

1. Authentication app registration — enables the agent’s Entra user authentication and exposes an API scope
2. Canvas (client) app registration — represents the hosting web app or custom canvas that performs token acquisition

Do not reuse one registration for both. SSO configuration adds a token exchange URL (scope URI such as api://{app-id}/{scope}) on the agent’s authentication settings so the canvas can perform on-behalf-of style exchange without showing a login card when the user is already signed in.

SSO channel support (plan only what is supported)

SSO is supported for scenarios including custom website, Microsoft Teams (with Teams-specific SSO configuration), SharePoint, and certain Omnichannel live chat setups. It is not supported for demo website, Facebook, mobile app channel, and Azure Bot Service channels in the documented matrix—and not for Power Apps portals at time of the docs. Exam traps often offer SSO on an unsupported channel.

User identity vs service (maker) identity

Microsoft integration guidance notes that third-party connectors may prompt users for credentials they do not understand—sometimes maker credentials are appropriate, but only with governance, DLP review, and least privilege on the service account.

Knowledge rule of thumb: SharePoint, Dataverse, and enterprise connector knowledge that relies on Microsoft Search indexes content as the agent user. If user A cannot open a site, the agent must not recite that site’s secrets to user A.

Tool rule of thumb: Creating a ServiceNow ticket “as the user” preserves audit trails; creating it “as a service account” may be required for unattended agents—document the choice.

Least privilege and scopes

When configuring manual OAuth:

• Request only scopes the agent needs (profile, openid, plus resource-specific scopes)
• Avoid over-broad Graph or LOB permissions “just in case”
• Separate read vs write permissions when the IdP allows
• Prefer federated credentials or certificates over long-lived client secrets when enterprise policy requires

Inside Power Platform environments, plan security roles for:

• Makers who edit agents (environment maker / custom roles)
• Administrators who manage DLP, sharing, and environments
• Runtime access to Dataverse tables the agent reads or writes

Agent sharing (who may chat) is not the same as solution security roles (who may edit or which Dataverse rows are reachable). Design both.

Identity decisions tied to features

Some generative features assume Microsoft authentication. For example, tenant graph grounding with semantic search requires Authenticate with Microsoft; other auth modes block changing that setting. If your architecture depends on semantic index quality over SharePoint and connectors, identity choice is a functional dependency—not only a security preference.

Channels also constrain identity:

• Teams users are always in a Microsoft identity context under Authenticate with Microsoft
• Public web agents that still need Entra users need manual auth + optional SSO on the custom canvas
• External customers on non-Entra IdPs need generic OAuth2 planning (branding, token lifetime, logout)

Exam scenarios to rehearse

Scenario A: Internal HR agent only in Teams and Microsoft 365 Copilot Chat, reading SharePoint policies.
Plan: Authenticate with Microsoft; SharePoint knowledge; share agent to HR security group; no public web channel.

Scenario B: Same agent must also embed on an authenticated intranet site with silent SSO.
Plan: Authenticate manually with Entra ID; dual app registrations; token exchange URL; custom canvas MSAL code; Teams SSO configured separately if Teams remains in scope.

Scenario C: Public product FAQ agent on contoso.com with no customer accounts.
Plan: No authentication only if knowledge is public websites/docs and tools do not need user credentials; never attach private SharePoint.

Scenario D: Tool calls a LOB API with User.AccessToken.
Plan: Authenticate manually (not Authenticate with Microsoft alone); ensure scopes include the API; handle User.IsLoggedIn in topics.

Identity planning checklist

1. Classify audience: internal employees, guests, or anonymous public.
2. List channels first—auth option must support every target channel.
3. List knowledge sources that require user Entra ACL enforcement.
4. List tools that need user tokens vs service connections.
5. Choose auth option and whether sign-in is required at conversation start.
6. Design app registrations, scopes, admin consent, and SSO supportability.
7. Align environment roles, DLP, and sharing model.
8. Publish and test auth on each channel—not only the Test pane.

A coherent identity strategy keeps enterprise knowledge safe, enables SSO where supported, and prevents last-minute channel blockers on exam case studies and real deployments.