You click connect, your browser opens the vendor's login page, you approve a list of permissions, and the chat app receives a token to use on your behalf. It never sees your password. The MCP authorization specification defines the steps, and each one is a place a buyer can ask a question.
The steps in order
- The first request has no token. The chat app calls the connector and gets a 401 response with a header that points to metadata about the server.
- Discovery. The app reads that metadata to find which login server the connector trusts. The specification requires MCP servers to implement OAuth 2.0 Protected Resource Metadata.
- Client identity. The app identifies itself to the login server. The specification prefers Client ID Metadata Documents and keeps Dynamic Client Registration only for backward compatibility.
- Browser approval. The app opens a browser with a request that includes a PKCE challenge and a resource parameter naming the connector. You see a consent page and approve.
- Token exchange. The app swaps the returned code for an access token, again naming the connector as the resource.
- Calls with the token. Every request carries the token in an Authorization header, never in the URL.
Terms in plain words
| Term | Meaning |
|---|---|
| Scope | A permission, such as read findings |
| PKCE | A check that stops a stolen code from being redeemed by someone else |
| Resource parameter | Says which connector the token is for |
| Audience check | The connector refuses tokens issued for other services |
Why the details matter
The specification says servers must validate that a token was issued specifically for them, and must not accept tokens meant for other resources. The security best practices page calls accepting foreign tokens an anti-pattern because it lets one stolen token reach other services and makes audit trails unreliable.
It also describes a mix-up attack, where a hostile login server tries to get a code meant for an honest one. The specification asks clients to record the expected issuer and validate the response against it.
What you see as a user
Only the consent page. That page is your control. Read the scopes, read the connector name, and check that the address belongs to the vendor you meant. Claude's help center advises reviewing requested scopes and denying unnecessary ones.
Questions to ask the vendor
- Which login server issues tokens, and is it ours or theirs?
- What scopes exist, and what does each allow?
- How long do tokens last, and can we revoke one user?
- Does the connector reject tokens meant for another service?
A worked example: reading a consent page
This is an illustrative consent page, not a real product.
You click connect. A page opens with the vendor's name and text saying that the chat app wants permission to read project and finding summaries, read full vulnerability details, and create tickets. Below are two buttons, approve and cancel. Check these things in order.
- The address bar. It should show the vendor's own domain, over HTTPS. If it shows something else, cancel.
- The app name. It should be the chat app you meant to connect.
- The permissions. Your first question is about reading findings. Creating tickets is not needed yet, so if the page lets you untick it, do so. If not, cancel and ask the vendor for narrower scopes.
- Your account. Make sure you are signed in as the intended user, not a shared admin account.
After approving, the browser returns you to the chat app. The app holds a token. Your password never went to the chat app.
Step by step: test the sign in as a buyer
- Start with no existing session at the vendor, in a private browser window.
- Connect from the chat app and note each page.
- Approve a narrow scope set, then ask a question that needs a wider one. The specification describes the connector answering with a 403 that names the scope needed, after which the client may ask you to approve more.
- Disconnect in the chat app.
- Look at the vendor's access list. Does the grant remain? It may need revoking at the vendor too.
- Revoke it there and confirm calls fail.
- Write down the lifetime of the token if the vendor states it.
Table: what can go wrong in the flow
| Weak point | What the specification asks for |
|---|---|
| Stolen authorization code | PKCE, so the code is useless alone |
| Token for the wrong service | Resource parameter and audience validation |
| Hostile login server | Check the issuer recorded earlier against the response |
| Dangerous redirect address | Clients validate URL schemes and avoid shells |
| Tokens in links | Tokens must not appear in the URL query string |
Which of these you can test
As a buyer you cannot test the client's internals, but you can test the connector's behavior: refusals without a token, refusals with a token for another service, scope behavior, and revocation. Ask the chat provider and the vendor which parts of the specification they implement.
Refresh tokens
The specification says clients must keep refresh tokens confidential and must not assume they will be issued. Ask the vendor how long sessions last and how a refresh is handled, because a long lived refresh token raises the value of a stolen one.
Notes for administrators
Where an admin adds a connector for a team, each member still signs in. Make sure the sign in screens users see match what you approved, and tell them what to decline.
Where Safeguard fits
Safeguard offers agent identity and an MCP Guardrail for teams that need accountable identities for agents calling tools. You can also look at real output with the free scan before you wire anything up.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice where sign in and permissions appear in the setup, and compare them with the consent page example above.
Quick check
Does the chat app store my password?
No. With OAuth you sign in at the vendor's page and the app receives a token, per Claude's help center.
What is a 401 versus a 403 here?
The specification uses 401 for missing or invalid tokens and 403 for a valid token with insufficient permissions.
Is OAuth enough on its own?
No. It identifies the user and limits scope, but you still need tool approvals, logging and review of what the tools can do.
Sources
- MCP specification, authorization
- MCP security best practices
- Claude Help Center, custom connectors using remote MCP
Last reviewed: 19 October 2026.
