Authentication verifies that a communicating party is who it claims to be. In application security, the term covers both user authentication—logging in—and message authentication, where a recipient verifies who sent a message. It matters at every trust boundary: a payment API must distinguish a request from ACME from one forged by an attacker, and a service must not accept an unverified caller. section 4.1 section 16.1
Common authentication patterns include:
- User login: applications may ask for credentials, but externalizing login to a single sign-on (SSO) identity provider avoids making each application store usernames and passwords. section 2.1.5 section 12.1
- Federated login: OAuth2 delegates authorization, while OpenID Connect adds a standardized identity layer and ID token for verifying who the user is. section 13.3.1
- Password alternatives: WebAuthn supports biometric scanners and phishing-resistant physical security keys. section 2.1.5
- Message authentication: HMAC combines a message with a shared secret so only parties holding that secret can generate or validate an authentic result. section 4.7
- Service authentication: services prove identity with certificates, signed tokens, metadata, mutual TLS, JWTs, or request signatures, backed by a trusted certificate authority or token issuer. section 16.1
A forged service request
Suppose a billing service trusts the header X-Service-Name: order-service without checking it. An attacker can add that header, send fake invoices, modify amounts, and obtain billing data. Authentication changes the decision: the billing service verifies a certificate, token, or signature and rejects requests whose claimed identity cannot be proved. The same principle applies when a payment API verifies that a credit-card charge request came from the merchant rather than an impostor. section 16.1 section 4.1
Authentication is not the same as authorization. Authentication establishes who is making a request; authorization determines what that identity may do. It also differs from integrity and confidentiality: integrity detects alteration, confidentiality prevents unauthorized reading, and authentication identifies the sender. A plain cryptographic hash can detect changes, but HMAC adds sender authenticity; a leaked static API key remains easy to spoof and difficult to rotate. section 4.1 section 16.4
Table 4.1 Cryptography goals and algorithm types
|
Goal
|
Foundational algorithm required
|
Standards covered in the book
|
|---|---|---|
|
Integrity
|
Cryptographic hash function
|
SHA-2, SHA-3 (this chapter)
|
|
Authentication
|
Cryptographic hash function
|
HMAC using SHA-2 or SHA-3 (this chapter)
|
|
Confidentiality
|
Symmetric or public-key encryption
|
AES, RSA, ECC, JWE, Diffie-Hellman, TLS
|
|
Nonrepudiation
|
Public-key encryption
|
RSA, ECC, X.509, JWS, PKI
|
Compare authentication with integrity, confidentiality, and nonrepudiation, then relate each goal to its foundational algorithm type. section 4.1
