Authentication Response

A short-lived credential granting access to specific resources. It is a bearer token, typically a JWT (JSON Web Token), containing claims about the user and permissions. The client includes this token in the Authorization header of API requests.

• Format: Usually a JWT with a header, payload, and signature.
• Lifespan: Designed to be ephemeral (e.g., 1 hour) to limit risk if compromised.
• Scope: Defines the specific APIs or data the token can access.

A long-lived credential used to obtain a new access token without requiring the user to re-authenticate. It is stored securely (e.g., in an HTTP-only cookie) and sent only to the authorization server's token endpoint.

• Purpose: Enables seamless user sessions while maintaining security through short-lived access tokens.
• Security: Highly sensitive; its compromise allows an attacker to obtain new access tokens. Often paired with rotation and revocation mechanisms.

A JWT issued by an OpenID Connect (OIDC) provider that contains identity claims about the authenticated user. It is intended for the client application, not for API access.

• Contents: Standard claims like sub (subject), email, name, and iss (issuer).
• Use Case: Allows the client app to create a local session and personalize the UI.
• Verification: The client must validate the token's signature, issuer, and audience.

Metadata defining the token's characteristics and validity period. Critical for clients to handle tokens correctly.

• token_type: Usually Bearer, indicating how the token is presented (in the Authorization header).
• expires_in: The lifetime of the access token in seconds (e.g., 3600).
• scope: The space-separated list of permissions granted, which may be a subset of what was requested.

Authentication responses follow standardized formats to ensure interoperability. The most common is the OAuth 2.0 Token Response (RFC 6749).

• Example JSON: {"access_token":"eyJ...", "token_type":"Bearer", "expires_in":3600, "refresh_token":"def...", "id_token":"ghi..."}
• Content-Type: Always application/json.
• Error Responses: Use a different structure with error and error_description fields.

The primary credential granting access to protected resources. It's a cryptographically signed token (like a JWT) containing claims about the user and permissions. The client includes this token in the Authorization header of subsequent API requests.

• Structure: Typically a JSON Web Token (JWT) with a header, payload, and signature.
• Lifetime: Short-lived for security (e.g., 1 hour).
• Purpose: Proves the user's authenticated session without repeatedly sending credentials.

A long-lived credential used to obtain a new Access Token when the current one expires. It is issued alongside the access token but stored securely by the client and sent only to the authentication server's token refresh endpoint.

• Security: Must be kept more secure than the access token, often in an HTTP-only cookie.
• Revocation: Can be invalidated by the server to force re-authentication.
• Flow: Enables persistent sessions without requiring the user to re-enter their password.

Specifies how the Access Token should be used by the client. The most common value is Bearer, as defined in RFC 6750, indicating the token is a bearer credential.

• Example: "token_type": "Bearer"
• Usage: Informs the client to place the token in the Authorization: Bearer <token> header.
• Other Types: Less common types include MAC or DPoP for additional security proofs.

The lifetime of the Access Token in seconds. This tells the client application how long the token is valid before a new one must be obtained via the Refresh Token or a new authentication flow.

• Example: "expires_in": 3600 (1 hour)
• Client Logic: Applications use this value to schedule token refresh operations proactively.
• Security: Short expiration times limit the window for a stolen token to be misused.

A space-separated list of permissions granted to the Access Token. It defines the specific resources and actions the token authorizes, implementing the principle of least privilege.

• Example: "scope": "read:profile write:transactions"
• Authorization: The resource server checks the token's scope against the requested action.
• User Consent: Often presented to the user during the authorization grant step (OAuth2).

A JSON Web Token (JWT) introduced by OpenID Connect (OIDC) that contains claims about the authenticated user's identity. It is intended for the client application, not the resource server.

• Contents: Includes standard claims like sub (subject/user ID), email, name.
• Verification: The client must validate the JWT's signature and issuer.
• Purpose: Provides identity information to enable single sign-on (SSO) and user profile data.

Advanced Authentication Responses can delegate authority to a session key, a limited-use key for specific actions. This enables:

