Authentication & Access Control Models (Security+ SY0-701)

Authentication & Access Control Models

Authentication and access control appear across Domains 1 and 4 of SY0-701. Questions test your ability to identify the right authentication mechanism for a scenario and choose the correct access control model based on organizational requirements.

🏛️

IAM = three separate questions: (1) Authentication — who are you? (verify identity). (2) Authorization — what can you do? (access control models). (3) Accounting — what did you do? (logging, AAA). These three form the AAA framework tested throughout SY0-701.

🔐

Auth Factors & MFA

Verify Identity

Authentication factors prove who you are. MFA requires two or more different factor categories — combining them makes account compromise dramatically harder.

Know: Password, PIN, security question Have: Token, smart card, OTP app Are: Fingerprint, retina, face scan MFA: Two+ different factor types

🏛️

Access Control Models

Authorize What's Allowed

Access control models define who can access what. The right model depends on security requirements, flexibility needs, and organizational structure.

DAC: Owner grants access (Windows) MAC: Labels + clearances (gov/military) RBAC: Job roles grant access (enterprise) ABAC: Attribute policies (most flexible)

🗝️

Identity Protocols

AAA Infrastructure

The protocols that carry authentication and authorization over the network. Each has specific use cases — the exam tests which protocol fits which scenario.

Kerberos: Ticket-based, Windows AD RADIUS: VPN/Wi-Fi AAA (UDP) TACACS+: Device admin (TCP, full encrypt) LDAP: Directory lookups (port 389/636)

🤝

SSO & Federation

One Login, Many Services

SSO and federation let users authenticate once and access multiple systems. The specific standard used depends on the architecture and application type.

SAML 2.0: XML SSO, enterprise browser OAuth 2.0: Authorization (NOT authn) OIDC: Authentication on top of OAuth Federation: Cross-org trust

The SY0-701 IAM Mindset

Know the purpose of each model and protocol, not just its name. The exam presents scenarios and asks which control fits — RBAC vs. ABAC, RADIUS vs. TACACS+, SAML vs. OAuth. The wrong answer usually fails one specific requirement in the scenario.

💡

The biggest exam trap: OAuth 2.0 is an authorization framework — it grants an app permission to access resources on a user's behalf. It does NOT authenticate the user's identity. OpenID Connect (OIDC) adds authentication on top of OAuth 2.0. If the exam asks "which standard lets a user log in with their Google account" → OIDC. If it asks "which lets an app access Google Calendar data" → OAuth 2.0.

Take the Quiz →

Deep Dive: Each IAM Category

The mechanisms, protocols, models, and exam traps for each authentication and access control category in SY0-701.

🔐 Authentication Factors & MFA Verify Identity

The Five Factor Categories

🧠

Knowledge

Something You Know

Password, PIN, passphrase, security question answer

📱

Possession

Something You Have

OTP app, hardware token, smart card, push notification

👁️

Inherence

Something You Are

Fingerprint, retina, iris, face, voice, palm vein

📍

Location

Somewhere You Are

GPS location, IP geolocation, network (office Wi-Fi only)

🖱️

Behavior

Something You Do

Typing cadence, mouse movement patterns, gait analysis

MFA (Multi-Factor Authentication)

Requires two or more different factor categories. Password + PIN = single factor (both knowledge) — NOT MFA. Password + OTP app = MFA (knowledge + possession). The categories must differ, not just the number of steps.

2+ different categories required

TOTP (Time-Based OTP)

Generates a new 6-digit code every 30 seconds using a shared secret + current timestamp. Google Authenticator, Microsoft Authenticator, Authy. Both the app and server compute the same code independently. Codes expire quickly — captured codes are useless after 30 seconds.

Time-based · 30-second window

HOTP (HMAC-Based OTP)

Counter-based OTP — a new code is generated each time the button is pressed (or a login is attempted). The server and token maintain synchronized counters. A valid code remains valid until used (look-ahead window for sync). RFC 4226.

