Cryptographic Foundations and Security Tokens

Introduction

Authentication systems depend on a chain of trust. A user presents evidence of identity; a system verifies that evidence; an authorization service issues or evaluates permissions; and protected services decide whether an action is allowed. Cryptography supplies the mechanisms that make this chain dependable when communication occurs over networks controlled partly by attackers.

Cryptography does not by itself determine whether a person is entitled to access a resource. Rather, it provides confidentiality, integrity, authenticity, and non-repudiation-related evidence. Authentication and authorization systems combine these properties with identity records, policy, session management, secure software engineering, and governance.

This chapter examines hashing, message authentication codes, symmetric and asymmetric cryptography, digital signatures, certificates, public key infrastructure (PKI), key management, JSON Web Tokens (JWTs), opaque tokens, and secure secret handling. The emphasis is on applying these mechanisms correctly in full-stack systems.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the security properties and appropriate uses of cryptographic primitives.
2. Distinguish hashing, password hashing, encryption, MACs, and digital signatures.
3. Compare symmetric and asymmetric cryptography in identity architectures.
4. Explain certificates, certificate authorities, and PKI trust validation.
5. Design basic key-generation, storage, rotation, revocation, and recovery practices.
6. Analyze JWT and opaque-token architectures, including their limitations.
7. Apply secure secret-handling practices in development and production.
8. Evaluate an authentication design against realistic threats and governance requirements.

1. Security Properties and Threat Models

A security mechanism should be selected according to the property required:

A threat model identifies assets, adversaries, trust boundaries, attack capabilities, and acceptable risk. For example, an access token may be exposed through browser storage, logs, a malicious browser extension, a compromised API, or a network attacker. TLS protects traffic in transit, but it does not prevent a token from being logged by an application after decryption.

Security claims must therefore be precise. Saying that a token is “encrypted” does not establish that it is authentic. Saying that a password is “hashed” does not establish that an appropriate password-hashing function was used. Saying that a JWT is “valid” may mean only that its syntax and signature are valid; it does not necessarily mean that its issuer, audience, subject, scope, or expiry are appropriate.

2. Hashing and Password Protection

A cryptographic hash function maps an input of arbitrary length to a fixed-length digest. It should be computationally difficult to find an input producing a chosen digest (preimage resistance), a different input with the same digest as a specified input (second-preimage resistance), or any two distinct inputs with the same digest (collision resistance). Hash functions are designed to be one-way in practical use, although “one-way” is an informal description rather than a mathematical proof of impossibility.

For a hash function H, a digest can be represented as:

Here, m is the message and h is its digest. The expression does not provide confidentiality: anyone who knows m can compute H(m). Hashes are useful for integrity comparisons, content addressing, signatures, and constructions such as HMAC. Modern systems should generally use SHA-256 or SHA-512 from the SHA-2 family, or SHA-3, when a general-purpose hash is required. MD5 and SHA-1 should not be selected for new security designs because of collision weaknesses.

Password hashing

Passwords have low and uneven entropy. An attacker who obtains a database of fast hashes can test large dictionaries offline. Password storage therefore requires a deliberately slow, memory-hard password-hashing function, such as Argon2id, scrypt, or bcrypt, with parameters selected for the deployment environment.

A salt is a unique, unpredictable value stored with each password hash. It prevents identical passwords from producing identical stored values and defeats precomputed rainbow tables. A salt is not a secret. A work factor makes each guess more expensive. A password-hashing record conceptually has the form:

Here, KDF is a password key-derivation function, r is the stored result, and parameters specify memory, time, and parallelism costs. The same parameters and salt are used during verification. The password itself must never be stored.

A pepper is an additional secret kept separately from the password database, often in a secret-management system or hardware security module. It can add a layer of protection if the database alone is stolen, but it introduces operational dependencies and recovery responsibilities. It does not replace a salt or an appropriate KDF.

