Hacker DirectoryHacker Directory
Continue learning
TRSave HTML ↓

WEB / WEB-14.02

Basic authentication, API keys, and bearer tokens

Basic is an HTTP authentication scheme, an API key is an application-credential design, and bearer describes possession semantics. Appearing in a request does not give them the same identity or permission meaning.

CORE · RED · BLUE · ARTIFACT · PRACTICE

1. Core · Mechanism

Read every scenario without motion

Bearer · user grant

  1. Bearer alias ready

    The client selects a bearer alias for a protected own-note action; no real credential is shown.

    Client
    bearer-duru-read alias
    Atlas API
    No request
    Trusted registry/policy
    User grant: Duru; Atlas API; read own note
  2. Bearer request arrived

    The HTTPS request carries the Bearer scheme. Parsing is not yet validity or permission.

    Client
    Waiting
    Atlas API
    Received Bearer alias; unresolved
    Trusted registry/policy
    User grant: Duru; Atlas API; read own note
  3. Registry binding resolves

    This local fixture resolves a valid credential, subject, and audience; it depicts no remote introspection.

    Client
    Waiting
    Atlas API
    Valid: subject-duru; audience Atlas API
    Trusted registry/policy
    Active grant; required scope present
  4. Action policy passes

    The own-note relationship and read permission are supplied as allowed.

    Client
    Waiting
    Atlas API
    ALLOW own note
    Trusted registry/policy
    Valid grant + resource policy passed
  5. Representation arrived

    The client receives the representation allowed for this action only.

    Client
    Own note delivered
    Atlas API
    Response: allowed
    Trusted registry/policy
    Valid grant + resource policy passed

App key · deny

  1. Application-key alias

    The key is defined for a public-cover application. The request asks for a private note.

    Client
    key-cover-app; private-note request
    Atlas API
    No request
    Trusted registry/policy
    Application attribution; no user subject
  2. Key-carrying request arrived

    X-Atlas-Key is this fixture’s product contract; no standard HTTP scheme is implied.

    Client
    Waiting
    Atlas API
    Received application key alias
    Trusted registry/policy
    Application attribution; no user subject
  3. Key recognized; user not resolved

    The registry returns an application binding. It does not create a Duru subject.

    Client
    Waiting
    Atlas API
    Key valid; user subject absent
    Trusted registry/policy
    Purpose: public cover fetch only
  4. Private action is denied

    Private-note policy requires user/resource authority; key attribution does not provide it.

    Client
    Waiting
    Atlas API
    DENY private-note action
    Trusted registry/policy
    Application attribution remains; no permission elevation
  5. Denial arrived

    The boundary between recognizing the key and delivering a private representation is preserved.

    Client
    No private representation
    Atlas API
    Response: action denied
    Trusted registry/policy
    Application attribution remains; no permission elevation

Basic · mismatch

  1. Basic candidate alias

    Base64 is the conceptual carrier; the alias is not an encoded password. HTTPS is a separate supplied condition.

    Client
    Basic alias; HTTPS supplied
    Atlas API
    No request
    Trusted registry/policy
    Local password verifier alias
  2. Basic request arrived

    The API recognizes the scheme; reversible encoding is not cryptographic proof.

    Client
    Waiting
    Atlas API
    Received Basic candidate; verification pending
    Trusted registry/policy
    Local password verifier alias
  3. Local verifier mismatch

    The supplied verification predicate is false. Even if encoding was parsed, there is no authenticated subject.

    Client
    Waiting
    Atlas API
    Credential invalid; no subject
    Trusted registry/policy
    Verifier unchanged
  4. Authentication denial arrived

    A generic failure response arrives; no private representation is delivered.

    Client
    Authentication failed; no private content
    Atlas API
    Response: authentication denied
    Trusted registry/policy
    Verifier unchanged

ACTORS · STATE · DATA FLOW

Request carriers differ from server meaning

A credential string reaching the Atlas API is only a transport observation. The server must determine its scheme, validity, represented client/subject context, and permission for the request.

A token can generally be a string representing state or authority within a protocol. Not every token is a JWT or a bearer credential, and not every API key is a user session. An opaque token can resolve through a server registry; a self-contained token can contain verifiable data. Format alone does not explain use policy.

HTTP Basic: Base64 encoding, not encryption

