Hi Vercel Community,
I am trying to understand an unexpected interaction between Trusted Sources and Vercel Authentication on a Hobby account.
Setup:
- The target is a READY Preview deployment, not Production.
- Vercel Authentication is enabled using Standard Protection.
- Trusted Sources is enabled.
- The default “This project” trusted-source entry is present.
- The visible access summary states that matching environments are allowed and that development tokens can access Preview.
- The entry shows “Customize”, so no customized self-project rule appears to be active.
- I am using Vercel CLI 50.40.0.
OIDC verification:
I generated a new ephemeral project token and classified its JWT payload locally and only in memory.
The following checks matched:
- Environment: DEVELOPMENT
- Project identity
- Owner scope
- Subject project
- Subject owner
- Subject environment
- Team issuer
- Expected team audience
- Token validity and expiration
No token, JWT, raw claims, identifiers or personal information are included in this post.
Observed behavior:
- I made exactly one HTTPS GET request to the root path of the Preview deployment.
- The token was sent using the standard Trusted Sources OIDC mechanism.
- No protection-bypass mechanism was used.
- The response was HTTP 302.
- The redirect classified as the Vercel Authentication flow.
- I did not follow the redirect.
- No explicit Trusted Sources error message was exposed.
Expected behavior:
Based on the visible default “This project” rule, I expected the DEVELOPMENT project token to be admitted to the Preview deployment.
Actual behavior:
The request appears to fall through to Vercel Authentication.
No mutations were performed:
- No source or repository files were changed.
- Trusted Sources and Vercel Authentication were not modified.
- No custom rule, bypass, exception or environment variable was created.
- No new deployment or Production promotion was performed.
I am not claiming that this proves a Vercel defect, product failure, deployment failure or configuration failure.
Could someone clarify:
- Should the default “This project” rule admit a DEVELOPMENT project token to a Preview deployment?
- What non-visible condition could cause the request to fall through to Vercel Authentication when the visible rule and token classifications appear compatible?
- Is there a supported read-only method to determine which Trusted Sources validation check did not admit the request?
- Does
vercel project tokenin CLI 50.40.0 require any additional condition for this use case? - Is there an officially supported resolution that preserves both Vercel Authentication and Trusted Sources without creating a temporary bypass?
I can provide additional sanitized classifications if needed, but I will not publish tokens, raw JWT claims, deployment URLs, hostnames, aliases, raw headers or response bodies.
Thank you.