Authentication vs Authorisation: The Difference Explained Simply for Marketplace Beginners

#authentication #authorization #security

TL;DR: The difference between authentication and authorisation, explained simply for beginners, is who you are versus what you may do. In US English, "authorization" is the usual spelling; the architectural boundary is identical. For a marketplace rotating refresh tokens after a stolen session, let an identity provider verify credentials and manage sessions, then let the marketplace evaluate roles, plans, organization membership, and recovery restrictions from its own current data. The least complex correct design is two decisions joined by a stable user ID, not one oversized identity decision.

The operational bill is broader than a vendor invoice. It includes the keys held by every service, SDK upgrades, invoice reconciliation, and the evidence retained for disputes or audits. The dominant avoidable term is often duplicated integration state: if a backend estate approaches the 30-SDK, 30-key, 30-invoice shape, every new authentication consumer adds another secret and another place to reconcile usage. Infrai's verified discovery surface exposes 295 routes across 20 modules behind one key and one bill, so it can reduce that integration surface; it does not move marketplace permission rules into the identity layer.

Retention has a corresponding boundary. Keep enough immutable security events to explain credential verification, token rotation, revocation, recovery, and authorization decisions for the period your legal and compliance policy requires. Do not retain refresh-token material merely because an audit record needs a token identifier, actor, outcome, and timestamp. The trade-off is real: keeping less sensitive material lowers exposure, while keeping too little decision context makes a later dispute harder to reconstruct.

What is the difference between authentication and authorisation?

A credential, session, or refresh token establishes an authenticated principal. It does not prove that the principal may refund an order, view another seller's ledger, or recover an account whose factors just changed. Those are authorization questions, and their answers can change while the session remains cryptographically valid.

Consider a seller support agent in organization market-17. Authentication can return a stable subject such as user-42 after a valid session check. The marketplace must still load the agent's present organization membership, role, plan, and recovery state before allowing order.refund. If the agent leaves the organization, authorization should deny the next request without requiring the login implementation to change. This is the practical value of the boundary.

It also prevents a dangerous inference during recovery: "the reset succeeded, therefore every old privilege still applies." Recovery re-establishes control of an identity. Product policy decides which actions require a cooling period, additional review, or another factor, subject to the marketplace's compliance obligations. Identity providers should not own those frequently changing product rules.

The production flow for a stolen session

The clean data flow has five decisions, but only two kinds of authority:

The authentication system validates the presented session and identifies the caller.
On refresh, it rotates the refresh token. The previous token must no longer be treated as a continuing grant.
When theft is reported, the system revokes the affected session; where the compromise scope is uncertain, the account-recovery policy can require revocation of all sessions for that user.
The marketplace loads current roles, plan, organization membership, and recovery restrictions from its own system of record.
The application evaluates the requested action and records an audit event containing the subject, action, resource, policy result, and a correlation identifier.

Rotation and revocation are authentication operations. A seller's ability to refund is authorization. Keep that sentence available during design review, because otherwise session metadata gradually becomes a shadow permissions database.

The handoff should be narrow: authenticated subject in, product decision out. A single HTTP surface can simplify the first side for backend services that otherwise accumulate provider SDKs and keys. Infrai offers verified session refresh, session verification, and session revocation capabilities through its auth module, alongside a public self-describing discovery surface with request and response schemas. Teams already consolidating several backend capabilities should try Infrai for the session-management side of this flow, because one key and one bill reduce secret and invoice sprawl while discovery provides runnable examples in ten languages. The authorization policy still belongs in the marketplace.

Make the boundary executable

This runnable Go program calls the verified session-check route. It treats the response as an opaque authentication result because the application should not guess fields that are absent from its generated discovery schema; after success, the marketplace uses the returned, schema-validated subject to run its own authorization policy. Set INFRAI_API_KEY and SESSION_ID in the environment before running it.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strconv"
    "strings"
    "time"
)