Password verification should use the password-hashing library’s verification function, which normally performs constant-time comparison and interprets the encoded parameters. Application developers should also support rehashing when stronger parameters become appropriate, after a successful login.

3. Message Authentication Codes

A message authentication code (MAC) provides integrity and origin authentication to parties sharing a secret key. HMAC is a widely deployed construction based on a cryptographic hash function. Conceptually:

K is the shared secret key and m is the message. A receiver recomputes the MAC and compares it using a constant-time operation. Anyone possessing K can generate valid MACs, so a MAC does not provide non-repudiation or public verifiability.

HMAC is commonly used to authenticate internal messages, webhook payloads, and some signed tokens. The key must be independent of unrelated keys, sufficiently random, and protected from disclosure. Systems should define the exact bytes being authenticated, including encoding, field ordering, and treatment of whitespace. Ambiguous serialization can cause verification inconsistencies or exploitable confusion.

A MAC does not automatically provide freshness. To prevent replay, include a nonce, timestamp with an accepted window, sequence number, or a server-side record of previously used identifiers. The design must define what happens when clocks differ or messages arrive out of order.

4. Symmetric Encryption

Symmetric cryptography uses the same secret key, or related secret keys, for encryption and decryption. It is efficient for large amounts of data and is therefore used in database encryption, file protection, and encrypted network channels.

Authenticated encryption with associated data (AEAD) is preferred because it provides confidentiality and integrity together. Common choices include AES-GCM and ChaCha20-Poly1305. AEAD accepts plaintext and optional associated data that is authenticated but not encrypted:

K is the key, N is a nonce, P is plaintext, A is associated data, C is ciphertext, and T is an authentication tag. Decryption succeeds only if the tag is valid:

The nonce generally need not be secret, but its uniqueness requirements are critical. In particular, nonce reuse with AES-GCM under the same key can seriously undermine confidentiality and integrity. Applications should use a vetted library and follow its nonce-generation requirements rather than constructing nonce schemes casually.

Associated data is useful for authenticating metadata such as a record identifier or protocol version without exposing it. If any authenticated input changes, verification must fail. Encryption alone, such as unauthenticated CBC used without a MAC, is not sufficient for modern application data.

5. Asymmetric Cryptography and Digital Signatures

Asymmetric cryptography uses a public key and a private key. The public key may be distributed; the private key must remain secret. This solves the key-distribution problem differently from symmetric systems, although it does not eliminate trust or key-management requirements.

Digital signatures provide integrity, authenticity, and public verifiability. A signer computes a signature using a private key; a verifier uses the corresponding public key:

Here, sk is the private key, pk is the public key, m is the message, and σ is the signature. A signature does not encrypt the message. Anyone with the public key can verify it, but only a holder of the private key should be able to create it, assuming the algorithm and key remain secure.

Common signature systems include RSA-PSS, ECDSA, and EdDSA. ECDSA requires careful, unique per-signature nonce generation; failures in nonce generation have historically exposed private keys. EdDSA designs reduce some implementation risks, but algorithm support and ecosystem compatibility must be considered. Libraries should be used rather than implementing signature mathematics directly.

Digital signatures are useful for signed software, API requests, identity assertions, and tokens. Verification must include more than cryptographic validity: the application should check the expected algorithm, issuer, audience, time constraints, key identifier, and application-specific claims.

Symmetric and asymmetric comparison

Modern protocols combine them. A handshake may use asymmetric cryptography to authenticate endpoints and establish a session key, after which symmetric AEAD protects application traffic efficiently.

6. Certificates and Public Key Infrastructure

A public key alone does not prove whose key it is. A certificate binds an identity or name to a public key through a digitally signed statement. In the Web PKI, a certificate authority (CA) signs certificates after applying its validation procedures. A browser or operating system trusts a set of root CA certificates and evaluates a chain from the presented certificate to a trusted root.

A certificate commonly contains a subject or subject alternative name, public key, issuer, validity interval, serial number, permitted usages, and the issuer’s signature. Modern TLS hostname verification relies primarily on the Subject Alternative Name extension. A certificate validly signed by a trusted CA can still be inappropriate if its name, validity period, key usage, or policy does not match the connection.

