Glitch personal access token grants full access to all projects: is this a documented error?

Question

Problem description
Glitch’s personal access tokens are created through the user settings page and are designed to allow programmatic access to the platform’s API. However, each token is granted blanket access to every project owned by the user, including all environment variables, domain settings, and project files. There is no mechanism to restrict a token to a single project or to a subset of resources.
In addition, the token does not contain an expiration timestamp. Once issued, it remains valid indefinitely until the user manually revokes it. This lack of an automatic expiration or time‑to‑live field means that a leaked or compromised token could continue to operate with full privileges for an unrestricted period.
These two characteristics—over‑privileged scope and indefinite validity—represent an unresolved design decision in Glitch’s authentication model. The platform has not published a roadmap or committed to implementing scoped or time‑bound tokens, and community requests remain unaddressed.
Specific questions

Does Glitch have an official plan to introduce scope‑based personal access tokens or to allow users to specify limited permissions?
Can users request a time‑bounded token through the API or settings interface, and if so, what parameters are required?
What is Glitch’s current policy for automatic revocation or expiration of personal access tokens, and are there any mechanisms to enforce it?

Tasadduq Burney · Answer

Answer: This is documented behavior, not an error.
Glitch personal access tokens (PATs) are intentionally scoped to the user account, granting the same privileges as the user across all owned projects, and they do not expire automatically.
Likely explanation
The platform treats a PAT as a user‑level credential rather than a project‑specific one, so the API checks the token against the user’s identity and allows any request the user could make.
Confirmed facts from Glitch’s documentation and observed behavior

Creating a PAT via Settings → API Tokens yields a token that can be used with the Glitch API to read/write any project owned by the account.
Inspecting the token (e.g., decoding the JWT) shows no scope or exp claims; the token remains valid until manually revoked.
There is no setting or API parameter to limit a token to a single project or to set a time‑to‑live.

To verify this in your own account, generate a token and call the API for two different projects; both calls will succeed.
Missing diagnostic detail: If you can share the decoded token payload (e.g., via jwt.io), we can confirm whether any scope claims are present; this would only change the recommendation if a hidden scope were found.

Glitch personal access token grants full access to all projects: is this a documented error?

Problem description

Specific questions

1 answer

Answer: This is documented behavior, not an error.

Likely explanation

Confirmed facts from Glitch’s documentation and observed behavior

Your perspective belongs here.

0 question comments