Counter-based · Valid until used

FIDO2 / WebAuthn / Passkeys

Phishing-resistant passwordless authentication. Uses public-key cryptography: a private key stored on the device/authenticator, public key registered with the server. Hardware tokens (YubiKey), platform authenticators (Face ID, Windows Hello). Cannot be phished — tied to the specific origin domain.

Phishing-resistant · Passwordless

Smart Cards / PIV / CAC

Physical card with an embedded certificate and private key. PIV (Personal Identity Verification) is the US federal standard. CAC (Common Access Card) is the DoD version. Requires PIN to unlock the card — combines possession (card) + knowledge (PIN). Strong MFA for government.

Possession + knowledge · Government

Biometric Error Rates

FAR (False Acceptance Rate): Percentage of unauthorized users incorrectly accepted — a security risk. FRR (False Rejection Rate): Percentage of legitimate users incorrectly rejected — a usability problem. CER (Crossover Error Rate): The point where FAR = FRR — used to compare biometric system accuracy. Lower CER = better system.

FAR · FRR · CER

⚠️

MFA exam trap — factors must be different categories: A password + a PIN = two knowledge factors = NOT MFA. A fingerprint + a retina scan = two inherence factors = NOT MFA. MFA requires factors from different categories: e.g., password (know) + authenticator app (have) + fingerprint (are). The exam will test this distinction.

Exam keyword mapping "30-second expiring code" = TOTP · "Counter-based token" = HOTP · "Phishing-resistant, no password" = FIDO2/WebAuthn · "Federal/DoD card + PIN" = PIV/CAC · "FAR/FRR crossover" = CER · "Two factor types" = MFA

🏛️ Access Control Models Authorize Access

DAC — Discretionary Access Control

The resource owner decides who can access their data and sets permissions accordingly. Common in Windows NTFS (file owner sets ACL permissions). Flexible but risky — users may grant access too broadly. Linux standard permissions (rwxrwxrwx) are also DAC.

Owner-controlled · ACLs · Windows/Linux

MAC — Mandatory Access Control

Access based on security labels (classification level) assigned to data and clearance levels assigned to users. The OS/system enforces access — the owner cannot override it. Used in government/military environments. SELinux implements MAC. Bell-LaPadula model: No Read Up (can't read above clearance), No Write Down (can't write below classification).

Labels + clearances · Government · SELinux

RBAC — Role-Based Access Control

Access permissions are assigned to roles, and users are assigned to roles. Most common enterprise model. Simplifies administration — add/remove a user from a role rather than updating individual permissions. Risk: role explosion (too many fine-grained roles) and privilege creep (old roles not removed when job changes).

Roles → permissions · Enterprise standard

ABAC — Attribute-Based Access Control

Fine-grained access based on attributes of the user (role, department, clearance), resource (classification, type), and environment (time of day, location, device). Most flexible model — policies can combine many attributes simultaneously. XACML is the policy language. Used in cloud environments and Zero Trust architectures.

Attributes + policies · Most flexible · Cloud

Rule-Based Access Control

Admins define static rules that apply to all users — rules are NOT based on user roles or identity. Examples: firewall rules (allow port 443 from any), time-of-day restrictions (no access outside 9am–6pm). Not the same as RBAC despite similar naming. Common source of exam confusion.

Admin-defined rules · Not role-based

Privilege Creep & Least Privilege

Privilege creep: Accumulation of access rights over time as users change roles but old access is never removed. Mitigated by periodic access reviews (recertification). Least privilege: Users should have only the minimum access needed for their current job — no more. A core Zero Trust principle.

Key concepts · Access review required

💡

Bell-LaPadula vs. Biba models (MAC variants): Bell-LaPadula = confidentiality model. Rule: No Read Up (can't read higher classification), No Write Down (can't write to lower classification — prevents leaking secrets). Biba = integrity model. Rule: No Write Up (can't write to higher integrity level — prevents corruption), No Read Down (can't read lower integrity — prevents contamination).

