Exam coverage: This review supports Security+ SY0-701 (V7) objective 4.6 and SY0-801 (V8) objective 4.5, with some related identity concepts for context. Compare your version's study guide for differences in emphasis. Kerberos is included as useful authentication background, not as a claim that it is separately named in both objective maps.
When a question mentions a login, a token, a directory, or a permission, first decide what the system is trying to accomplish. The same organization can use several of these technologies together, but they do different jobs.
Fast rule: Authentication asks who are you? Authorization asks what can you do? Federation connects identity trust across systems. A directory stores and provides identity information. Identify the job before choosing a protocol.
1. Start with the question
Use this order to avoid treating every identity scenario as an authentication problem:
- Identity proofing: Is the organization establishing who an applicant is before enrollment?
- Authentication: Is the person or system proving control of a valid credential?
- Federation or single sign-on: Is a service relying on identity information or a sign-in from another system?
- Delegated access: Is an application receiving limited permission to access an application programming interface (API) or resource?
- Authorization: After identity is established, who or what decides which action is permitted?
- Lifecycle: Should an account, privilege, or session still exist after a role change or departure?
These steps are not always separate products. An identity provider can authenticate a user, issue an identity assertion, and supply attributes that a relying application uses in its own authorization policy.
2. Identity protocol comparison
The names in this table are not interchangeable. Their useful difference is what information or capability they provide.
| Technology | Main job | Recognize this clue |
|---|---|---|
| Security Assertion Markup Language (SAML) | Exchange identity and authentication assertions between trusted systems | Enterprise web single sign-on using an identity provider and a service provider |
| Open Authorization (OAuth 2.0) | Delegate limited access to protected resources | An app requests permission to use an API without receiving the user's password |
| OpenID Connect (OIDC) | Provide an identity and sign-in layer on OAuth 2.0 | An app needs a standardized sign-in result and an ID token |
| Lightweight Directory Access Protocol (LDAP) | Read and manage directory entries and attributes | Search for a user, group membership, or directory attribute |
| Kerberos | Authenticate through a trusted ticket-based service | A domain client obtains tickets from a Key Distribution Center (KDC) |
SAML: assertions between trusted systems
A user signs in with an identity provider. The identity provider sends a signed SAML assertion to a service provider, which validates it and establishes a session. SAML can carry authentication and attribute information, and its specifications support other assertion types. In Security+ sign-in scenarios, the key clue is often federated enterprise web access.
OAuth: delegated authorization
A photo-printing app needs permission to retrieve pictures from another service. OAuth 2.0 lets the app request limited resource access without asking for the account password. OAuth provides an authorization framework; an OAuth access token alone should not be treated as standardized proof of the user's identity.
OpenID Connect: user authentication on OAuth
OpenID Connect builds on OAuth 2.0 and adds authentication capabilities, including an ID token with claims about the authenticated user. This helps a relying application verify the sign-in result. OIDC may also provide access tokens for APIs. That does not make its ID token an API access token.
LDAP and Kerberos: directory versus authentication
An LDAP directory lookup can answer, "Which groups contain this account?" LDAP also supports bind operations used for authentication in some designs. LDAP is a directory access protocol, not by itself a federation or web single sign-on standard.
Kerberos uses tickets issued through a KDC to support authentication to network services. In Kerberos scenarios, watch for ticket validity, service principals, and significant clock differences. A directory and Kerberos can operate together, as they do in many domain environments, without doing the same job.
3. Identity and access tokens
A token's job depends on who should accept it and what it is intended to prove.
- ID token: In OpenID Connect, conveys the result of an end-user authentication to the intended client. The client must validate it, including the issuer, audience, signature, and relevant timing requirements.
- Access token: Represents permission for a protected resource or API. The resource server checks that the token is valid and has the appropriate permissions and audience.
- SAML assertion: Carries signed statements, often about authentication or user attributes, from an issuer to a trusting service. The recipient must validate the assertion and its expected audience and conditions.
- Kerberos service ticket: Lets a client demonstrate authentication to a service in the ticket system. It is not an OAuth API access token.
OAuth access tokens are not required to have one specific format. An access token may be opaque or use a structured format; do not assume every access token is a JSON Web Token (JWT).
Token clue: An application checking who signed in expects identity information from its approved sign-in flow. An API checking whether a call is allowed expects a token intended for that API and an authorization decision.
4. SSO, federation, and directories
Single sign-on (SSO) means a user can authenticate once and then reach multiple connected services without a separate interactive login for each. It describes the sign-in experience, not the number of authentication factors.
Federation is a trust relationship in which one system accepts identity information from another. A federated setup may provide SSO between organizations or domains. A single organization can also offer SSO without crossing a federation boundary.
Directory services store accounts, group membership, and identity attributes. A directory may support the identity provider's work, but looking up a directory entry is not the same as issuing a SAML assertion or an OIDC ID token.
A common chain is: the user signs in to an identity provider, that provider consults its identity store, the provider sends an assertion or token to the application, and the application checks its access policy. Each part has a separate responsibility.
5. Authorization models
Once the user or service is authenticated, the system still needs to decide what it may access. These models explain where the permission decision comes from.
| Model | Permission basis | Scenario clue |
|---|---|---|
| Role-Based Access Control (RBAC) | Assigned job role | Help-desk staff can reset ordinary accounts but cannot approve payroll changes |
| Attribute-Based Access Control (ABAC) | Subject, resource, action, and contextual attributes evaluated against policy | Allow a clinician to open a relevant record only from an approved managed device |
| Discretionary Access Control (DAC) | Owner can grant access within system limits | A file owner shares a document with a coworker |
| Mandatory Access Control (MAC) | Central labels and clearance policy | A user cannot override the classification rules to share a protected file |
| Rule-based control | Explicit system rules or conditions | Deny access outside the approved network or access window |
RBAC versus ABAC: Roles are good for repeatable job functions. Attributes add decisions based on context or resource characteristics. A system can use both. A role can itself be one attribute in a broader ABAC policy.
MAC versus DAC: In the classic models, MAC enforces centrally defined labels, while DAC allows an owner to share an object within policy limits. "An administrator created the permission" is not enough evidence by itself to identify MAC.
Rule-based versus ABAC: Both can evaluate conditions. The exam clue matters. A simple network or time rule is commonly called rule-based; a policy that combines user, device, resource, and environment attributes points to ABAC. Real systems do not always keep these categories separate.
6. Access lifecycle and privilege
Authorization must change when a person's responsibilities change. A strong initial login does not justify leaving old permissions in place.
- Provisioning: Create or enable an identity and its approved starting privileges.
- Role change: Review old permissions before adding the new role's access.
- Deprovisioning: Remove access when the account or relationship no longer needs it.
- Access review: Confirm that existing permissions remain justified, including group-derived privileges.
- Privileged access management (PAM): Control and monitor elevated access, often with approval, session controls, and time limits.
- Just-in-time (JIT) access: Grant elevated privileges for the approved task window, then remove them. JIT changes when a permission is available; it does not replace the underlying access model.
7. Scenario comparisons
A contractor opens a partner's application with the company's sign-in
The company's identity provider authenticates the contractor, and the partner accepts the signed identity assertion. Think federation and SAML if the scenario describes enterprise web assertions. SSO describes the user experience but does not identify the exact protocol on its own.
A calendar tool may read appointments, but not the account password
The user authorizes limited access, and the tool gets an access token for the calendar API. Think OAuth 2.0. If the tool also needs to sign the user in and receive identity claims, the scenario may involve OpenID Connect.
A support analyst can open tickets but not approve vendor payments
Access follows an assigned job role. Think RBAC. If the decision also depends on device compliance, data sensitivity, and location, think ABAC or a combined policy.
A user signs in successfully but cannot open a classified document
Authentication succeeded. A central classification policy still denies the action. Think authorization and MAC when clearance and labels control the outcome. Resetting the user's password does not resolve the policy decision.
A departing employee's old application access still works
This is an account lifecycle and deprovisioning failure. Adding another authentication factor will not remove an unnecessary account or grant. Check identity-provider sessions, application accounts, and group-based access as required by the design.
8. Common exam traps
- OAuth means authentication. OAuth 2.0 primarily provides delegated authorization; OpenID Connect adds a standardized authentication layer.
- An ID token and an access token are interchangeable. Their recipients and purposes differ. Validate the intended audience and use.
- SSO means no MFA. SSO and multifactor authentication solve different problems and can be used together.
- LDAP provides federation by itself. LDAP provides directory access. Federation needs a trust and assertion or token arrangement.
- Kerberos and LDAP perform the same job. Tickets authenticate to services; directories expose entries and attributes. Deployments can use both.
- Rule-based and ABAC can never overlap. Attribute policies can contain rules and conditions; classify using the scenario's emphasized decision method.
- JIT access is a new permission model. JIT limits the duration of privilege; a role or policy still defines what the privilege allows.
- A successful login proves the action should be allowed. The authorization decision is separate from authentication.
9. Rapid review grid
| Question clue | Think first |
|---|---|
| Signed enterprise web identity assertion | SAML |
| An app requests delegated API permission | OAuth 2.0 |
| An app verifies a standardized login and ID token | OIDC |
| Search identity entries or group membership | LDAP |
| Service authentication through tickets and a KDC | Kerberos |
| Privileges follow job function | RBAC |
| Permissions vary by user, device, resource, and context | ABAC |
| Owner can share a file | DAC |
| Central clearance and labels govern access | MAC |
| Privileged access only during a maintenance window | JIT privilege |
| User leaves and old access still works | Deprovisioning |