RFC 7617 Basic combines a user-id and password into a user-pass value represented using Base64. The Authorization header uses the Basic scheme name. This encoding is a reversible representation; it neither encrypts the password nor produces a hash verifier.

Basic needs an external secure transport, typically HTTPS/TLS. TLS protects the credential on the network; the application endpoint still handles it and needs log redaction. Seeing a Basic header alone proves neither TLS use nor successful account verification.

A server challenge uses WWW-Authenticate to identify the scheme and realm. A realm is a protection-space label, not a role or tenant-authorization document. Credential-reuse behavior relates to that protection-space context; an Authorization header is not the cookie scope mechanism.

API key: whose key, or which project?

An API key’s meaning depends on the product contract. It can support application/project attribution, quota, or a paid plan; another design can make it a service-principal credential. “API key valid” does not automatically mean an end user named Duru authenticated.

Current Google Cloud documentation illustrates the distinction: a standard API key associates a request with a billing/quota project and does not authenticate a principal; a service-account-bound authorization key is a separate type. This Google example does not require every product to use the same categories.

In the Atlas fixture, key-cover-app is an application binding limited to public-cover fetching. The registry supplies no end-user subject. Requesting Duru’s private note with this key fails the user/resource policy condition; recognition does not elevate the key into permission. An API-key header name belongs to the product API contract, not an invented universal HTTP API-key scheme.

Bearer: possession can be the proof

For a bearer credential under RFC 6750, its holder need not prove possession of a separate cryptographic key to use it. This makes token confidentiality critical. Bearer does not mean unreadable contents: an opaque string or a token with a readable JWT payload can be used as bearer.

An OAuth bearer access token is commonly sent to a resource server through Authorization: Bearer. The resource server evaluates it under its usage rules; possession does not mean every token is valid or allowed for every resource.

The fixture’s bearer-duru-read is associated in an authoritative registry with subject-duru, the Atlas API audience, and read:own-note scope. An inappropriate audience, expired/revoked state, or missing action permission is rejected at the relevant trust/policy boundary. WEB-14.03 expands local JWT claim/signature validation.

Transport, storage, and policy are separate defenses

TLS protects data in transit; it does not automatically prevent logging a token incorrectly or choosing unsuitable client storage. Putting passwords, API keys, or bearer credentials in URLs unnecessarily spreads them into history, logs, and referrers. Prefer the protocol’s protected header/body transport.

An application secret in a frontend bundle cannot stay secret. For a credential that must be delivered to the Browser, consider lifetime, storage visibility, XSS/CSRF boundaries, and server validation together. Do not conflate RFC 6750 bearer usage with cookie-based sessions merely because terminology overlaps.

Key rotation/revocation changes future acceptance of a credential; it does not magically delete every client copy. Enforce client, audience, action, and tenant scope at the server’s approved boundary. Using an API key as the only defense for sensitive resources is not an adequate general approach.

The purpose of 401, 403, and challenges

An HTTP authentication challenge differs from an application permission denial. Basic and Bearer have their own meanings within the challenge/response framework. For OAuth bearer, invalid_token and insufficient_scope are distinct reasons; status and WWW-Authenticate follow the protocol.

The API-key-denial case shows the fixture’s product policy, while Basic mismatch shows credential-verification failure. Neither is a real HTTP capture. Keep end-user responses safe and understandable while observing the deciding boundary through nonsecret internal reasons.

2. Red · Trust & Impact

Read every scenario without motion

Key is not a user

  1. The carrier type was selected

    This branch uses the application-defined X-Atlas-Key header. Its name belongs to the fixture contract, not a universal API-key authentication scheme.

    Credential carrier
    application-defined API key header
    Binding registry
    Binding not established
    Action policy
    Resource withheld
  2. Credential validity was read separately

    credentialValid=true means the key-cover-app record is recognized. Recognition alone does not establish an end-user subject for this request.

    Credential carrier
    Credential valid=true
    Binding registry
    Binding not established
    Action policy
    Resource withheld
  3. The binding kind was preserved

    bindingKind=application attribution and subject=null remain. The allowed purpose is public cover fetch; Duru’s identity is not derived from this application record.

    Credential carrier
    Credential valid=true
    Binding registry
    Application attribution; no user
    Action policy
    Resource withheld
  4. The private-action condition was evaluated

    The action read Duru private note lacks its required end-user binding. This product’s key contract grants no private-note permission, so actionAllowed=false.

    Credential carrier
    Credential valid=true
    Binding registry
    subject=null
    Action policy
    actionAllowed=false
  5. Representation delivery was withheld

    representationDelivered=false marks this negative data boundary. A key binding to a different principal in another product does not supply the missing Duru binding here.

    Credential carrier
    Validity: true
    Binding registry
    No user subject
    Action policy
    Representation withheld
  6. The carrier was not given excess authority

    This case separates a valid application credential from private-user denial. The conclusion follows registry binding and action policy, not the header name.

    Credential carrier
    Application credential recognized
    Binding registry
    No user binding
    Action policy
    Private resource withheld

