OpenID Connect：OAuth 2.0协议之上的简单身份层

• OpenID Connect是什么？OpenID Connect(目前版本是1.0)是OAuth 2.0协议(可参考本人此篇：OAuth 2.0 / RCF6749 协议解读)之上的简单身份层，用 API 进行身份交互的框架，允许客户端根据授权服务器的认证结果最终确认用户的身份，以及获取基本的用户信息；它支持包括Web、移动、JavaScript在内的所有客户端类型；它是可扩展的协议，允许你使用某些可选功能，如身份数据加密、OpenID提供商发现、会话管理

• OpenID Connect vs OpenID 2.0：OpenID Connect完成很多与OpenID 2.0相同的任务，是API-friendly，定义了可选的签名和加密的机制；OAuth 1.0a和OpenID 2.0的集成需要扩展，而OpenID Connect协议本身就建立在OAuth 2.0之上

• 部分名词解释：

  1. Relying Party(RP)：依赖方，通常是第三方应用程序(客户端)
  2. OpenID Provider(OP)：OpenID 提供方，通常是一个 OpenID 认证服务器，它能为依赖方提供断言以证实用户拥有某个标识
  3. End-User(EU)：终端用户，指持有账号的人

• OpenID Connect协议构成：

  下边两条是 Web RPs 实现者的独立参考指南:

  协议迁移规范:

  OpenID Connect 工作组已启动新的工作计划:

  

• 1. OpenID Connect Profile for SCIM Services – (Optional) Defines how to use SCIM with OpenID Connect

  2. OpenID Connect Federation – (Optional) Defines how sets of OPs and RPs can establish trust by utilizing a Federation Operator

  1. OpenID 2.0 to OpenID Connect Migration 1.0 – Defines how to migrate from OpenID 2.0 to OpenID Connect

  1. Basic Client Implementer’s Guide – Simple subset of the Core functionality for a web-based Relying Party using the OAuth code flow

  2. Implicit Client Implementer’s Guide – Simple subset of the Core functionality for a web-based Relying Party using the OAuth implicit flow

  1. Core – 定义 OpenID Connect 核心功能: 认证建立在OAuth 2.0之上，使用声明与终端用户进行信息交互

  2. Discovery – (Optional) Defines how Clients dynamically discover information about OpenID Providers

  3. Dynamic Registration – (Optional) Defines how clients dynamically register with OpenID Providers

  4. OAuth 2.0 Multiple Response Types – 定义了几种新的OAuth 2.0响应类型

  5. OAuth 2.0 Form Post Response Mode – (Optional) Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User Agent using HTTP POST

  6. Session Management – (Optional) Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality

  7. Front-Channel Logout – (Optional) Defines a front-channel logout mechanism that does not use an OP iframe on RP pages

  8. Back-Channel Logout – (Optional) Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out

• OpenID Connect的工作流程：下以EU获取UserInfo为例来说明，

  1. RP(客户端)发送一个认证请求给OP；
  2. OP对EU进行身份认证并获得授权；
  3. OP发送ID Token给RP，通常也同时发送Access Token(为兼容OAuth 2.0。ID Token其实可以取代Access Token用来完成授权)；
  4. RP使用Access Token发送一个请求UserInfo EndPoint；
  5. UserInfo EndPoint返回EU的Claims。

  

  下边是关于“ID Token 与 Access Token”的描述来自 User Authentication with OAuth 2.0 [UserInfo Endpoint]：

  It should be noted that clients are not required to use the access token, since the ID Token contains all the necessary information for processing the authentication event. However, in order to provide c