Good question, and you've already half answered it yourself in your first bullet.
WHY YOU GET "SITE MISSING"
That endpoint belongs to Azure Bot Service Direct Line, and it expects a Direct Line secret tied to a provisioned site. Copilot Studio never issues you one when the agent is set to Authenticate with Microsoft. With that option selected, the agent is restricted to Microsoft first party channels such as Teams and Microsoft 365 Copilot, and Direct Line isn't one of them. No Direct Line site exists for your agent, hence ResourceNotFound. The error text pointing you at the Azure Bot Service site documentation is unhelpful here, because none of that applies to a Copilot Studio agent.
Same reason the embed code disappears. It's only visible when No authentication is selected. Choose Authenticate with Microsoft or Authenticate manually and it's gone.
So to your second question: no, Direct Line can't be used while Microsoft authentication is enabled. Direct Line needs either No authentication or Authenticate manually.
WHAT YOU ACTUALLY WANT, GIVEN YOUR STATED GOAL
Don't use Direct Line. Use the Microsoft 365 Agents SDK with the Copilot Studio Client. It's built for exactly the architecture you described, and it expects Authenticate with Microsoft, so you keep the setting you already have.
1. Leave the agent on Authenticate with Microsoft
2. Go to the Channels page, select Web app or Native app, copy the connection string
3. Register your custom app in Entra ID and grant it the Copilot Studio scope
4. Your app signs the user in with MSAL and passes that token to CopilotStudioClient
5. The agent resolves the signed in user into the System.User variables, and connector actions run as that user
One app registration, real Entra ID SSO, no magic code prompts, and no Direct Line secret anywhere in your stack.
IF YOU'RE FORCED ONTO DIRECT LINE
If you have non Entra users, or you specifically need a public API rather than an SDK, the path is heavier. Switch to Authenticate manually with your own Entra ID app registration, then configure SSO for a custom canvas: a separate app registration for the canvas, define a custom scope on the agent, add that scope to the agent configuration, and handle the OAuth card token exchange in your client code. Five steps, all of them easy to get subtly wrong.
YOUR LAST QUESTION, THE FOUR TOKENS
They sit on two unrelated layers.
Transport layer, meaning "is my application allowed to talk to this agent":
Direct Line secret. Long lived channel credential. Server side only, never in a browser.
Direct Line token. Short lived, scoped to a single conversation, minted from the secret on your server. This is the one that's safe to hand to a client.
Identity layer, meaning "who is the human talking":
Authenticate with Microsoft. The agent setting that forces user sign in and populates the System.User variables.
Entra ID access token. The user's identity, acquired by your application, passed through to the agent.
They aren't alternatives, and they aren't all required together. On the Direct Line path you need all four. On the Agents SDK path the first two disappear entirely, because the Entra ID token covers both transport and identity. That collapse is the main reason to prefer it.
One last thing, since you mentioned you're new to this. Authentication changes only take effect after you republish the agent (I learned it the hard way, lol). If you switch auth modes and immediately test against the old channel configuration, you'll get misleading errors that look unrelated to what you changed.
Hope that helps. If it does, please mark it as the answer so others can find it.