Basic mismatch

  1. The carrier type was selected

    The Basic branch uses BASIC_ALIAS_NOT_BASE64. This inert label carries neither an actual Base64 credential nor a usable password.

    Credential carrier
    Basic
    Binding registry
    Binding not established
    Action policy
    Resource withheld
  2. Credential validity was read separately

    credentialValid=false is supplied. Parsing Basic or knowing its Base64 format does not establish password verification success; encoding is not encryption.

    Credential carrier
    Credential valid=false
    Binding registry
    Binding not established
    Action policy
    Resource withheld
  3. The binding kind was preserved

    bindingKind is a user-id/password candidate, but failed verification leaves subject=null. A candidate is not a trusted user context.

    Credential carrier
    Credential valid=false
    Binding registry
    Unverified candidate; no user
    Action policy
    Resource withheld
  4. The private-action condition was evaluated

    Without credential acceptance, this branch remains actionAllowed=false. Presence of a header named Authorization does not mean resource authorization occurred.

    Credential carrier
    Credential valid=false
    Binding registry
    subject=null
    Action policy
    actionAllowed=false
  5. Representation delivery was withheld

    representationDelivered=false remains. HTTPS transport protection does not turn a password mismatch into success; transport and credential outcomes are separate controls.

    Credential carrier
    Validity: false
    Binding registry
    No user subject
    Action policy
    Representation withheld
  6. The carrier was not given excess authority

    This case separates a Basic candidate from a trusted subject. Encoding format is not expanded into confidentiality, credential-validity or permission evidence.

    Credential carrier
    Credential not verified
    Binding registry
    No user binding
    Action policy
    Private resource withheld

ASSUMPTION · BOUNDARY · CONTROL

A header is not identity evidence

In a defensive review, separate scheme, presented alias, registry binding, validity, and action decision. A header named Authorization does not prove resource authorization ran; the name is a protocol convention.

If key-cover-app is recognized but subject is null, the subject binding needed for Duru’s private note is absent. Resolving a bearer token’s subject still requires action/resource policy. Correctly parsing Basic encoding also does not make password verification succeed.

Do not equate a carrier name with the authority supplied by its credential. This fixture’s application key identifies the cover service without supplying an end-user subject for a private note. Key recognized by the registry and object/action permission resolved for Duru are separate findings. Another product can bind a key to a different principal, so explain the outcome through its verified binding contract and request policy rather than the header name.

Reduce credential propagation

Raw credentials are unnecessary in logs, error messages, analytics, and cache keys. A scheme and opaque correlation alias can suffice for diagnostics. A URL-carried credential is not safe because it is Base64, and a JWT is not automatically public.

The ledger uses correlation aliases, binding kinds, and action outcomes instead of raw credentials. Encoding shape, credential validity, and resource authority can therefore be observed separately.

3. Blue · Secure development & defense

Read every scenario without motion

Binding review

  1. A credential observation was selected

    Review uses scheme, bindingKind, subject and actionAllowed together in the normal Bearer row. Correlation uses an alias rather than raw credentials.

    Carrier observation
    Bearer normal row
    Contract review
    Contract not examined
    Evidence conclusion
    No broader conclusion
  2. The contract outcome was read

    bindingKind=verified user grant and subject=subject-duru are supplied. Audience Atlas API and scope read:own-note describe this product’s grant scope.

    Carrier observation
    Bearer normal row
    Contract review
    User grant; Atlas API
    Evidence conclusion
    No broader conclusion
  3. Action or validity was compared

    action=read own note, actionAllowed=true and representationDelivered=true are recorded together. This row contains no grant for administration actions.

    Carrier observation
    Bearer normal row
    Contract review
    Own note allowed; delivered
    Evidence conclusion
    No broader conclusion
  4. A different principal type was compared

    The valid API-key row carries application attribution with subject=null. The Bearer user grant is not transferred to that separate application credential.

    Carrier observation
    Bearer normal row
    Contract review
    Binding kinds differ
    Evidence conclusion
    No broader conclusion
  5. Missing runtime evidence was separated

    The row shows declared grant and delivery decisions. Actual token validation, current revocation and browser receipt are not independently measured by this artifact.

    Carrier observation
    Bearer normal row
    Contract review
    Declared decision known
    Evidence conclusion
    Runtime validation unknown
  6. Observation concluded without carrying secrets

    Scheme and bindingKind are interpreted with subjectResolved and actionDecision. Grant scope can be explained without a raw credential, and is not extended to other resources or products.

    Carrier observation
    Bearer normal row
    Contract review
    Scope: own note
    Evidence conclusion
    Selected grant only

