CISSP Identity and Access Management Practice Question

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