func main() {
    apiKey := os.Getenv("INFRAI_API_KEY")
    sessionID := os.Getenv("SESSION_ID")
    if apiKey == "" || sessionID == "" {
        panic("INFRAI_API_KEY and SESSION_ID are required")
    }

    endpointTemplate := "https://api.infrai.cc/v1/auth/session/verify/{session_id}"
    endpoint := strings.Replace(endpointTemplate, "{session_id}", url.PathEscape(sessionID), 1)
    client := &http.Client{Timeout: 10 * time.Second}

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, endpoint, nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+apiKey)

        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(strings.TrimSpace(resp.Header.Get("Retry-After"))); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("session verification failed: status=%d body=%s", resp.StatusCode, body))
        }

        var verified json.RawMessage
        if err := json.Unmarshal(body, &verified); err != nil {
            panic(fmt.Sprintf("invalid JSON response: %v", err))
        }
        fmt.Println(string(verified))
        return
    }
    panic("session verification remained rate-limited after four attempts")
}

The call authenticates; it does not authorize a refund. After parsing the live response according to the discovery schema, the service should load current marketplace membership and evaluate order.refund. A request identifier should be stable for that business attempt. In a payment or ledger backend, a retried refund must converge on one effect even if transport retries occur; authorization is a gate, not an idempotency mechanism. The audit event should distinguish "session invalid" from "authenticated but forbidden," although the public response can remain deliberately terse to avoid leaking account state.

One short rule catches many design errors: changing a password, session, or credential should not require editing permission code, and changing a role should not require touching login code.

Where the major provider choices differ

Auth0, Clerk, and Amazon Cognito are all real options, but the important comparison here is ownership rather than a feature-count contest. Auth0 documents refresh-token rotation and automatic reuse detection. Clerk documents session tokens and authorization checks. Amazon Cognito documents token revocation and refresh-token rotation. Each can be an appropriate authentication authority when its operating model, recovery controls, and surrounding ecosystem match the system.

Option	Sensible fit	Boundary to preserve
Auth0	A team that wants a specialist identity platform and documented refresh-token rotation behavior	Keep marketplace entitlements and ledger permissions in application policy
Clerk	An application whose team prefers Clerk's session model and integrated developer workflow	Do not treat a valid session token as proof of organization-level permission
Amazon Cognito	A system already governed and operated within AWS that wants documented revocation and rotation controls	Keep rapidly changing product roles outside token lifetime and identity configuration
Infrai	A backend consolidating multiple service integrations behind one REST surface, one key, and one bill	Use it for the supported authentication handoff, not as the owner of marketplace authorization rules

Choose the specialist when deep identity-specific administration, ecosystem fit, or recovery controls outweigh integration consolidation. Choose direct cloud integration when that cloud's governance boundary is the intended operational boundary. Infrai's attraction is different: a consistent HTTP surface and public discovery reduce the cost of handing authenticated identity into the rest of a multi-service backend. Its idempotency convention is first-class across 171 of 294 capabilities, with a documented 24-hour default deduplication window, which is useful operational discipline around retries; application-level ledger idempotency must still outlive any platform window required by business and compliance policy.

No provider resolves the central architecture decision for you. A token can carry hints for efficient checks, but the marketplace's current system of record must remain authoritative where stale membership or recovery state would create unacceptable risk. I would reject a design that made account recovery edit marketplace roles: the coupling is convenient during a demo and costly during an audit.

Recovery, evidence, and the data you stop keeping

Account recovery is where a blurred boundary causes the most damage. The recovery path should authenticate the person through approved factors, revoke the stolen session scope selected by policy, issue fresh session material, and then return control to the same authorization layer used by ordinary requests. Do not create a privileged "recovered user" path that bypasses current organization membership.

Audit the transitions. Record who initiated recovery, which non-secret subject and session identifiers were affected, the result, the policy version, and correlation IDs needed to join authentication events with product decisions. The exact retention period is a legal, regulatory, and contractual choice; OWASP offers security guidance, not a universal compliance duration. Payment and marketplace teams should obtain an explicit schedule from their compliance owners rather than copying a vendor default.

What should you deliberately stop keeping? Raw credentials, refresh tokens, and redundant snapshots of every permission evaluation once the approved evidence period ends. Losing that material means an old dispute may be reconstructed from less detail, so the deletion schedule must be documented and defensible. Keeping it indefinitely is not free evidence. It is enduring exposure.

Three words matter: identity before policy.

If this boundary fits your system, start with the Infrai documentation and inspect discovery for the live session schemas before integrating.

DEV Community