• Gasless transactions sponsored by the dApp
• Time-bound permissions (e.g., valid for 24 hours)
• Action-specific scopes (e.g., only permit NFT approvals) This pattern, used by ERC-4337 smart accounts and ERC-6551 token-bound accounts, enhances UX while maintaining security boundaries.

In decentralized identity systems like W3C Verifiable Credentials, the Authentication Response contains cryptographically verifiable claims. These are not just proof of wallet ownership but attestations from issuers about:

• KYC/AML status
• Proof-of-humanity
• Professional accreditation The response is typically a JSON Web Token (JWT) or a W3C Verifiable Presentation, allowing dApps to request specific user attributes.

Conceptually similar to an OAuth 2.0 authorization code grant, but with key Web3 distinctions:

• Self-custody: Proof comes from a digital signature, not a centralized issuer.
• Minimal disclosure: Users can prove specific claims (e.g., age > 18) without revealing full identity.
• Interoperability: Responses use open standards (EIP-4361, JWTs) instead of proprietary vendor formats. The response is the user's direct, verifiable answer to an authentication challenge.

DApp backends must rigorously validate every Authentication Response to prevent attacks:

• Verify the ECDSA signature against the claimed Ethereum address.
• Check the domain field matches the dApp's origin.
• Validate nonce uniqueness to block replay attacks.
• Enforce expiration-time and reject stale messages.
• Audit statement content to ensure user awareness. Failure to validate correctly can lead to session hijacking and impersonation.

The W3C standard format for Authentication Responses, enabling cryptographically secure, privacy-preserving proofs. A VC is a tamper-evident credential with metadata, claims, and proofs that can be verified by any party.

• Structure: Contains issuer DID, subject DID, claim data, proof signature, and expiration.
• Selective Disclosure: Allows users to reveal only specific attributes (e.g., age > 18) without exposing the entire credential.
• Interoperability: Standardized format ensures credentials work across different systems and blockchains.

The act of presenting a VC to a verifier creates a Verifiable Presentation, which introduces security risks.

• Replay Attacks: A malicious actor intercepts and re-uses a presentation. Mitigated by including nonces and audience restrictions in the proof.
• Presentation Integrity: The presentation itself is signed, binding it to a specific holder's DID and the verifier's challenge.
• Timestamp Validity: Verifiers must check credential issuance date and expiration to prevent use of stale credentials.

The foundational identifier for subjects and issuers in an Authentication Response, decoupled from central registries.

• Self-Sovereignty: Users control their DID and its associated private keys, stored in a wallet.
• DID Document: Resolves to a public document containing public keys and service endpoints for authentication.
• Sybil Resistance: DIDs can be anchored on a blockchain, providing a global, immutable root of trust without revealing personal data.

Advanced cryptographic method for creating Authentication Responses that prove a claim without revealing the underlying data.

• Privacy Maximization: Proves statements like "I am over 21" or "my credit score > 700" without disclosing birthdate or actual score.
• ZK-SNARKs / ZK-STARKs: Common proof systems used to generate succinct, verifiable proofs.
• Computational Overhead: Generating ZKPs is computationally intensive, a trade-off for enhanced privacy.

Mechanisms to invalidate Authentication Responses before their expiration, a critical security control.

• Revocation Registries: A privacy-preserving method (e.g., accumulators) where the verifier checks if a credential's ID is not on a blacklist.
• Status List 2021: A W3C standard using bitstrings to encode revocation status for many credentials efficiently.
• Real-Time Verification: Verifiers must perform a live status check, introducing a dependency on the issuer's availability.

The security of the Authentication Response is only as strong as the user's custody of private keys.

• Seed Phrase Loss: Losing the wallet's mnemonic seed means permanent loss of identity and all associated credentials.
• Key Compromise: If a device holding private keys is hacked, an attacker can create fraudulent presentations.
• Social Engineering: Major attack vector targeting users to reveal seeds or approve malicious signature requests.