noCV
ATOKEN-102 · Define token authority

Store only token verification material and a safe display prefix

Practice briefTaskIntermediate

The token-management page retrieves complete credentials from the database every time an administrator opens it.

Focused work estimate
2h 30m + prerequisites
Priority in the scenario
Medium
Engineering practice
Credential storage · Privacy

Estimated field mix

  • Security80%
  • Database engineering20%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional B2B export API uses long-lived tokens. Tokens copied between organizations can access too much, and revocation takes effect unpredictably.

Setup prerequisites

  • Create a local synthetic API and two isolated organizations.
  • Use generated disposable credentials only.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Show the full token only at initial issuance.
  • Persist one-way verification material and a nonsecret identifier.
  • List views never return reusable token material.

Implementation constraints

  • Use a mature cryptographic primitive and document verification behavior.

Verification to include

  • Issue and authenticate a disposable token.
  • Read the list and stored record; verify the raw token is absent.

Deliverables

  • Token storage contract and disclosure tests

Rollout and recovery

Migrate new tokens first; retire legacy raw-token records through explicit rotation.

Value of the work

For the engineer: Practice authorization boundaries, credential lifecycle and safe diagnostics.

For the team: Review denial paths and operational control over service access.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.