OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. Which of the following is incorrect? (Wentz QOTD)
A. OpenID 2.0 used XML and a custom message signature scheme, while OIDC employs JSON.
B. The OpenID Provider performs authentication and provides the ID Token as a JSON Web Token.
C. The OAuth 2.0 authorization server authenticates the end-user as a human participant.
D. OAuth 2.0 specifies access tokens to access resources and standard methods to provide identity information.

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 D. OAuth 2.0 specifies access tokens to access resources and standard methods to provide identity information.

Wentz’s book, The Effective CISSP: Security and Risk Management, helps CISSP and CISM aspirants build a solid conceptual security model. It is a tutorial for information security and a supplement to the official study guides for the CISSP and CISM exams, and an informative reference for security professionals.

OAuth 2.0 specifies access tokens to access resources, but it doesn’t provide standard methods to provide identity information (ID Token), and that’s why OpenID Connect (ODIC) comes in.

• (Identity, Authentication) + OAuth 2.0 = OpenID Connect
• OIDC is the third generation of OpenID technology, which aligned with OAuth 2.0 and switched from XML to JSON.
• OIDC takes care of identity and authentication by ID tokens, and OAuth 2.0 deals with authorization through access/bearer tokens.
• As OIDC is built on top of OAuth 2.0, the OpenID provider is essentially the same as the OAuth 2.0 authorization server.

ID Token

Bearer Token

Any party in possession of a bearer token (a “bearer”) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

Source: RFC 6750

Microsoft.AspNetCore.Authentication.JwtBearer is a software component that handles bearer tokens in .NET 5.0.

OpenID Connect (OIDC) and OAuth 2.0

OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”. It’s uniquely easy for developers to integrate, compared to any preceding Identity protocol.

OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, it provides a secure verifiable, answer to the question: “What is the identity of the person currently using the browser or native app that is connected to me?”

OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.

(Identity, Authentication) + OAuth 2.0 = OpenID Connect

Source: OpenID Connect FAQ and Q&As

Earlier Versions of OpenID

OpenID Connect is the third generation of OpenID technology. The first was the original OpenID, a visionary’s tool that never got much commercial adoption, but got industry leaders thinking about what was possible. OpenID 2.0 was much more fully thought through, offered excellent security, and worked well when implemented properly. However, it suffered from several design limitations – foremost among them that Relying Parties could be Web pages but not native applications; it also relied upon XML, leading to some adoption problems.

OpenID Connect’s goal is to be much more developer-friendly, while expanding the set of use cases where it can be used. It has already been successful in this; there are production deployments operating at huge scale. Any programmer with sufficient experience to send and receive JSON messages over HTTP (which is most of them these days) should be able to implement OpenID Connect from scratch using standard crypto signature-verification libraries. Fortunately, most won’t even have to go that far, as there are good commercial and open-source libraries that take care of the authentication mechanics.

Source: OpenID Connect FAQ and Q&As

OAuth 2.0 Abstract Protocol Flow

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

             OAuth 2.0 Abstract Protocol Flow

OIDC Protocol Flow

The OpenID Connect protocol, in abstract, follows the following steps.

1. The RP (Client) sends a request to the OpenID Provider (OP).
2. The OP authenticates the End-User and obtains authorization.
3. The OP responds with an ID Token and usually an Access Token.
4. The RP can send a request with the Access Token to the UserInfo Endpoint.
5. The UserInfo Endpoint returns Claims about the End-User.

These steps are illustrated in the following diagram:

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+

                   OIDC Protocol Flow

Reference

• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
• OAuth 2.0
• Welcome to OpenID Connect
• OpenID Connect FAQ and Q&As
• OAuth 2.0 / OpenID Connect Explained
• Understanding ID Token
• Pass an identity provider access token to your application in Azure Active Directory B2C
• AccessToken Vs ID Token Vs Refresh Token – What? Why? When?

---

OpenID Connect 是 OAuth 2.0 協議之上的一個簡單身份層。 以下哪項敍述是不正確的？ (Wentz QOTD)
A. OpenID 2.0 使用 XML 和自定義消息簽名方案，而 OIDC 使用 JSON。
B. OpenID Provider 執行身份驗證並提供 JSON Web Token形式的 ID Token。
C. OAuth 2.0 授權服務(AS)器對最終用戶(人類參與者)進行身份驗證。
D. OAuth 2.0 指定了存取資源的訪問令牌(access token)和提供身份信息的標準方法。