Exam keyword mapping "Owner sets permissions, ACL" = DAC · "Security labels, clearances, government" = MAC · "Job roles, enterprise, role explosion" = RBAC · "Multiple attributes, time/location/department" = ABAC · "Admin rules, firewall, time-of-day" = Rule-Based · "No Read Up, No Write Down" = Bell-LaPadula (MAC)

🗝️ Identity & Directory Protocols AAA Infrastructure

Kerberos

Ticket-based authentication used in Windows Active Directory environments. Port 88. Key components: KDC (Key Distribution Center) = Authentication Server (AS) + Ticket Granting Server (TGS). Flow: User authenticates to AS → receives TGT → presents TGT to TGS → receives service ticket → presents to application server. Mutual authentication. Time-sensitive (5-minute clock skew tolerance).

Port 88 · Tickets · Windows AD · Mutual auth

LDAP / LDAPS

Lightweight Directory Access Protocol — queries directory services (like Active Directory) for user account information. Port 389 (plaintext), port 636 (LDAPS — encrypted). Hierarchical structure: DN (Distinguished Name), OU (Organizational Unit), CN (Common Name). LDAP is for lookups — authentication is done by Kerberos or NTLM, not LDAP itself.

Port 389/636 · Directory queries · Not auth

RADIUS

Remote Authentication Dial-In User Service — provides AAA for network access (VPN concentrators, wireless access points, network switches). Uses UDP ports 1812 (auth) and 1813 (accounting). Encrypts only the password field, not the full packet. Client-server: NAS (Network Access Server) forwards credentials to RADIUS server.

UDP 1812/1813 · VPN/Wi-Fi · Password-only encrypt

TACACS+

Terminal Access Controller Access-Control System Plus — Cisco-developed (now open). Provides AAA for network device administration (router/switch configuration). Uses TCP port 49. Fully encrypts the entire packet (not just the password). Separates Authentication, Authorization, and Accounting into independent processes for granular command-level authorization.

TCP 49 · Full encryption · Device admin · Cisco

AAA Framework

Authentication: Who are you? (verify identity — username/password/MFA). Authorization: What can you do? (permissions, access control models). Accounting: What did you do? (session logs, audit trails, compliance reporting — duration, bytes transferred, commands run). RADIUS and TACACS+ both implement AAA.

Auth + Authz + Accounting

NTLM (NT LAN Manager)

Legacy Windows authentication protocol using a challenge-response mechanism. Replaced by Kerberos for domain authentication in modern Windows. Still used in some scenarios: workgroup environments (no AD), some legacy apps, and when authenticating by IP address (not hostname). Vulnerable to pass-the-hash attacks. Avoid when possible.

Legacy Windows · Challenge-response · Pass-the-hash risk

Kerberos Authentication Flow

1

User → Authentication Server (AS)"I am Alice" + encrypted timestamp (proves knowledge of password hash). No password sent

2

AS → User: TGT (Ticket Granting Ticket)Encrypted with the KDC's secret key. Alice cannot read it — but carries it to the TGS.

3

User → Ticket Granting Server (TGS)"I need to access the file server" + TGT. No re-authentication needed

4

TGS → User: Service TicketEncrypted with the file server's secret key. Alice presents this to the file server.

5

User → File Server: Service TicketFile server decrypts it (proves KDC issued it) and grants access. Mutual auth

⚠️

RADIUS vs. TACACS+ — the critical distinctions: (1) RADIUS uses UDP; TACACS+ uses TCP. (2) RADIUS encrypts only the password; TACACS+ encrypts the entire packet. (3) RADIUS is for network access (VPN, Wi-Fi); TACACS+ is for network device administration (router/switch commands). (4) TACACS+ separates A/A/A independently; RADIUS bundles authentication and authorization. Exam questions often hinge on "command-level authorization" or "full packet encryption" → TACACS+.

