Project Token and Native/Public OAuth both return HTTP 403
dmackp
HOBBYOP

a month ago

We’re troubleshooting a production application issue and are attempting to use Railway’s documented read-only API authentication methods to inspect deployment/service state.

We have now tested both of the following authentication paths:

  • Native/Public OAuth with PKCE
  • Railway Project Token authentication

Both are returning HTTP 403 despite matching the documented authentication flow.

For OAuth, we verified:

  • Native/Public application
  • PKCE S256
  • no client secret
  • successful browser authorization/consent
  • successful callback
  • valid state/redirect/PKCE flow
  • documented token endpoint

The authorization-code exchange still returned HTTP 403.

We then tested a Railway Project Token created from the project’s Settings → Tokens page and scoped to the production environment.

For direct GraphQL authentication we used the documented:

Project-Access-Token

header and the documented Project Token identity query:

query {

projectToken {

projectId

environmentId

}

}

The first request returned HTTP 403.

We then performed one controlled retry after:

  • recreating/re-entering the token securely
  • confirming the token was created from Project Settings → Tokens
  • confirming the production environment was selected
  • confirming there was no leading/trailing whitespace or embedded newline
  • revalidating the endpoint, header, and query

The retry also returned HTTP 403.

We have not performed repeated retries or any Railway mutations.

Current behavior:

Native/Public OAuth:

HTTP 403 during token exchange

Project Token:

HTTP 403 during projectToken identity query

Controlled Project Token retry:

HTTP 403 again

Could you clarify:

  1. Are there any account, workspace, project, or environment-level restrictions that could cause a valid Project Token to receive HTTP 403 from the GraphQL API?
  2. Is Project-Access-Token still the correct header for Project Token authentication?
  3. Is projectToken { projectId environmentId } still the recommended identity query for validating a Project Token?
  4. Is there any additional permission or configuration required for production-scoped Project Tokens?
  5. Are there any known issues affecting Project Token or Native/Public OAuth authentication that may not appear on the general Railway status page?

We’re intentionally avoiding further retries until we understand the rejection reason.

Solved

1 Replies

Status changed to Awaiting Railway Response Railway • about 1 month ago


dizzydes90
EMPLOYEE

a month ago

Project-Access-Token is still the correct header for a Project Token, and projectToken { projectId environmentId } is still the correct query to validate one, so your request shape is right. Project Tokens are scoped to a single environment and only resolve that token's own project and environment, so they aren't used for account-level queries.

When a token is actually invalid or lacks scope, our API returns a JSON "Not Authorized" error (or a not-found on the projectToken query), not a bare HTTP 403. A top-level 403 carrying a Cloudflare ray ID and no error body, hitting both the token exchange and GraphQL the same way, means the request is being rejected before it reaches token authentication, so this is not a problem with the token or its scope.


Status changed to Awaiting User Response Railway • about 1 month ago


Railway
BOT

a month ago

This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!

Status changed to Solved Railway • about 1 month ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...