Transport evidence

  1. A credential observation was selected

    Review separates encoding, transport and credentialValid in the Basic mismatch row. The observation contains no actual TLS capture or certificate result.

    Carrier observation
    Basic mismatch row
    Contract review
    Contract not examined
    Evidence conclusion
    No broader conclusion
  2. The contract outcome was read

    The field Base64 is representation, not encryption describes the encoding boundary. HTTPS supplied separately marks transport as independent of credential matching.

    Carrier observation
    Basic mismatch row
    Contract review
    Encoding ≠ encryption
    Evidence conclusion
    No broader conclusion
  3. Action or validity was compared

    credentialValid=false, subject=null and actionAllowed=false are recorded. Presence of the transport condition does not change this negative decision.

    Carrier observation
    Basic mismatch row
    Contract review
    Invalid; no subject; denied
    Evidence conclusion
    No broader conclusion
  4. A different principal type was compared

    The API-key row can have validity=true with a null user subject. Basic formatting and key recognition are different controls, each evaluated under its binding contract.

    Carrier observation
    Basic mismatch row
    Contract review
    Binding kinds differ
    Evidence conclusion
    No broader conclusion
  5. Missing runtime evidence was separated

    HTTPS is supplied as a condition, but peer identity, certificate validation and post-proxy transport observations are absent. This gap does not establish that cleartext was observed either.

    Carrier observation
    Basic mismatch row
    Contract review
    Declared decision known
    Evidence conclusion
    UNKNOWN: observed TLS path
  6. Observation concluded without carrying secrets

    Basic mismatch and a transport-evidence gap are distinct findings. Adding encoded output or a raw password cannot fill that gap; transport evidence must come from its own source.

    Carrier observation
    Basic mismatch row
    Contract review
    Credential mismatch known
    Evidence conclusion
    Transport needs separate evidence

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Write down credential type and subject semantics

Define accepted schemes and credential formats for each endpoint. Does registry/token validation yield an end-user subject, service principal, or project attribution? Preserve that distinction in policy input types.

Do not automatically turn an application credential into a user session. Restrict/revoke keys according to the product contract, and separately resolve the authenticated subject/resource relationship required for a user action.

Use strong transport and redaction

Use HTTPS/TLS for sensitive transport such as Basic and bearer; endpoint-certificate validation is part of client responsibility. Also define the trusted transport boundary beyond a reverse proxy.

Prevent URL credentials and establish header/body handling and log-redaction policy. Keep server secrets out of the frontend. Preserve the distinction between credential expiry/revocation and client cleanup in the UI model.

Complete acceptance at the action boundary

After token/key recognition, enforce validity, issuer/audience or registry binding, and action permission. Basic requires a password verifier and account policy. Accepting a valid token for the wrong resource is not justified by successful format parsing.

Audit credentialType, bindingKind, subjectResolved, and actionDecision. Even without secrets or encoded values, the key-app/no-user and bearer-user/allowed distinction remains clear.

NOW APPLY IT TO THE CASE

Which principal does a recognized credential bind to?

Bearer user grants, application keys and Basic candidates represent different binding kinds. Credential recognition, transport and private-action permission are evaluated separately.

