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]：