Authentication vs authorization: the IAM distinction Security+ tests

What is the difference between authentication and authorization?

Authentication proves who you are. Authorization decides what you are allowed to do. Authentication always happens first, because a system cannot decide your permissions until it knows whose permissions to check.

Picture arriving at an office building. Authentication is the front desk checking your ID and confirming you are who your badge claims. Authorization is the set of doors that badge actually opens once you are inside. The lobby scan and the door locks are different systems doing different jobs. You can pass the first and still be stopped at the second, which is exactly what a correctly configured system should do. A visitor who proves their identity honestly still should not reach the server room.

The memory hook that survives the exam room: authentication is about identity, the who. Authorization is about permissions, the what. When a question tangles them together on purpose, silently sort it into one bucket or the other before you read the answers. There is a third A that rounds out the model, and students forget it constantly, so it gets its own section below.

Where does this land in the 28% Security Operations domain?

Identity and access management lives in Domain 4.0, Security Operations, the largest single slice of SY0-701 at 28% of the exam. The IAM objective, numbered 4.6, is where authentication, authorization, single sign-on, and the access-control models all cluster together.

CompTIA phrases that objective as 'given a scenario,' which is a signal worth reading. The exam usually will not ask you to recite a definition. It hands you a situation, a user who cannot reach a share, a contractor who kept access after their project ended, and asks what went wrong or what to do next. That framing rewards understanding the moving parts over memorizing a glossary. The proving-who-you-are half, authentication itself, splits into the factor categories we break down in multi-factor authentication factors. This post picks up right after the login succeeds and follows what the system does with you next.

If you already design IAM systems for a living, this will read as basic, and that is fine, it is not written for you. It is written for the candidate who keeps dropping these questions, and for the new hire who will meet the exact same distinction on a real ticket in their first week.

AAA: authentication, authorization, and the accounting everyone forgets

AAA stands for authentication, authorization, and accounting. The first proves identity, the second grants or denies access, and the third records what actually happened. Students remember the first two and drop the third, which the exam notices.

Accounting is the log. Every authentication, every access granted or denied, every privileged action, written down with a timestamp and an identity attached. It is what turns 'someone deleted the records' into 'this account deleted the records at this time from this address.' On the exam, AAA often appears alongside protocols like RADIUS and TACACS+, which centralize these three functions so an organization is not managing them box by box.

The practical reason accounting matters: authorization without accounting means you can control access but never prove who did what afterward. That gap is exactly where an investigation stalls. Keep the three roles straight and a surprising number of IAM questions resolve to naming which A the scenario is really about.

SSO and federation: one login, many doors

Single sign-on lets one authentication event unlock many applications. Federation extends that trust across organizations, so an identity proven in one place is accepted in another. Both are authentication conveniences, not authorization shortcuts.

SSO means you authenticate once and reach a set of applications without logging in again to each one. Federation is SSO that crosses a boundary: your company's identity provider vouches for you to a separate vendor's application, and the vendor never sees your password. Instead it trusts a signed message, an assertion, from the identity provider that says this person authenticated and here is who they are.

Two standards carry those assertions in the real world. SAML is older and common in enterprise web applications. OpenID Connect is built on OAuth 2.0 and common in modern and consumer apps. The exam wants the concepts more than the packet details: the identity provider, the relying party, and the assertion that flows between them. NIST's federation guidance, SP 800-63C, is the authoritative reference if you want the model spelled out formally.

One caution the exam likes to test: SSO is about authentication. It does not decide what you can do once you are inside an application. That is still authorization, and it is why a zero trust approach keeps checking even after a login succeeds, rather than treating one successful sign-in as a permanent hall pass.

RBAC, RuleBAC, ABAC, MAC, DAC: how authorization decisions get made

Once someone is authenticated, five models decide what they can actually access. Role-based grants by job role, rule-based enforces system-wide rules, attribute-based decides by evaluating attributes, mandatory grants by classification labels, and discretionary leaves it to the resource owner's choice.

The exam loves to hand you a scenario and ask which model fits. The fastest tell is who makes the decision and what it is based on:

• RBAC, role-based access control: permissions attach to roles, and users inherit them by holding a role. The 'payroll clerk' role opens payroll, and you never assign permissions to people one at a time. This is the most common model in business systems because it scales cleanly.
• RuleBAC, rule-based access control: access follows system-wide rules an administrator sets, enforced automatically for everyone, such as a time-of-day limit or an ACL on a firewall that blocks a range of addresses. The rules apply to all users equally, which is what separates it from role-based, and the near-identical name to RBAC is a favorite exam trap.
• ABAC, attribute-based access control: access is decided by evaluating attributes, such as the user's department, device, time of day, and the resource's sensitivity, against policy. More flexible and more complex than roles. NIST's ABAC guide (SP 800-162) is the standard definition.
• MAC, mandatory access control: the system enforces access using classification labels like confidential or secret and matching clearances. Users cannot override it. Think government and military environments where the rules are rigid by design.
• DAC, discretionary access control: the owner of a resource decides who gets in. The person who created the file shares it with whoever they choose. Flexible, but it puts security decisions in ordinary users' hands, which is the tradeoff the exam wants you to see.

How do you know you actually know this yet?

You do not know it from re-reading, because re-reading feels like understanding without ever testing it. The honest signal comes from answering questions you have not seen and checking whether you can apply the distinction, not just recognize it.

Recognition is a trap with this exact topic. The authentication-versus-authorization pair reads as obvious on the page, then falls apart under a scenario question written to blur it. The fix is to practice retrieving the difference under pressure, not rereading the definitions. Work quiz questions and a full-length attempt, then look at what your answers say about this specific objective.

Our Mastery Index rolls up your quiz and practice-exam performance into an internal study signal for each area, shown with an evidence-quality label so you can see how much it is actually based on. It is uncalibrated, and it is not a pass prediction. What it is good for is honest: pointing you at the IAM topics where your answers are still shaky, so you spend your remaining study time where it changes the outcome instead of where it feels comfortable.

The one distinction to carry into the exam room

Strip everything else away and hold onto this: authentication answers who, authorization answers what, and accounting answers what happened. Single sign-on and federation are ways to prove who once and reuse it. RBAC, RuleBAC, ABAC, MAC, and DAC are five ways to decide what. When a Security+ question feels tangled, name which of those jobs it is really testing, and the tangle usually clears. This is not exam trivia you drop after test day. It is the same reasoning you use the first time a real ticket asks you to give someone access they should, or should not, have. Learn it as the job and the exam comes along for the ride. When you want to see where you actually stand, the Security+ track and the practice tools are built to tell you honestly, not to flatter you.