CISSP Identity and Access Management Practice Question
Which TWO of the following are OAuth 2.0 grant types? (Choose two.)
⚠ Common exam trap
CISSP often tests whether candidates can distinguish OAuth 2.0 grant types from other authentication protocols like SAML, LDAP, and Kerberos, so they pick protocol names that sound like grants but are not part of OAuth 2.0.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Client credentials
Option B (Client credentials) is correct because the client credentials grant is one of the standard OAuth 2.0 grant types defined in RFC 6749, used for machine-to-machine authentication where the client requests an access token using its own credentials without a resource owner. Option E (Authorization code) is correct because the authorization code grant is the core OAuth 2.0 flow defined in RFC 6749, where the client exchanges an authorization code obtained via the authorization endpoint for an access token at the token endpoint. The other options do not belong: SAML assertion (A) is an XML-based authentication/authorization standard used in SAML bearer assertions, not an OAuth 2.0 grant type; LDAP bind (C) is an authentication operation in the LDAP protocol, not an OAuth grant; and Kerberos ticket (D) is a ticket-based authentication mechanism in the Kerberos protocol, unrelated to OAuth 2.0 grant types.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
SAML assertion
Why it's wrong here
SAML (Security Assertion Markup Language) assertion is an XML-based token used primarily for exchanging authentication and authorization data between an identity provider and a service provider, enabling single sign-on (SSO) across different security domains. While SAML can be used in conjunction with OAuth 2.0 (e.g., an identity provider might issue a SAML assertion that an OAuth client then uses to obtain an access token via a custom grant type), it is not one of the standard, predefined OAuth 2.0 grant types itself. OAuth 2.0 defines specific flows for delegated authorization, distinct from SAML's identity federation role.
- ✓
Client credentials
Why this is correct
The Client Credentials grant type is specifically designed for machine-to-machine authentication, where a confidential client (e.g., a service, daemon, or another API) needs to access protected resources on behalf of itself, rather than a specific end-user. In this flow, the client authenticates directly with the authorization server using its own client ID and client secret, receiving an access token that grants it access to resources it is authorized for. This grant is ideal for server-to-server interactions or automated processes where no user interaction is present or required.
- ✗
LDAP bind
Why it's wrong here
LDAP (Lightweight Directory Access Protocol) bind is a fundamental operation within the LDAP protocol used to authenticate a client to an LDAP directory server. This process establishes the client's identity and permissions for subsequent directory queries or modifications. It is a low-level authentication mechanism for directory services, entirely distinct from OAuth 2.0, which is an authorization framework for delegated access to HTTP-based resources. An LDAP bind operation does not facilitate the issuance or exchange of access tokens for third-party applications.
- ✗
Kerberos ticket
Why it's wrong here
Kerberos is a network authentication protocol that provides strong authentication for client/server applications using secret-key cryptography, issuing "tickets" to users and services. A Kerberos ticket is a proof of identity that allows a client to securely access a service without repeatedly sending credentials. While it is a robust authentication system, Kerberos operates independently of and is not a defined grant type within the OAuth 2.0 authorization framework. OAuth 2.0 focuses on delegated authorization using access tokens, not on issuing Kerberos tickets for authentication.
- ✓
Authorization code
Why this is correct
The Authorization Code grant type is a highly secure and widely used OAuth 2.0 flow, primarily intended for confidential clients like server-side web applications. This multi-step process involves redirecting the user's browser to the authorization server to obtain user consent, which then redirects back to the client with a temporary authorization code. The client then securely exchanges this code for an access token directly with the authorization server via a back-channel request, preventing the access token from being exposed in the user's browser or URL.
Go deeper
Related to this question
Learn chapter
Identity and Access Management (IAM)
Key term
OAuth
OAuth is an open standard for access delegation that allows users to grant third-party applications limited access to their resources without sharing their credentials.
Key term
LDAP
LDAP is a protocol used to access and manage directory information over a network, such as user accounts and permissions.
About these practice questions
Courseiva writes every CISSP question from scratch — 816 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This CISSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CISSP exam.