What you will be able to do
- Handle an MCP insufficient_scope challenge without dropping permissions already granted
- Choose an MCP client registration method and recognise when Dynamic Client Registration is only a fallback
- Assess Workload Identity Federation and SSO settings for over-broad access, long-lived credentials and login fallbacks
1.Reading 401 versus 403, and stepping up scope safely
Authorization failures on an MCP connection are signalled by status code, and each code calls for a different response. Treating them as interchangeable is where the gaps begin:
| Status code | Meaning | Usage |
|---|---|---|
| 401 | Unauthorized | Authorization required or token invalid |
| 403 | Forbidden | Invalid scopes or insufficient permissions |
| 400 | Bad Request | Malformed authorization request |
A 403 carries a WWW-Authenticate header with error="insufficient_scope" and the scope the operation needs. In the specification's example, a write call returns scope="files:write" with the description "File write permission required for this operation". The subtle gap is in how the client re-authorizes. It must request the union of the scopes it previously requested and the scopes in the new challenge. That way, permissions it already holds survive when a server issues per-operation challenges. The client then retries the original request a few times at most, and after that treats the failure as permanent. Unbounded retries count as a design flaw too.
The next read operation can fail. The spec requires the client to compute the union of its previously requested scopes and the challenged scopes, so the new request should cover both files:read and files:write.
Refresh tokens have their own rules. Clients must keep them confidential in transit and in storage, and must not assume one will be issued at all. The authorization server decides.
Sources1
2.How the MCP client proves who it is
Before any of this, the authorization server has to know the client. The specification gives an order of preference, and a design that reaches for a later option when an earlier one is available deserves a second look:
| Priority | Mechanism | When it applies |
|---|---|---|
| 1 | Pre-registered client information | Client and server have an existing relationship |
| 2 | Client ID Metadata Documents | Authorization Server advertises client_id_metadata_document_supported; the most common case, with no prior relationship |
| 3 | Dynamic Client Registration | Fallback if the Authorization Server exposes registration_endpoint |
| 4 | Prompt the user for client information | No other option is available |
Dynamic Client Registration is deprecated and survives only for backwards compatibility with authorization servers that lack Client ID Metadata Document support. With metadata documents, the checks live on both sides. The client must make sure the client_id in the document matches the document's URL exactly. The authorization server must check that the fetched document's client_id matches the URL, and must validate the redirect URIs in each authorization request against the ones listed in the document. If the server skips that redirect check, the metadata document stops constraining where authorization codes can be sent.
3.Replacing static API keys with Workload Identity Federation
Authentication gaps are not only about MCP. A workload that calls the Claude API with a long-lived sk-ant- key carries a static secret that has to be minted, stored in CI, rotated, and can leak. Workload Identity Federation (WIF) replaces that key with short-lived OIDC tokens from an identity provider you already run, such as AWS IAM, Google Cloud, GitHub Actions, Kubernetes, Entra ID or Okta. Anthropic validates the signed JWT against trust rules and returns a short-lived access token bound to a service account.
Three resources express that trust. A service account (svac_...) is a non-human identity. A federation issuer (fdis_...) registers the OIDC provider. A federation rule (fdrl_...) maps matching JWTs to a service account with a scope and a lifetime. The service account is also what improves auditing: a workspace API key is a credential, whereas a service account has credentials, which makes it easier to see which workload acted as which account.
| Setting | What the source says | Gap to look for |
|---|---|---|
| Match | At least one of subject_prefix, claims, or condition must be set; all configured matchers must pass | A broad subject_prefix with a trailing * that admits more workloads than intended |
| Authorization scope | Default workspace:developer grants the same access as a workspace API key | Keeping the default when a narrower product scope such as workspace:manage_tunnels fits |
| token_lifetime_seconds | 60 to 86400; API default 3600; wizard prefills 600 | Lifetimes stretched toward a day, eroding the short-lived benefit |
Rules are selected explicitly by ID in the exchange request, and there is no implicit rule search. Finally, WIF has a stated limit: federated authentication is only as strong as the upstream identity provider that signs the JWT. Anthropic's guidance is to pair it with IdP controls such as workload identity binding, conditional access and audit logging.
Sources3
4.Human sign-in: SSO enforcement and its failure modes
For people signing in to Claude or the Claude Console, single sign-on is configured at a parent organization. Domain verification is required before SSO can be configured, and each parent organization can be linked to only one identity provider. Parent organizations handle identity and access only. Billing and usage tracking stay with each individual organization.
Configuring SSO is not the same as enforcing it. Require SSO for Console and Require SSO for Claude are separate toggles. When SSO is not required, users can pick either the SSO option or email login, so an organization that set up SSO but left enforcement off still has an email path around its IdP. Enforcement has the opposite risk: users who are not correctly assigned to the Anthropic app in the IdP can be locked out. With several organizations under one parent, a unique IdP group per organization, used with group mappings, controls who is provisioned where and with which role. Once the domain is verified, a Restrict organization creation toggle can stop users creating new organizations, personal accounts included, on that domain.
A CISO reviewing an Agent SDK rollout learns that permission_mode is set to bypassPermissions in a batch-processing pipeline and asks which authorization controls, if any, still constrain the agent under that mode. Based on how bypassPermissions is evaluated, which of the following statements are accurate? (Select 2)(Select 2)
Correct answers: A, B — Hooks still execute and a hook that denies a call is still enforced, because hooks are evaluated before the permission mode step in the flow; An explicit ask rule configured in settings.json still forces the call through the canUseTool callback, even though the mode would otherwise auto-approve it
- A. Correct. Hooks run first in the evaluation order, ahead of deny rules, ask rules, and the permission mode step, so a hook denial still blocks the call even under bypassPermissions.
- B. Correct. Explicit ask rules are checked before the permission mode step, so a matching ask rule still routes the call to canUseTool for confirmation even when bypassPermissions would otherwise auto-approve it.
- C. allowed_tools only pre-approves the tools it lists; unlisted tools still fall through to the permission mode, where bypassPermissions approves them too. Listing a narrow set in allowed_tools does not scope or limit what bypassPermissions itself approves.
- D. disallowed_tools entries are deny rules, and deny rules are evaluated before the permission mode step and still block matching calls even in bypassPermissions mode; they are not overridden by it.
- E. plan mode explicitly routes file-edit and shell-write tools to canUseTool regardless of allow rules, while bypassPermissions auto-approves those same operations at the mode step; the two modes produce opposite outcomes for edits, not identical ones.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.On an insufficient_scope 403, the client should re-authorize requesting only the scope named in the challenge.Why is that wrong?
The client must request the union of its previously requested scopes and the challenged scopes, so that earlier grants are preserved.
Covered in Reading 401 versus 403, and stepping up scope safely
2.Dynamic Client Registration is the preferred way for an MCP client to register with a new authorization server.Why is that wrong?
Client ID Metadata Documents are the mechanism the spec recommends. DCR is deprecated and kept only for backwards compatibility.
Covered in How the MCP client proves who it is
3.Switching from API keys to Workload Identity Federation closes the credential gap by itself.Why is that wrong?
WIF depends on the upstream IdP that signs the JWT and should be paired with that IdP's own controls.
Covered in Replacing static API keys with Workload Identity Federation
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“403 | Forbidden | Invalid scopes or insufficient permissions”
↩︎ Reading 401 versus 403, and stepping up scope safely“Determine required scopes by computing the union of the client’s previously requested scope set and the scopes from the current challenge.”
↩︎ Reading 401 versus 403, and stepping up scope safely“MUST NOT assume refresh tokens will be issued; the AS retains discretion”
↩︎ Reading 401 versus 403, and stepping up scope safely“MUST keep refresh tokens confidential in transit and storage as specified in OAuth 2.1 Section 4.3”
↩︎ Reading 401 versus 403, and stepping up scope safely“Note that Dynamic Client Registration is deprecated and retained for backwards compatibility”
↩︎ How the MCP client proves who it is“Determine required scopes by computing the union of the client’s previously requested scope set and the scopes from the current challenge.”
↩︎ Exam trap 1“Note that Dynamic Client Registration is deprecated and retained for backwards compatibility”
↩︎ Exam trap 2 - 2.https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registrationOfficial docs
“Use pre-registered client information for the server if the client has it available”
↩︎ How the MCP client proves who it is“MUST validate redirect URIs presented in an authorization request against those in the metadata document”
↩︎ How the MCP client proves who it is - 3.
“short-lived OpenID Connect (OIDC) tokens instead of long-lived sk-ant-... API keys”
↩︎ Replacing static API keys with Workload Identity Federation“The default is workspace:developer, which grants the same access as a workspace API key.”
↩︎ Replacing static API keys with Workload Identity Federation“At least one of subject_prefix, claims, or condition must be set, and all configured matchers must pass for the JWT to be accepted.”
↩︎ Replacing static API keys with Workload Identity Federation“a workspace API key is a credential, while a service account has credentials”
↩︎ Replacing static API keys with Workload Identity Federation“federated authentication is only as strong as the upstream identity provider that signs the JWT”
↩︎ Exam trap 3 - 4.
“SSO enforcement might result in users being unable to log in if they are not correctly assigned to the Anthropic app in the IdP.”
↩︎ Human sign-in: SSO enforcement and its failure modes“When SSO is not required, they will have the option to choose”
↩︎ Human sign-in: SSO enforcement and its failure modes - 5.
“Each parent organization can only be linked to one Identity Provider.”
↩︎ Human sign-in: SSO enforcement and its failure modes