SAML vs OAuth vs OIDC on Security+: Pick by the Question

Objective 4.6 on SY0-701 mentions LDAP, OAuth, and SAML as single sign-on standards. The exam rarely tests your ability to define them. Instead, it presents a login scenario, an app integration, or a partner portal, and asks which standard fits. The wrong answers are typically the other names from that same group. Understanding what each acronym is used for is more important than knowing its definition.

One question per protocol

Each of these systems was created to solve a distinct problem, and that's the main idea.

SAML addresses "who is this person, and can I trust the company that says so?" An identity provider signs the user in and then presents the app with a signed XML message known as an assertion. The application relies on the signature rather than seeing the password. Picture an employee who opens Salesforce or Workday and lands on the corporate sign-in page before the app itself.

OAuth 2.0 deals with "what is this app allowed to do on my behalf?" You grant a calendar app permission to access your schedule, and in return the app gets an access token that's limited in scope. The app can view your calendar but not your email, and it won't discover your password. Note what OAuth omits: it doesn't reveal your identity to the app. OAuth is focused on authorization, and the exam frequently highlights this difference.

OpenID Connect (often written as OIDC) is the piece that bridges that gap. It works on top of OAuth 2.0 and introduces an ID token, a signed JWT that identifies the user. When a website offers "Sign in with Google", that button is OIDC in action atop OAuth. OIDC isn't listed in the 4.6 list, but you need it to understand the challenge further down.

LDAP is the outlier. It's a directory protocol for reading and writing the user, group, and attribute storage behind the login. Often, the identity provider checks a password against LDAP, rather than using it to log into an app. Basic LDAP sends bind credentials in plain text, so the secure version is LDAPS or LDAP with StartTLS.

The scenario words that decide it

Read the stem for the use case before checking the options. A few phrases keep repeating.

• "Employees sign in once to several cloud apps through the company identity provider" refers to SAML.
• "Let a third-party app access a user's data without giving it the password" refers to OAuth.
• "The app needs to know who the user is", or a "sign in with" button for a social account, refers to OIDC.
• "Query the directory for group membership" refers to LDAP.

If the stem mentions both "access" and "without sharing the password", it is OAuth most of the time. If it includes "assertion" or "XML", it is SAML, because no other option uses those terms.

The trap: OAuth used as a login

The most common mistake in this objective is choosing OAuth when the topic is really about identity. OAuth seems correct because the Google sign-in button appears to use OAuth, and it does involve an OAuth flow. However, an access token just indicates the app is allowed to perform certain actions; it doesn't reveal who the user is. Apps that rely on access tokens for user verification can be deceived into accepting a token intended for another application. That's precisely why OIDC was developed.

A simple distinction keeps them separate: OAuth authorizes, OIDC identifies. For situations where the app needs to know the user's identity, the correct answer is OIDC, or SAML in a business setting. If the app only requires permission to access data on behalf of a user, then OAuth is the right choice.

Federation is the bigger picture

A lot of 4.6 questions don't focus on a single protocol. They talk about two organizations. For instance, if a partner company's staff need access to your project portal, but you don't want to create or manage accounts for them, that's federation, a trust relationship where their people sign in at their own identity provider and your app accepts the result. SAML or OIDC handles the login across that trust.

If the question also mentions that access should end when someone leaves the partner company, the answer typically includes SCIM, which pushes account changes from their directory to your app automatically. Creating guest accounts manually is a common distractor, as people rarely remember to delete them.

How to drill this

Run through the four protocols and put each one's question into your own words. SAML is about who this person is, OAuth is about what this app can do, OIDC adds who the user is on top of OAuth, and LDAP is about what the directory says. After that, work through 4.6 questions in one sitting so the four names stop running together. CompTIA's own wording for 4.6 is on the full objectives list, the practice questions page is a good place to try the use-case reading, and each acronym here has its own entry in the glossary.