Authorization
Two-Factor Authentication (2FA) is a security process requiring users to provide two distinct forms of identification to verify their identity before accessing an account or system.
Two-Factor Authentication (2FA) is a method of multi-factor authentication (MFA) that enhances security by requiring two distinct authentication factors to verify a user's identity. These factors are typically categorized into three types: something the user knows (e.g., password, PIN), something the user has (e.g., a physical token, smartphone, smart card), and something the user is (e.g., fingerprint, facial scan). A common implementation involves a password (knowledge factor) combined with a one-time password (OTP) generated by an authenticator app or sent via SMS (possession factor). The process begins with the user entering their primary credential, usually a password. Upon successful validation of the first factor, the system requests the second factor. The validity of the second factor is then checked against a pre-registered value or a time-based algorithm. If both factors are successfully authenticated, access is granted. The primary benefit of 2FA is its resilience against common attack vectors like phishing, credential stuffing, and brute-force attacks, as compromising a single factor is insufficient to gain unauthorized access. However, tradeoffs include increased user friction, the potential for lost or stolen second factors, and reliance on the security of the second factor's delivery mechanism (e.g., SMS interception). Advanced implementations may involve risk-based authentication, where the system dynamically adjusts the number or type of factors required based on context, such as location, device, or time of day.
graph LR
Center["Authorization"]:::main
Rel_authorization["authorization"]:::related -.-> Center
click Rel_authorization "/terms/authorization"
Rel_mfa_multi_factor_authentication["mfa-multi-factor-authentication"]:::related -.-> Center
click Rel_mfa_multi_factor_authentication "/terms/mfa-multi-factor-authentication"
Rel_single_sign_on_sso["single-sign-on-sso"]:::related -.-> Center
click Rel_single_sign_on_sso "/terms/single-sign-on-sso"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explain Like I'm 5
[Authorization](/en/terms/authorization) is like the permissions on your phone. Authentication is your passcode that unlocks the phone. Once it's unlocked, authorization is what decides if an app is allowed to look at your photos or use your microphone. Just because you unlocked the phone doesn't mean every app can do anything it wants.
🤓 Expert Deep Dive
Two-Factor Authentication (2FA) fundamentally augments security by layering an additional verification mechanism upon the primary credential (typically a password or passphrase). This process adheres to the principle of multi-factor authentication (MFA), specifically requiring two distinct factors from the following categories:
- Something you know: Passwords, PINs, answers to security questions.
- Something you have: Physical tokens (e.g., YubiKey, RSA SecurID), smartphones running authenticator applications (e.g., Google Authenticator, Authy), or SIM cards for SMS-based OTPs.
- Something you are: Biometric data such as fingerprints, facial scans, or iris patterns.
A common implementation involves Time-based One-Time Passwords (TOTP), standardized by RFC 6238. TOTP algorithms generate a new code every 30-60 seconds based on a shared secret key (provisioned during initial setup) and the current time, often synchronized via NTP. The server-side validation involves recalculating the expected OTPs for a given time window and comparing it against the user-provided code.
Another prevalent method is HMAC-based One-Time Passwords (HOTP), defined in RFC 4226, which generates codes based on a counter that increments with each use. The server and client must maintain synchronized counters.
More advanced implementations utilize Universal 2nd Factor (U2F) and its successor, FIDO2, which leverage [public-key cryptography](/en/terms/public-key-cryptography). During registration, a unique private/public key pair is generated on the security key, and the public key is registered with the service. Authentication involves the server sending a challenge that the FIDO device signs with its private key, which the server then verifies using the registered public key, providing strong resistance against phishing attacks as the key never leaves the device and is tied to the specific origin (domain) of the website.