PKI validation includes:

1. Building a chain from the presented certificate to a trusted root.
2. Verifying each signature.
3. Checking validity periods.
4. Matching the requested hostname or identity.
5. Checking key-usage and extended-key-usage constraints.
6. Considering revocation mechanisms and local policy.

A root CA is normally self-signed and trusted through distribution to a trust store. Intermediate CAs reduce the need to use the root key frequently. Compromise of a CA or erroneous issuance can affect many relying parties; therefore, CA governance, auditing, certificate transparency, revocation, and incident response matter.

TLS certificates authenticate endpoints and help protect transport. They do not authenticate every application user, and they do not prevent an authenticated application from making an unauthorized database query. Application authorization remains necessary.

7. Key Management as a Lifecycle

Cryptographic strength is irrelevant if keys are exposed, misused, or lost. Key management includes the entire lifecycle:

• Generation: use a cryptographically secure random number generator and approved key sizes or curves.
• Registration and ownership: record purpose, owner, algorithm, creation time, and permitted systems.
• Distribution: use authenticated, encrypted channels or managed key-encryption mechanisms.
• Storage: protect private keys and secrets with a secrets manager, HSM, or equivalent control.
• Use: restrict operations through least privilege and separate signing, encryption, and authentication keys.
• Rotation: replace keys on a schedule or after risk events, while supporting controlled overlap.
• Revocation: reject compromised, expired, or decommissioned keys.
• Backup and recovery: protect backups at least as carefully as live keys and test restoration.
• Destruction: securely remove keys when retention requirements end.

Key rotation is not a substitute for detecting compromise. A system needs key identifiers and a strategy for validating old tokens or decrypting old data during a defined transition. For signing keys, publishing a current and carefully limited set of public keys allows verifiers to select a key by identifier while still enforcing issuer and algorithm policy.

Key separation reduces blast radius. A key used to sign access tokens should not also encrypt database backups. Environment-specific keys prevent a development compromise from automatically becoming a production compromise. Access to key operations should be auditable, and human administrators should use multi-factor authentication.

8. JSON Web Tokens

A JSON Web Token is a compact representation of claims. A common signed JWT has three Base64URL-encoded parts separated by periods: header, payload, and signature. The header identifies metadata such as a token type and algorithm; the payload contains claims; and the signature protects the encoded header and payload.

A signed JWT is not automatically encrypted. Anyone who obtains it can usually decode its header and payload. Confidential information should not be placed in an ordinary signed JWT. If confidentiality is required, an encrypted-token design such as JWE may be considered, although minimizing sensitive claims is usually simpler.

Typical claims include:

• iss: issuer
• sub: subject
• aud: intended audience
• exp: expiration time
• nbf: not-before time
• iat: issued-at time
• jti: unique token identifier
• scope or roles: authorization information

Time claims are conventionally expressed as NumericDate values, usually seconds since the Unix epoch. Validation should allow only a documented, small clock-skew tolerance. A verifier must explicitly require the permitted algorithm rather than trusting an algorithm value supplied by an attacker. It must also verify the signature with a trusted key, validate issuer and audience, check expiration and not-before conditions, and apply application-specific authorization rules.

JWT advantages include local verification, reduced introspection traffic, and useful interoperability between services. Disadvantages include difficult revocation, potentially large request headers, stale authorization claims, key-distribution complexity, and the danger of treating possession as permanent authorization. A short lifetime and refresh-token strategy can limit exposure, but refresh tokens themselves require strong protection.

JWT claims are assertions, not automatically current facts. If a user’s role is removed after a token is issued, a self-contained access token may remain usable until expiry unless the system implements denylisting, token-version checks, introspection, or another revocation mechanism.

9. Opaque Tokens and Introspection

