Innomerc Learn
English is the default.
A worked example

How credentials are checked

One exchange at a time. Read what changes, then explain it in your own words before moving on.

  1. Meet the components
  2. Follow the steps
  3. Compare an example
  4. Check your understanding
Interactive Lab

How credentials are checked

See the difference between storage, proof, validation and authorization.

Steps1. Signed token 2. Trusted public key 3. Validated claims 4. Allowed response
Click a box or choose its name to learn what it means.
ClientReadyVerifierReadyCredential storeReadyResourceReadyClientReadyVerifierReadyCredential storeReadyResourceReady
Ready to traceJWT validation
Before you start · 4 stepsJWT validation

A readable token is not a trusted token; validate claims before authorization.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Client

    A program that asks another system for information or an action.

    Example: A shopping app requests a list of products from a service.

  • Verifier

    The system checking whether the presented proof is acceptable.

    Example: A sign-in service checks a submitted password against its stored password verifier.

  • Credential store

    Storage for authentication-related records. It should not hold passwords as readable text.

    Example: A service stores salted password hashes and account information.

  • Resource

    The information or action someone wants permission to use.

    Example: A private document or an account setting is a resource.

JWT validation

A readable token is not a trusted token; validate claims before authorization.

  1. Client Verifier: Signed token. The request includes a token, not its signing key.
  2. Credential store Verifier: Trusted public key. Resolve trusted verification material; this may be cached.
  3. Verifier Resource: Validated claims. Check issuer, audience and lifetime, then evaluate permissions.
  4. Resource Client: Allowed response. Only an authorized operation returns protected data.

Server session

An opaque cookie identifies server-side session state.

  1. Client Verifier: Session cookie. The browser sends an opaque session identifier.
  2. Verifier Credential store: Lookup session. The service reads the associated state.
  3. Credential store Verifier: User + expiry. Expiry and revocation affect the result.
  4. Verifier Resource: Identity context. Resource authorization is still required.

Password hashing

Use a password KDF such as Argon2id with a unique salt and suitable cost.

  1. Client Verifier: Password over TLS. The verifier receives the candidate in a protected connection.
  2. Credential store Verifier: Salt + KDF settings. Retrieve the stored salt, parameters and verifier.
  3. Verifier Credential store: Compare verifier. Compare computed and stored verifier safely; do not store plaintext.
  4. Verifier Client: Decision. Apply rate limits and additional factors where required.

Refresh token

Renewal is a separate credential flow, not an extension of an expired access token.

  1. Client Resource: Expired token. The resource rejects an expired access token.
  2. Client Verifier: Refresh credential. The client presents its refresh credential to the authorization server.
  3. Verifier Client: New access token. Issue a new token only after the refresh policy succeeds.
  4. Client Resource: Retry with token. The resource validates the new token and requested permissions.

API key

An API key is a credential with scope, expiry and revocation policy—not necessarily a user identity.

  1. Client Verifier: API key. The client presents a secret credential over TLS.
  2. Verifier Credential store: Lookup policy. Check status, expiry and configured permissions.
  3. Verifier Resource: Scoped caller. Authorize this operation under the credential’s policy.

Authorization failure

Authentication can succeed while the requested object remains forbidden.

  1. Client Verifier: Valid credentials. The verifier establishes who the caller is.
  2. Verifier Resource: Other user’s object. The application checks the target owner and action.
  3. Resource Client: 403 · denied. Protected content is not returned.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.