OpenID Connect (OIDC) is a simple identity layer on top of the OAuth 2.0 protocol. OIDC implements authentication as an extension to the OAuth 2.0 authorization process. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. Which of the following statements about OIDC and OAuth 2.0 is not true?
A. OAuth 2.0 Clients using OIDC are also referred to as Relying Parties (RPs).
B. OAuth 2.0 Authentication Servers implementing OIDC are also referred to as OpenID Providers (OPs).
C. OAuth 2.0 Clients obtain authorization from the resource server to request access tokens.
D. OAuth 2.0 Clients use different authorization grants or flow to request access tokens based on their types.
Kindly be reminded that the suggested answer is for your reference only. It doesn’t matter whether you have the right or wrong answer. What really matters is your reasoning process and justifications.
My suggested answer is C. OAuth 2.0 Clients obtain authorization from the resource server to request access tokens.
OAuth 2.0 clients obtain the authorization grant from the resource owner, for the subsequent request for access tokens to employ resources.
According to RFC 6749, there are five types of authorization grant:
- Authorization Code (Web App)
- Implicit (Third-party client)
- Resource Owner Password Credentials (First-party client)
- Client Credentials (Machine)
- Extension Grants (Absolute URI)
Access tokens are credentials used to access protected resources. OIDC and SAML are well-known standards to describe or normalized access tokens. However, OIDC is built on top of OAuth 2.0 as its extension.
Access tokens are credentials used to access protected resources. An
access token is a string representing an authorization issued to the
client. The string is usually opaque to the client. Tokens
represent specific scopes and durations of access, granted by the
resource owner, and enforced by the resource server and authorization
The token may denote an identifier used to retrieve the authorization
information or may self-contain the authorization information in a
verifiable manner (i.e., a token string consisting of some data and a
signature). Additional authentication credentials, which are beyond
the scope of this specification, may be required in order for the
client to use a token.
The access token provides an abstraction layer, replacing different
authorization constructs (e.g., username and password) with a single
token understood by the resource server. This abstraction enables
issuing access tokens more restrictive than the authorization grant
used to obtain them, as well as removing the resource server’s need
to understand a wide range of authentication methods.
Access tokens can have different formats, structures, and methods of
utilization (e.g., cryptographic properties) based on the resource
server security requirements. Access token attributes and the
methods used to access protected resources are beyond the scope of
this specification and are defined by companion specifications such
Source: RFC 6749
- The OAuth 2.0 Authorization Framework (RFC 6749)
- Which OAuth 2.0 Flow Should I Use?
- OAuth 2.0 Authorization Framework
- An Illustrated Guide to OAuth and OpenID Connect
- Welcome to OpenID Connect
- OAuth vs. OpenID – What’s the difference?
- Understanding OAuth 2.0 and OpenID Connect
- What’s the Difference Between OAuth, OpenID Connect, and SAML?
A BLUEPRINT FOR YOUR SUCCESS IN CISSP
My new book, The Effective CISSP: Security and Risk Management, helps CISSP aspirants build a solid conceptual security model. It is not only a tutorial for information security but also a study guide for the CISSP exam and an informative reference for security professionals.
OpenID Connect (OIDC)是架構在OAuth 2.0協議之上的簡易身份(Identity)層。 OIDC可實現身份驗證，是OAuth 2.0授權程序的擴充。透過授權服務器的身份驗證機制，OIDC讓客戶端(Clients)能夠驗證最終用戶(End-User)的身份，並以可互動及類似於REST的方式取得與最終用戶相關的基本資料。下列關於OIDC和OAuth 2.0的哪些說法不正確？
A. 使用OIDC的OAuth 2.0客戶端(Clients)也稱為依賴方(Relying Parties, RPs)
B. 實現OIDC的OAuth 2.0身份驗證服務器也稱為OpenID提供者(OpenID Providers, OPs)
C. OAuth 2.0客戶端從資源服務器(Resource Server)獲取授權以請求訪問令牌(Access Token)
D. OAuth 2.0客戶端根據其類型使用不同的授權授予(Grant)或流程來請求訪問令牌(Access Token)