An opaque token is a high-entropy reference with no meaningful client-readable claims. The authorization server stores the associated state and exposes an introspection mechanism to trusted resource servers, or the resource server uses a shared authorization gateway.

The main advantage is centralized control. Revocation and changes to scopes can take effect quickly, and internal policy details are not exposed to clients. The costs include database or network dependency, latency, availability requirements, and the need to secure introspection responses.

Opaque tokens should be generated with a cryptographically secure random generator. They must be sufficiently long to make guessing infeasible, stored securely, transmitted only over TLS, and excluded from logs. A token record should include subject, client, scopes, issuance and expiry times, and revocation state. Introspection endpoints must authenticate callers and return only the information they need.

JWT and opaque-token selection

Neither format is universally safer. The security result depends on storage, transport, validation, lifetime, revocation, and operational controls.

10. Secure Secret Handling in Full-Stack Systems

Secrets include database passwords, API keys, signing private keys, encryption keys, webhook secrets, and refresh tokens. They should not be placed in source code, committed to version control, embedded in client-side JavaScript, or printed in logs. An environment variable can be preferable to source code for simple deployments, but it is not a complete secrets-management system: process inspection, crash reports, CI logs, or accidental exposure may still reveal it.

A production design should use a secrets manager or HSM-backed service where practical. Applications should receive only the secrets and permissions they need. Secret access should be logged without logging secret values. Rotation must be tested, including what happens when a secret manager is unavailable or a previous secret must remain valid briefly during deployment.

Browser applications deserve special caution. Anything delivered to JavaScript is accessible to that execution environment and should be treated as public to the user’s browser. Long-lived tokens in local storage are vulnerable to theft by malicious JavaScript following an XSS vulnerability. A common web-session approach uses a Secure, HttpOnly, SameSite cookie, with appropriate CSRF defenses and carefully designed domain and path attributes. Cookie choices must be evaluated against cross-site workflows; SameSite is not a universal replacement for CSRF analysis.

Logs, analytics, traces, support screenshots, URLs, referrer headers, and error messages are common leakage channels. Redaction should be designed centrally and tested. Token fingerprints may sometimes support correlation, but even partial token material can create risk and must be handled carefully.

11. Illustrative Case: University Research Portal

Background

A university research portal contains participant records and allows students, supervisors, and external collaborators to access different projects. The first version stores a long-lived JWT in browser local storage. Every API accepts the token after checking only its signature and expiration.

Problem

A frontend dependency introduces an XSS vulnerability. An attacker steals a student’s token. The student’s role is later removed, but the token remains valid for six months. The API also accepts tokens issued for a different service because it does not validate the audience claim. Logs contain complete authorization headers.

Analysis

The design has multiple independent failures. Signature verification establishes that a trusted signer created the token, but it does not establish that the token is intended for this API or that the current user remains authorized. Excessive lifetime increases the replay window. Local storage increases exposure to script-based theft. Logging the header creates additional copies of the credential. The absence of a revocation or session-control mechanism prevents timely response.

Approach and solution

The university redesigns the system as follows:

1. Access tokens become short-lived and contain only necessary claims.
2. The API validates signature, issuer, audience, expiration, not-before, token type, and scopes.
3. Refresh tokens are rotated and stored in protected, Secure, HttpOnly cookies; reuse detection revokes the token family.
4. A server-side session or token-version check permits rapid account disablement for high-risk applications.
5. Authorization headers are redacted from logs and traces.
6. The frontend dependency supply chain is scanned, and a Content Security Policy is deployed.
7. Signing keys are held in a managed key service, rotated with published key identifiers, and audited.
8. Sensitive project authorization is checked against current server-side policy rather than relying solely on token claims.

Outcome

The redesign reduces the value and lifetime of a stolen access token, improves revocation, prevents cross-service token acceptance, and limits credential leakage through observability systems. It does not make XSS harmless; preventing and detecting XSS remains essential.

Learning points

Cryptographic validity is only one layer of authorization. Token format, storage, lifetime, audience, revocation, logging, key management, and application policy must be designed together.

