security(core): scope auth tokens with explicit CRUD permissions and server-assigned login - #7963
Open
ar2rsawseen wants to merge 1 commit into
Open
security(core): scope auth tokens with explicit CRUD permissions and server-assigned login#7963ar2rsawseen wants to merge 1 commit into
ar2rsawseen wants to merge 1 commit into
Conversation
…server-assigned login Token scope was expressed as an app list and an endpoint regex, which verify_token compared against the request path and, when present, the request's app_id. That is a data-scoping control: it does not describe what the resolved member may do, and rights.js did not carry it past token resolution, so a token authorized whatever its owner could. Login capability was likewise inferred from the token's purpose string, which is supplied by the caller at creation. Tokens now carry explicit permissions and an explicit login capability. - token_permission stores a member.permission-shaped grant on the token. rights.js intersects it with the owner's own permissions as soon as the member is loaded, before any validator authorizes anything, so every existing feature check becomes scope-aware without being touched. The intersected member does not carry global_admin. The intersection is recomputed per request, so it follows the owner's current permissions. - A grant is bounded by the credential that creates it, not by the owner. Because the intersection has already happened, params.member is that credential's authority, and isPermissionSubset refuses anything wider. An "all" grant may only be passed on by a holder of "all", since it covers features that do not exist yet. - can_login is a server-assigned property of the token. It is set where the server establishes or propagates a session (setLoggedInVariables, the renderer, the ban-warning mail), and by /i/token/create only when the creating credential holds it and the child is not narrowed. purpose returns to being a description. - Token creation, listing and deletion require a full-permission credential, since each of them hands out, exposes or revokes the owner's credentials. Tokens created before this change are unaffected: with no token_permission they are neither intersected nor re-scoped, the endpoint regex still applies to them, and /login/token still accepts the unrestricted login-purpose tokens it accepted previously. The token manager grants app, CRUD and feature permissions using the same permission grid and helpers as user management, instead of endpoint regexes. Covered by unit tests for the permission algebra and the token record, and by API tests for the create, login, list and delete boundaries. Reported through the security bug bounty program (received 2026-08-18). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replaces the token
app/endpointscoping model with explicit CRUD permissions, and makes permission to open a dashboard session an explicit, server-assigned property of the token.Why the old model could not express what it looked like it expressed. A token's
app/endpointfields are a data-scoping control:authorizer.verify_tokenmatchesendpointagainst the request path andappagainst the request'sapp_id, and only when one is present. They say nothing about what the resolved member may do, andrights.jsdid not carry them past token resolution, so once a token resolved to its owner it authorized whatever that owner could. Login capability had the same shape: it was inferred frompurpose, a string the caller supplies at creation.The model
Two new fields on
auth_tokens, both optional, so existing tokens are untouched.token_permission- amember.permission-shaped grant ({_:{a,u}, c/r/u/d:{appId:{all, allowed}}}).rights.jsintersects it with the owner's own permissions as soon as the member is loaded, before any validator authorizes anything. Every existing feature check therefore becomes scope-aware without being modified - one line at each of the 7 member-load sites.global_admin; that is the authority a scoped token was narrowed away from.can_login- server-assigned only.setLoggedInVariables, the renderer (/o/render, dashboards reports), the ban-warning mail, and OIDC (enterprise-plugins, linked below)./i/token/creategrants it only when the creating credential holds it and the child is not narrowed. It never readspurpose./login/token/:tokengates on it.purposereturns to being a description.Grants are bounded by the creating credential, not the owner. Because the intersection has already happened,
params.memberis the creating credential's authority, soisPermissionSubsetneeds no second lookup. An owner with apps A and B may hold an A-scoped token, and that token cannot produce a child that reaches B. Anallgrant may only be passed on by a holder ofall, since it covers features that do not exist yet.Token creation, listing and deletion require a full-permission credential.
/o/token/listreturns whole documents and a document's_idis the token itself, so these three endpoints hand out, expose and revoke the owner's credentials respectively.Compatibility
Tokens created before this change are unaffected: with no
token_permissionthey are neither intersected nor re-scoped, theendpointregex still applies to them, and/login/tokenstill accepts the unrestricted login-purpose tokens it accepted before. No migration, no backfill.The two documented flows keep working: the dashboard session token still authenticates API calls in place of the
api_key, and creating a login token and redirecting through/login/tokenstill works from a credential that may itself sign in.Token manager
The drawer now grants app, CRUD and feature permissions instead of endpoint regexes, reusing the same permission grid helpers as user management (
countlyAuth.permissionSetGenerator/combinePermissionObject) and the same feature list (GET /o/users/permissions). Existing tokens still render their legacyendpointvalue read-only.Tests
test/unit-tests/api.utils.rights.tokenPermissions.js- the permission algebra: subset boundaries,allpropagation, admin apps, the intersection,global_adminstripping, and permissions reduced after issue.test/unit-tests/api.utils.authorizer.tokenFields.js- the token record: field persistence,can_loginstrictness, and that the endpoint regex still applies to legacy tokens but not to permission-scoped ones.test/2.api/16.token.manager.js- create, login, list and delete boundaries.21 unit tests pass; lint clean.
Related
release.24.05: security(core): scope auth tokens with explicit CRUD permissions and server-assigned login (24.05) #7964Supersedes the earlier containment PRs #7957 / #7958, which were closed in favour of this model.
Reported through the security bug bounty program (received 2026-08-18).
🤖 Generated with Claude Code