|
1 | | - |
2 | | -<!-- markdownlint-disable MD041 --> |
3 | | -Authentication and authorization are two fundamental concepts in identity and access management. Together, they ensure that only the right people—and only what they need—can access organizational resources. |
| 1 | +Securing access to digital resources requires two distinct but related processes: confirming who is requesting access, and then deciding what that person, device, or application is allowed to do. These two processes—*authentication* and *authorization*—are fundamental to identity and access management. Understanding the difference between them is essential because every access decision in a modern organization depends on both. |
4 | 2 |
|
5 | 3 | ## Authentication |
6 | 4 |
|
7 | | -Authentication is the process of proving that you are who you say you are. Every time you sign in to an application, unlock your phone, or access a company system, authentication is happening. The system challenges you to provide proof of your identity, and then verifies that proof before deciding whether to allow access. |
8 | | - |
9 | | -Authentication is sometimes shortened to *AuthN*. The goal of authentication is to answer the question: *Who are you?* |
10 | | - |
11 | | -### How authentication works |
12 | | - |
13 | | -Authentication requires *credentials*—evidence that verifies your identity. Common types of credentials include: |
14 | | - |
15 | | -- A username and password |
16 | | -- A fingerprint or facial scan (biometrics) |
17 | | -- A one-time code sent to your phone |
18 | | -- A hardware security key |
| 5 | +*Authentication* is the process of proving that you are who you say you are. Every time you sign in to an application, unlock your phone, or access a company system, authentication is happening. The system challenges you to provide proof of your identity, and then verifies that proof before deciding whether to allow access. Authentication answers the question: *Who are you?* |
19 | 6 |
|
20 | | -A username alone doesn't prove identity—it can be known or guessed by others. Adding a password (something only the legitimate user should know) gives a system confidence that the right person is signing in. Adding a biometric or physical device raises that confidence further. |
| 7 | +Authentication requires *credentials*—evidence that verifies your identity. A username alone doesn't prove identity—it can be known or guessed by others. Adding a password provides a basic level of verification, but passwords can be stolen, guessed, or phished—making them one of the weakest forms of authentication on their own. Adding a stronger factor, such as a biometric or physical device, raises confidence significantly. |
21 | 8 |
|
22 | | -Modern authentication systems also evaluate *contextual signals*: where the sign-in request originates, what device is being used, the time of day, and whether behavior matches typical patterns. These signals help systems detect suspicious sign-in attempts even when the correct credentials are presented. |
| 9 | +Authentication methods are built on three categories of proof, called *authentication factors*: |
23 | 10 |
|
24 | | -### Passwordless authentication |
| 11 | +- **Something you know** — a password, PIN, or security question |
| 12 | +- **Something you have** — a mobile device, hardware security key, or smart card |
| 13 | +- **Something you are** — a biometric characteristic like a fingerprint or facial scan |
25 | 14 |
|
26 | | -*Passwordless* authentication removes the reliance on passwords by using stronger alternatives—such as biometrics, hardware security keys, or device-based credentials—to verify identity. Because there's no password to steal, reuse, or guess, passwordless methods reduce many of the risks associated with traditional password-based sign-in. |
| 15 | +Using only one factor—such as a password alone—is called *single-factor authentication*. Single-factor authentication is common but vulnerable. If that single factor is compromised—a password stolen through phishing, for example—an attacker has everything they need to impersonate the user. |
27 | 16 |
|
28 | | -### Multifactor authentication |
| 17 | +*Multifactor authentication (MFA)* strengthens authentication by requiring two or more factors from different categories. For example, signing in with a password (something you know) and then approving a notification on your phone (something you have). Because an attacker would need to compromise multiple independent credentials, MFA dramatically reduces the risk of account takeover. |
29 | 18 |
|
30 | | -A username and password alone are often insufficient protection. Passwords are frequently stolen through phishing attacks, data breaches, and credential-stuffing attacks. *Multifactor authentication (MFA)* strengthens authentication by requiring more than one type of proof, drawn from different categories: |
31 | | - |
32 | | -- **Something you know**—a password or PIN |
33 | | -- **Something you have**—a phone, a hardware security key, or a smart card |
34 | | -- **Something you are**—a biometric, such as a fingerprint or facial scan |
35 | | - |
36 | | -When MFA is enabled, stealing a password alone isn't enough to compromise an account. An attacker would also need to physically possess the user's device or replicate their biometrics. This extra layer of verification dramatically reduces the risk of account takeover. |
| 19 | +After the system evaluates the credentials, authentication either succeeds or fails. Successful authentication confirms the identity and allows the process to continue. Failed authentication denies access before any resources are exposed. But authentication alone doesn't determine what you can do—it only confirms who you are. That's where authorization comes in. |
37 | 20 |
|
38 | 21 | ## Authorization |
39 | 22 |
|
40 | | -Once your identity is confirmed through authentication, the next question is: *What are you allowed to do?* |
41 | | - |
42 | | -Authorization is the process of determining what an authenticated user has permission to access and what actions they can perform. Knowing who you are isn't enough—the system also needs to determine what you're entitled to. |
43 | | - |
44 | | -Authorization is sometimes shortened to *AuthZ*. |
45 | | - |
46 | | -### The hotel analogy |
47 | | - |
48 | | -A useful way to think about authentication and authorization is to imagine checking into a hotel. |
49 | | - |
50 | | -When you arrive, you go to the reception desk and present your passport or driver's license. The receptionist checks your identification against your reservation to confirm who you are. That's *authentication*. |
51 | | - |
52 | | -Once verified, you're given a keycard programmed to open specific doors: your assigned room, the fitness center, or the pool—but not other guests' rooms, the staff areas, or the kitchen. When you use the keycard, the door sensor checks your permissions and grants or denies access accordingly. That's *authorization*. |
53 | | - |
54 | | -In digital systems: |
55 | | -- The credentials you provide (username, password, biometrics) are like your passport—they prove who you are. |
56 | | -- The permissions assigned to your account—which applications, files, and actions you can access—are like the keycard. |
57 | | - |
58 | | -### How authorization is managed |
59 | | - |
60 | | -Authorization is typically managed through *roles* and *permissions*. Rather than assigning access rights individually to every user, systems group permissions into named roles, and then assign users to those roles. |
61 | | - |
62 | | -For example: |
63 | | -- A *help desk technician* role might allow viewing user account status but not resetting passwords. |
64 | | -- A *security administrator* role might allow resetting passwords and reviewing sign-in logs. |
65 | | -- A *global administrator* role might have full control over all settings and users. |
66 | | - |
67 | | -This model is called *role-based access control (RBAC)*. When the permissions of a role change, every user assigned to that role is automatically affected. RBAC makes managing access across large organizations scalable and consistent. |
| 23 | +*Authorization* is the process of determining what an authenticated identity is allowed to do. Once authentication confirms your identity, authorization evaluates your permissions and decides whether to grant or deny access to specific resources—applications, files, data, or system features. Authorization answers the question: *What are you allowed to do?* |
68 | 24 |
|
69 | | -Authorization decisions can also be dynamic. A user might be authorized to access a sensitive application under normal circumstances—but if they sign in from an unexpected location or an unrecognized device, a risk-based policy might step up the authentication requirement or restrict access until the risk is resolved. |
| 25 | +Authorization decisions are typically based on roles (such as employee, manager, or administrator), permissions (read, write, or delete), and attributes (department, location, or job function). The system evaluates these rules for each access request and grants or restricts access accordingly. |
70 | 26 |
|
71 | | -## Authentication and authorization work together |
| 27 | +A key authorization concept is the *principle of least privilege*: users should have only the minimum access they need to perform their job, and no more. Limiting access reduces the potential damage from a compromised account, minimizes the risk of accidental data loss, and helps organizations meet their security and compliance requirements. |
72 | 28 |
|
73 | | -Authentication and authorization are distinct processes, but they work together to protect resources. They always occur in a specific order: |
| 29 | +## How authentication and authorization work together |
74 | 30 |
|
75 | | -1. **Authentication**—the system verifies who you are. |
76 | | -2. **Authorization**—the system determines what you're allowed to do. |
| 31 | +Authentication and authorization are distinct processes, but they work together to protect resources. They always occur in a specific order: authentication happens first—at sign-in—and establishes who you are. Authorization happens after authentication and determines what you can access. |
77 | 32 |
|
78 | | -Authorization can only happen after successful authentication. You can't determine what someone is permitted to do without first confirming their identity. And confirming identity alone—without checking permissions—leaves resources exposed. |
| 33 | +Think of it like checking into a hotel. You present your ID at the front desk, and the receptionist verifies who you are—that's authentication. You're then given a keycard that opens your room and the fitness center, but not other guests' rooms or staff areas—that's authorization. |
79 | 34 |
|
80 | | -Together, authentication and authorization form the foundation of access management across all Microsoft security, compliance, and identity solutions. |
| 35 | +Authorization can only happen after successful authentication. You can't determine what someone is permitted to do without first confirming their identity. And confirming identity alone—without checking permissions—leaves resources exposed. Together, authentication and authorization ensure that the right identities get the right access, and nothing more. |
81 | 36 |
|
82 | 37 |
|
0 commit comments