🤝 SSO & Federation One Login, Many Services

SAML 2.0 (Security Assertion Markup Language)

XML-based SSO standard for enterprise browser-based applications. Three roles: User (browser), IdP (Identity Provider — authenticates the user, e.g., Okta, AD FS), SP (Service Provider — the app, e.g., Salesforce). SP redirects to IdP → IdP authenticates → IdP returns XML assertion → SP grants access. No credentials sent to the SP.

XML · Enterprise SSO · IdP + SP

OAuth 2.0

Authorization framework — NOT authentication. Grants a third-party application limited access to a user's resources on another service without sharing credentials. Example: "Allow this calendar app to read your Google Calendar." Tokens: access token (short-lived), refresh token (long-lived). Does NOT prove who the user is — only that they authorized access.

Authorization only · Delegated access · Tokens

OpenID Connect (OIDC)

An authentication layer built on top of OAuth 2.0. Adds an ID token (a JWT — JSON Web Token) that contains claims about who the user is. Enables "Sign in with Google/Apple/Microsoft" flows. OIDC = authentication (who are you?). OAuth 2.0 = authorization (what can the app access?). Both are typically used together for modern apps.

Authentication · JWT ID token · Builds on OAuth

Federation

A trust relationship between two separate identity domains — allowing users from one organization to access resources in another without creating a new account. Example: A company's employees log in to a partner's system using their corporate credentials. Implemented via SAML or OIDC. Each organization manages its own IdP.

Cross-org trust · Single identity

SSO (Single Sign-On)

Log in once and access multiple applications without re-entering credentials. Benefits: reduced password fatigue, fewer help-desk password resets, centralized access control. Risk: the IdP becomes a single point of failure and a high-value attack target — MFA on the IdP is critical. Implemented via SAML (enterprise) or OIDC (modern).

One login · Multiple apps · IdP is critical target

JWT (JSON Web Token)