Separate decisions for verified actor, tenant relation and requested action in the case. Do not substitute authentication or proof success for object permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Credential-carrier and binding ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations
{
  "aliasesOnly": true,
  "cases": [
    {
      "case": "normal",
      "scheme": "Bearer",
      "wireShape": "Authorization: Bearer BEARER_ALIAS_ONLY",
      "credentialAlias": "bearer-duru-read",
      "bindingKind": "verified user grant",
      "subject": "subject-duru",
      "audience": "Atlas API",
      "scope": "read:own-note",
      "credentialValid": true,
      "action": "read own note",
      "actionAllowed": true,
      "representationDelivered": true
    },
    {
      "case": "api-key-private-denied",
      "scheme": "application-defined API key header",
      "wireShape": "X-Atlas-Key: KEY_ALIAS_ONLY (fixture contract, not a standard scheme)",
      "credentialAlias": "key-cover-app",
      "bindingKind": "application attribution",
      "subject": null,
      "allowedPurpose": "public cover fetch",
      "credentialValid": true,
      "action": "read Duru private note",
      "actionAllowed": false,
      "representationDelivered": false
    },
    {
      "case": "basic-mismatch",
      "scheme": "Basic",
      "wireShape": "Authorization: Basic BASIC_ALIAS_NOT_BASE64",
      "credentialAlias": "basic-candidate-alias",
      "bindingKind": "user-id/password candidate",
      "encoding": "Base64 is representation, not encryption",
      "transport": "HTTPS supplied separately",
      "credentialValid": false,
      "subject": null,
      "actionAllowed": false,
      "representationDelivered": false
    }
  ],
  "selector": {
    "xml": "<carriers><decision scheme=\"bearer\" valid=\"true\" userSubject=\"true\" allowed=\"true\" delivered=\"true\"/><decision scheme=\"api-key\" valid=\"true\" userSubject=\"false\" allowed=\"false\" delivered=\"false\"/><decision scheme=\"basic\" valid=\"false\" userSubject=\"false\" allowed=\"false\" delivered=\"false\"/></carriers>",
    "xpath": "count(/carriers/decision[@delivered=\"true\" and (@valid!=\"true\" or @userSubject!=\"true\" or @allowed!=\"true\")])",
    "expected": 0,
    "positiveFixtureXml": "<carriers><decision valid=\"true\" userSubject=\"false\" allowed=\"false\" delivered=\"true\"/></carriers>",
    "positiveExpected": 1
  }
}
wireShape
An invalid alias string describing a carrier shape; not an executable HTTP request.
bindingKind / subject
Application attribution differs from end-user context; key recognition does not verify a user.
credentialValid / actionAllowed
Recognition/validity and resource permission are separate predicates.
representationDelivered
The final result of this fixture’s private-note policy.

Authorization strings are not real credentials; the Basic alias is deliberately not Base64. The registry is local logical data. TLS, Base64, credential verification, OAuth, and actual API endpoints were not executed. The Atlas key header is only a fixture contract.

Two reality checks

Basic encrypts using Base64; bearer tokens must be JWTs.

Base64 is reversible encoding and TLS is separate protection. Bearer describes possession semantics; tokens can be opaque or self-contained.

A valid API key proves Duru authenticated and may access a private note.

Key bindings depend on the product contract and can represent an application/project or service principal. End-user subjects and resource permissions require separate resolution.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The public-cover app key is valid; the action reads Duru’s private note. Does selected delivery occur?

  1. No; application attribution is not a user grant.
  2. Yes; a valid API key suffices for all user resources.
Read the explained answer

No; application attribution is not a user grant. — Subject is null and actionAllowed=false; a valid key establishes no private-note entitlement.

Why are Basic encoding and HTTPS separate fields?

Selected lesson artifact fields; teaching example

cases[2].encoding
Base64 is representation, not encryption
cases[2].transport
HTTPS supplied separately
cases[2].credentialValid
false
  1. Basic Base64 securely encrypts credentials without a secret key.
  2. Base64 is not encryption; HTTPS transport protection is supplied separately.
Read the explained answer

Base64 is not encryption; HTTPS transport protection is supplied separately. — Basic carries a user-id/password candidate; encoding establishes neither a valid credential nor channel security.

Does Bearer carriage guarantee that a token is a JWT or that a private action is allowed?

Read the explained answer

Bearer defines possession-based carriage semantics; a token may have an opaque or structured format. The selected grant is bound to Atlas API audience/read:own-note scope. Format decoding or valid carriage alone provides no current object/action permission; the API-key header name is also application-defined here.

□ I separated the Bearer scheme from JWT format.

□ I preserved audience/scope and action policy.

Open the application console · request / response / browser
Also open request, URL, cookie and DOM examples

Sources and scope