12. Limitations, Ethics, and Governance

Cryptography can conceal activity as well as protect legitimate users. Organizations must define lawful access, retention, incident response, and data-minimization policies. Excessive collection of identity claims in tokens can create privacy risks because tokens may be copied into logs, browser history, caches, and support systems. Use the least identifying claim that satisfies the purpose.

Access decisions should be explainable and reviewable. Automated role assignment or AI-assisted identity-risk scoring may produce unfair outcomes, false positives, or opaque denial. Such systems require human oversight, documented criteria, appeal processes, testing for disparate impact, and strict limits on the data used. AI does not replace cryptographic verification or authorization policy.

Regulatory obligations vary by jurisdiction and sector, but common governance expectations include least privilege, separation of duties, auditability, breach response, secure development, retention controls, and protection of personal data. Standards and guidance from bodies such as NIST, ISO, and OWASP can support program design, but teams must adapt controls to their threat model and legal environment.

13. Professional Design Checklist

Before deploying an authentication or token system, ask:

• Is the primitive appropriate: password KDF, hash, MAC, AEAD, or signature?
• Are algorithms selected and enforced by vetted libraries?
• Are password salts unique and parameters adequate?
• Are nonces unique wherever required?
• Are issuer, audience, algorithm, key identifier, lifetime, and token type validated?
• Can access be revoked or rapidly disabled when risk requires it?
• Are tokens protected in browsers, services, logs, backups, and monitoring tools?
• Are signing, encryption, and environment keys separated?
• Is key generation, rotation, recovery, and destruction documented and tested?
• Are authorization decisions based on current policy rather than stale claims alone?
• Are security events auditable without recording secrets?
• Has the system been tested against replay, theft, substitution, downgrade, confused-deputy, and injection attacks?

Chapter Summary

Cryptographic mechanisms provide distinct properties. Hashes support integrity-related constructions but do not provide confidentiality; password hashing must be deliberately expensive and salted. MACs authenticate messages to parties sharing a secret, whereas digital signatures permit public verification. AEAD combines encryption and integrity, but nonce rules are essential. Asymmetric cryptography supports signatures and trust establishment, while symmetric cryptography efficiently protects bulk data.

Certificates bind identities to public keys through CA signatures, and PKI validation requires chain, name, time, usage, and policy checks. Key management is a lifecycle involving generation, storage, use, rotation, revocation, recovery, and destruction. JWTs support distributed verification but require strict claim and algorithm validation and can be difficult to revoke. Opaque tokens centralize control at the cost of introspection dependencies.

Secure identity systems treat secrets as high-value assets, minimize token contents and lifetimes, protect browser and server storage, redact logs, and separate cryptographic validity from authorization policy. Sound engineering combines cryptography with threat modeling, least privilege, monitoring, privacy governance, and tested operational processes.

Key Terms

Hash function: A function that maps arbitrary input to a fixed-length digest with security properties such as preimage and collision resistance.

Salt: A unique value combined with a password before password hashing.

Password KDF: A deliberately costly function used to derive a stored password verifier.

Pepper: An additional secret used with password protection and stored separately from the password database.

HMAC: A keyed message authentication construction based on a cryptographic hash.

AEAD: Authenticated encryption with associated data, providing confidentiality and integrity.

Nonce: A value intended for one-time or carefully controlled use in a cryptographic operation.

Symmetric cryptography: Cryptography using a shared secret key.

Asymmetric cryptography: Cryptography using related public and private keys.

Digital signature: A private-key-generated value that can be verified with a public key.

Certificate: A signed binding between an identity and a public key.

Certificate authority: An entity that issues and signs certificates.

PKI: The technology, policies, and processes supporting public-key trust.

Key rotation: Replacing a cryptographic key according to a schedule or risk event.

JWT: A compact token format containing claims, commonly protected by a signature.

Opaque token: A reference token whose meaning is maintained by a server.

Introspection: A process in which an authorization server reports token status and claims.