A compact, signed token used in OIDC and OAuth 2.0. Three parts: Header (algorithm), Payload (claims: sub, email, exp, iat, etc.), Signature (verifies token wasn't tampered with). Base64URL-encoded. The signature is verified with the IdP's public key — no round-trip needed. Stateless: the server doesn't need to look up session state.

Header.Payload.Signature · Stateless · OIDC

SAML SSO Flow

1

User visits Salesforce (SP)Not logged in. Salesforce detects no session.

2

SP redirects to IdP (e.g., Okta)Browser redirects with a SAML authentication request. User logs into Okta with corporate credentials + MFA.

3

IdP issues SAML AssertionXML document signed by IdP's private key. Contains user identity, attributes, and validity period.

4

Browser posts Assertion to SPSalesforce verifies IdP's signature, reads user attributes, creates session. Access granted — no credentials ever sent to Salesforce.

⚠️

OAuth vs. OIDC — the exam's most common federation trap: OAuth 2.0 answers the question "What can this app do on your behalf?" — it's authorization. OIDC answers "Who is this user?" — it's authentication. "Sign in with Google" uses OIDC. "Allow this app to post on your Twitter" uses OAuth. The two are used together: OIDC for authentication + OAuth for authorization of resource access.

Side-by-Side Comparison

Filter by category or view all. Focus on the distinguishing features that determine the right control for each scenario.

Criterion	🔐 Auth/MFA	🏛️ Access Control	🗝️ Protocols	🤝 SSO/Federation
Core Question	Who are you? (identity verification)	What can you access? (authorization)	How is auth/authz transmitted? (AAA protocol)	Can you use your existing identity here? (trust)
Key Models	Know / Have / Are / Location / Behavior + MFA	DAC / MAC / RBAC / ABAC / Rule-Based	Kerberos / RADIUS / TACACS+ / LDAP / NTLM	SAML 2.0 / OAuth 2.0 / OIDC / Federation
Most Flexible	FIDO2/Passkeys — phishing-resistant, no password	ABAC — policies combine multiple attributes	TACACS+ — separates A/A/A independently	OIDC — modern, API-friendly, mobile-compatible
Government / High Security	Smart card (PIV/CAC) — possession + knowledge	MAC — labels and clearances, SELinux	Kerberos — mutual auth, no password on wire	SAML 2.0 — mature, widely audited standard
Key Limitation	Biometrics: FAR/FRR trade-off; TOTP: phishable; SMS OTP: SIM-swap vulnerable	DAC: users over-share; MAC: rigid; RBAC: role explosion; ABAC: complex policies	RADIUS: UDP (unreliable), password-only encryption; Kerberos: requires time sync	SAML: XML complexity; OAuth: not for authentication; SSO: IdP = single point of failure
Exam Keyword	"Phishing-resistant" = FIDO2 · "30-sec code" = TOTP · "CER/FAR/FRR" = Biometrics	"Labels/clearances" = MAC · "Roles" = RBAC · "Multiple attributes" = ABAC · "Owner sets" = DAC	"VPN/Wi-Fi AAA" = RADIUS · "Command-level, full encrypt" = TACACS+ · "Tickets, AD" = Kerberos	"Enterprise SSO, XML" = SAML · "Authorization, not authn" = OAuth · "Sign in with Google" = OIDC
Typical Use Case	Login flows, remote access, VPN, privileged admin access	File system permissions, cloud IAM policies, database access control	Enterprise networks, Windows domains, VPN gateways, managed switches/routers	Enterprise SaaS apps, cross-org partner access, mobile/API authentication

Exam-Style Vignettes

Read each scenario and identify the correct IAM answer before checking the breakdown.

🔐 Auth/MFAChoosing the Right MFA Method

"A financial institution's security team has experienced several account takeovers caused by attackers who used phishing sites to capture both passwords and TOTP codes in real time (real-time phishing proxy attacks). The team wants to deploy the strongest available MFA that cannot be captured by phishing. What should they deploy?"

Correct AnswerFIDO2 / WebAuthn (hardware keys like YubiKey or platform authenticators like Face ID). The credential is cryptographically tied to the specific origin domain — a phishing site on a different domain cannot obtain a valid response.

Why Not TOTP?TOTP codes can be captured in real-time phishing proxy attacks — the attacker captures the code and immediately replays it on the legitimate site within the 30-second window.

Why Not SMS OTP?SMS is vulnerable to SIM-swapping and SS7 interception attacks — weakest MFA form.

Exam Key"Phishing-resistant MFA," "cannot be captured in real-time" → FIDO2/WebAuthn/Passkeys

🏛️ Access ControlSelecting the Right Access Model

"A hospital needs an access control model where doctors can access patient records in their own department at any time, but access is automatically blocked after business hours for non-emergency staff, and contractors can only access specific systems relevant to their current project — no matter how the IT team configures things manually."

Correct AnswerABAC — policies combining user attributes (role=doctor, department=cardiology), resource attributes (patient department), and environment attributes (time of day, contractor status) enforce all three requirements simultaneously.

Why Not RBAC?RBAC can handle role-based access (doctor/nurse/contractor) but cannot natively enforce time-of-day restrictions or cross-reference department attributes without building many overlapping roles.

Why Not MAC?MAC uses fixed labels/clearances — it's too rigid for the dynamic, multi-attribute requirements here.

Exam Key"Time of day," "department match," "multiple conditions simultaneously" → ABAC

🗝️ ProtocolsRADIUS vs. TACACS+

"A network team manages 200 Cisco routers. They need to authenticate administrators, authorize which commands each admin tier can execute (Tier 1 = read-only, Tier 2 = full access), and log every command entered for compliance. All credentials and commands must be encrypted in transit."

Correct AnswerTACACS+ — separates Authentication, Authorization, and Accounting independently; provides granular command-level authorization; encrypts the entire payload (not just the password).

Why Not RADIUS?RADIUS encrypts only the password field — commands and attributes are transmitted in cleartext. RADIUS also bundles authentication and authorization, making command-level authorization harder to implement.

Why Not Kerberos?Kerberos provides mutual authentication but does not natively provide command-level authorization for network device administration.

Exam Key"Command-level authorization," "full encryption," "device administration" → TACACS+

🤝 SSO/FederationOAuth vs. OIDC

"A startup is building a productivity app. They want to: (1) allow users to log in using their existing Google account instead of creating a new password, and (2) with the user's permission, read their Google Calendar to display upcoming meetings in the app."

Authentication (Goal 1)OpenID Connect (OIDC) — adds an ID token to the OAuth flow that proves who the user is. "Sign in with Google" uses OIDC to authenticate the user's identity.

Authorization (Goal 2)OAuth 2.0 — grants the app a scoped access token to read Google Calendar data on the user's behalf, without the user ever sharing their Google password with the app.

Key DistinctionOIDC answers "Who is this user?" OAuth 2.0 answers "What resources can this app access?" They work together: OIDC for login, OAuth for resource access.

Exam Key"Sign in with" = OIDC (authentication). "Access calendar/contacts/data" = OAuth (authorization).

⚠️

Top 5 IAM exam traps: (1) Password + PIN = NOT MFA (both knowledge factors). (2) OAuth 2.0 is authorization only — not authentication. (3) RADIUS encrypts password only; TACACS+ encrypts everything. (4) Rule-based access control ≠ Role-based access control (RBAC). (5) Privilege creep = old roles not revoked after a job change — mitigated by periodic access reviews, not by adding more roles.

Practice Quiz

10 scenario-based questions with per-category breakdown — built around actual SY0-701 scenario question patterns.

Question 1 of 10

Auth/MFA

—

Access Control

—

Protocols

—

SSO/Federation

—

IAM Selector Tool

Answer 2–3 questions to identify the most appropriate identity and access management control for your scenario.

What IAM problem are you trying to solve?

Choose the goal that best describes your scenario.

What are the key requirements for authentication?

How should access be determined?

What are you authenticating?

What type of SSO or federation?

Memory Hooks & Mnemonics

Click each card to flip it and reveal the mnemonic.

👆 Tap a card to flip

🔐

MFA

What counts as true MFA?

Password + PIN = NOT MFA.
Password + phone app = MFA.

MFA requires factors from DIFFERENT categories: know + have, or know + are. Two passwords = still single factor. Two biometrics = still single factor. The categories must differ.

🗺️

Access Control

DAC / MAC / RBAC / ABAC — quick recall?

Owner · Labels · Roles · Attributes

DAC = owner decides. MAC = system enforces labels (govt). RBAC = roles = job functions (enterprise). ABAC = many attributes combined (most flexible, cloud). Each is more sophisticated than the last.

📡

RADIUS vs TACACS+

Which for VPN, which for routers?

RADIUS = Remote users (VPN/Wi-Fi).
TACACS+ = Terminal admin (devices).

RADIUS: UDP, encrypts password only, network access. TACACS+: TCP, encrypts everything, device administration with command-level authorization. "Full encryption + command control" = TACACS+.

🎫

Kerberos

What is a TGT and why does it matter?

"Log in once, get a golden ticket, use it all day."

TGT = Ticket Granting Ticket. You prove your identity to the AS once → get TGT → use TGT to get service tickets all day without re-entering credentials. KDC = AS + TGS. No password travels on the network.

🤝

OAuth vs OIDC

Which authenticates, which authorizes?

OAuth = "what can you do?" OIDC = "who are you?"

OAuth 2.0 = authorization only (grants resource access, issues access tokens). OIDC = authentication (adds ID token proving who the user is, built on top of OAuth). "Sign in with Google" = OIDC. "Access your calendar" = OAuth.

🏛️

Bell-LaPadula

What model and what are the rules?

No Read Up. No Write Down.
Confidentiality model (MAC).

Bell-LaPadula enforces confidentiality. A Secret-cleared user: cannot read Top Secret (no read up), cannot write to Unclassified (no write down — prevents leaking). Biba is the opposite for integrity: no write up, no read down.

📱

TOTP vs HOTP

What's the difference?

TOTP = Time (30 sec). HOTP = Counter (button press).

TOTP codes expire every 30 seconds — captured codes become useless quickly. HOTP codes are counter-based — valid until used. Google Authenticator = TOTP. Hardware RSA tokens with a button = HOTP. TOTP is more common in modern apps.

🔁

Privilege Creep

What is it and how do you stop it?

"Roles accumulate. Reviews reclaim."

Privilege creep = user gains new roles as jobs change but old access is never revoked. The fix: periodic access reviews (recertification campaigns) where managers re-approve every access right. Also mitigated by separation of duties and least privilege enforcement.

SY0-701 Quick-Recall Cheat Sheet

If the exam says…	Key detail	Answer
"Phishing-resistant MFA," "TOTP captured in real-time attack"	Tied to origin domain cryptographically	FIDO2 / WebAuthn / Passkeys
"30-second code," "authenticator app"	Time-based, expires quickly	TOTP
"FAR/FRR crossover point"	Where FAR = FRR — system accuracy metric	CER (Crossover Error Rate)
"Federal ID card + PIN," "DoD," "PIV"	Possession + knowledge	Smart Card (PIV/CAC)
"Owner controls access," "NTFS permissions," "ACL"	User-discretionary	DAC
"Security labels," "clearance levels," "government/military"	System-enforced, SELinux	MAC
"No Read Up, No Write Down"	Confidentiality-focused MAC	Bell-LaPadula Model
"Job roles," "enterprise," "role explosion," "least privilege"	Role-centric	RBAC
"Time of day + department + device type + role"	Multi-attribute policies	ABAC
"VPN auth," "Wi-Fi authentication," "AAA for network access," "UDP"	Password-only encrypted	RADIUS
"Router admin," "command-level authorization," "full encryption," "TCP 49"	Separates A/A/A	TACACS+
"Tickets," "TGT," "Windows AD," "KDC," "mutual auth"	Port 88, no password on wire	Kerberos
"Enterprise SSO," "XML assertion," "IdP + SP," "Salesforce/Workday"	Browser-based, mature standard	SAML 2.0
"Sign in with Google/Apple," "ID token," "JSON"	Authentication on top of OAuth	OpenID Connect (OIDC)
"App accesses calendar/contacts without your password"	Authorization only, not auth	OAuth 2.0

Authentication & Access Control
MFA · DAC/MAC/RBAC/ABAC · Protocols · SSO & Federation

Verify Identity

Authorize What's Allowed

AAA Infrastructure

One Login, Many Services

The SY0-701 IAM Mindset

🔐 Authentication Factors & MFA Verify Identity

🏛️ Access Control Models Authorize Access

🗝️ Identity & Directory Protocols AAA Infrastructure

🤝 SSO & Federation One Login, Many Services

SY0-701 Quick-Recall Cheat Sheet

Ready to Pass Security+?
Get Everything You Need in One Place.

Authentication & Access ControlMFA · DAC/MAC/RBAC/ABAC · Protocols · SSO & Federation

Verify Identity

Authorize What's Allowed

AAA Infrastructure

One Login, Many Services

The SY0-701 IAM Mindset

🔐 Authentication Factors & MFA Verify Identity

🏛️ Access Control Models Authorize Access

🗝️ Identity & Directory Protocols AAA Infrastructure

🤝 SSO & Federation One Login, Many Services

SY0-701 Quick-Recall Cheat Sheet

Ready to Pass Security+?Get Everything You Need in One Place.

Authentication & Access Control
MFA · DAC/MAC/RBAC/ABAC · Protocols · SSO & Federation

Ready to Pass Security+?
Get Everything You Need in One Place.