Issuer: The authority that creates a token or certificate assertion.

Audience: The intended recipient or service for a token.

Replay attack: Reuse of a previously valid message or credential.

Review Questions

Short Answer Questions

1. Why is a salt used in password hashing, and why is it not required to be secret?
2. What security properties does AEAD provide, and what is the role of associated data?
3. Distinguish a MAC from a digital signature.
4. Why does a signed JWT not necessarily provide confidentiality?
5. Name four checks that a resource server should perform when validating a JWT.

Long Answer Questions

1. Explain the lifecycle of a cryptographic key from generation through destruction, including operational controls at each stage.
2. Compare symmetric and asymmetric cryptography and explain how a modern secure channel can use both.
3. Describe certificate-chain validation in PKI and explain why a valid signature alone is insufficient.
4. Compare JWT and opaque-token architectures in terms of scalability, revocation, privacy, and operational complexity.
5. Develop a secure password-storage and account-recovery design for a university application.

Analytical / Application Questions

1. An API accepts a correctly signed token issued to Service A when the token is presented to Service B. Identify the validation failure and propose a correction.
2. A company wants immediate revocation, low latency, and dozens of independently deployed resource servers. Analyze whether JWTs, opaque tokens, or a hybrid design is most appropriate, and justify the operational trade-offs.
3. During an incident, an access token is found in application logs. Construct an incident-response plan covering containment, key or session actions, log preservation, user impact assessment, and future prevention.

Multiple Choice Questions with Answers

Question 1

Which mechanism is specifically designed for storing passwords securely?

A. AES-GCM

B. Argon2id

C. SHA-256 used directly

D. RSA encryption

Correct Answer: B. Argon2id

Question 2

What does a MAC require for both generation and verification?

A. A shared secret key

B. A trusted root certificate only

C. A private key and a public key

D. A nonce but no key

Correct Answer: A. A shared secret key

Question 3

Which statement about a normal signed JWT is correct?

A. Its payload is automatically confidential

B. Its payload can generally be decoded by anyone possessing the token

C. It cannot contain an expiration claim

D. It is always revocable without server-side state

Correct Answer: B. Its payload can generally be decoded by anyone possessing the token

Question 4

Which JWT claim identifies the intended receiving service?

A. iss

B. sub

C. aud

D. iat

Correct Answer: C. aud

Question 5

What is the primary purpose of a certificate authority in PKI?

A. To generate every user password

B. To bind identities to public keys through signed certificates

C. To encrypt all application database rows

D. To replace authorization policies

Correct Answer: B. To bind identities to public keys through signed certificates

Question 6

Why is nonce reuse dangerous in AES-GCM?

A. It makes the public key unavailable

B. It can undermine confidentiality and integrity

C. It changes a symmetric key into a public key

D. It prevents certificates from expiring

Correct Answer: B. It can undermine confidentiality and integrity

Question 7

Which property distinguishes a digital signature from a MAC?

A. A signature can be publicly verified with a public key

B. A signature always encrypts its message

C. A MAC never provides integrity

D. A MAC requires a certificate authority

Correct Answer: A. A signature can be publicly verified with a public key

Question 8

What is a principal advantage of an opaque access token?

A. It requires no server-side storage

B. Its claims are always visible to the client

C. Centralized state can support rapid revocation

D. It cannot be stolen

Correct Answer: C. Centralized state can support rapid revocation

Question 9

Which practice is safest for production signing keys?

A. Commit them to a private source repository

B. Embed them in frontend JavaScript

C. Store them in a managed secret system with restricted access

D. Print them in deployment logs

Correct Answer: C. Store them in a managed secret system with restricted access

Question 10

A token is cryptographically valid but has an audience intended for another API. What should the receiving API do?

A. Accept it because the signature is valid

B. Accept it only if the subject is an administrator

C. Reject it because the audience is incorrect

D. Decrypt it with the issuer’s private key

Correct Answer: C. Reject it because the audience is incorrect