OpenID Connect Core 1.0介绍

Posted 2021-01-13 athinker

IdentityServer4是基于OpenID Connect and OAuth 2.0框架，OpenID Connect Core 1.0是IdentityServer4最重要的文档

By 道法自然  2018年

摘要

OpenID Connect Core 1.0是一个在OAuth 2.0 [RFC6749]协议之上简单的身份层。它使客户验证基于由授权服务器验证终端用户的身份,以及获得互操作的基本概要信息和终端用户REST-like方式。

这个规范定义了 OpenID Connect核心功能：验证基于OAuth 2.0和使用声明式的终端用户的信息交流程。它还描述了使用OpenID Connect的安全和隐私问题。

1 介绍（Introduction）

作为背景，OAuth 2.0授权框架 (OAuth 2.0 Authorization Framework [RFC6749]) 和 OAuth 2.0无记名令牌用法 (OAuth 2.0 Bearer Token Usage [RFC6750]) 规范为第三方应用程序获得和使用有限的HTTP访问资源提供了一个总体框架。他们定义了获取和使用令牌访问资源的访问机制，没有定义标准方法提供身份信息。值得注意的是，如果对OAuth 2.0不加以了解,就不能实现提供终端用户的验证信息功能。读者应该熟悉这些规范。

OpenID Connect扩展实现了OAuth 2.0验证授权过程。使用这个扩展客户端授权请求，要求包括请求的openid scope值。在一个 JSON Web Token (JWT)中返回执行验证的一个称之为ID Token信息(见第二节 )。OAuth 2.0实现OpenID验证服务器连接,也被称为OpenID提供者(OPs)。OAuth 2.0客户端使用OpenID Connect 也被称为依赖方(RPs)。

这个规范假定依赖方已经获得 OpenID提供者的配置信息,包括它的授权终结点和令牌终结点位置。这些信息通常是通过发现获得（OpenID Connect Discovery 1.0  OpenID Discovery)中描述，或通过其他机制可以获得。

同样，这个规范假定依赖方已经获得需要使用OpenID提供者提供的足够多的凭证和信息。这通常是通过OpenID Connect Dynamic Client Registration 1.0中描述动态注册，或通过其他机制可以获得。

1.1 符号和约定要求（Requirements Notation and Conventions）

关键词“必须”、“不能”、“需要”、“应当”,“不得”，“应该”、“不应该”,“推荐”,“不推荐”、“可能”和“可选的” 文档中描述将被解释为 RFC 2119 [RFC2119]。

在.txt版本的文档中，应该从字面上理解这些词的意思。当在协议消息中使用这些词，引述不能作为值的一部分。在本文档的html版本，值按字面所示 的固定宽度字体使用。

本规范中JSON Web Signature (JWS)和JSON Web Encryption (JWE)的数据结构使用JWS压缩序列化或JWE压缩序列化; 不使用JWS JSON序列化和 JWE JSON序列化。

1.2 术语（Terminology）

该规范使用术语“访问令牌（Access Token）”,“授权码（Authorization Code）”，“授权终结点（Authorization Endpoint）”、“授权许可（Authorization Grant）”、“授权服务器（Authorization Server）”，“客户端（Client）”、“客户端验证（Client Authentication）”、“客户标识符（Client Identifier）”,“客户端密钥（Client Secret）”，“许可类型（Grant Type）”、“受保护资源（Protected Resource）”,“重定向URI（Redirection URI）”、“刷新令牌（Refresh Token）”，“资源所有者（Resource Owner）”、“资源服务器（Resource Server）”、“响应类型（Response Type）”,“令牌终结点（Token Endpoint）” 定义为 OAuth 2.0 (RFC6749)，术语“声明名称（Claim Name）”、“声明值（Claim Value）”,“JSON Web Token(JWT)”，“JWT声明集”,“嵌套JWT” 定义为 JSON Web Token(JWT) JWT，术语“Header Parameter”和“JOSE Header” 定义为 JSON Web Signature (JWS)，“用户代理”一词的定义 RFC 2616 [RFC2616]，和定义的术语“响应模式（Response Mode）” OAuth 2.0多个响应类型编码实践 [OAuth.Responses]。

此规范还定义了以下术语：

Authentication（验证）

提供在实体和提供身份两者间建立足够的信任操作。

Authentication Request（验证请求）

OAuth 2.0授权请求通过扩展参数和范围定义，为OpenID Connect从授权服务器到终端用户认证请求，是OpenID Connect提供者，对于客户端,是OpenID Connect依赖。

Authentication Context（验证上下文）

在依赖方需要的信息之前，对验证响应权利做出决定。这种上下文可以包括但不限于,实际的验证方法或保障级别等 ISO/IEC 29115 (ISO29115) 实体验证保障级别。

Authentication Context Class(验证上下文类)

验证方法或程序集，相当于在一个特定的上下文。

Authentication Context Class Reference（验证上下文类引用）

验证上下文类标识符。

Authorization Code Flow（授权码流程）

OAuth 2.0流程包含从授权终结点返回的授权码和从令牌终结点返回的所有令牌。

Authorization Request（授权请求）

OAuth 2.0定义的授权请求 (RFC6749) 。

Claim（声明）

信息断言一个实体。

Claim Type（声明类型）

用于代表声明值的语法。这个规范定义了正常、合并和分离的声明类型。

Claims Provider（声明提供者）

可返回的关于实体的服务器声明。

Credential（凭证）

作为可使用身份或其他资源权利证据的数据呈现。

End-User（终端用户）

参与的人。

Entity（实体）

确定在一个上下文中单独、独特的存在的东西。终端用户就是一个实体例子。

Essential Claim（基本声明）

指定客户端必要的声明，以确保终端用户流程畅授权的特定任务体验。

Hybrid Flow（混合流程）

OAuth 2.0流程包含有从授权终结点返回授权码，授权终结点返回的授权令牌,和从其他令牌终结点返回的令牌。

ID Token（令牌标识）

JSON Web Token(JWT)包含关于验证事件。它可能包含其他声明。

Identifier（标识符）

描述一个实体在一个特定上下文的唯一值。

Identity（身份）

一组相关实体属性。

Implicit Flow（隐式流程）

OAuth 2.0 流程从授权终结点返回的所有令牌，但不调用令牌终结点和授权码。

Issuer（发行人）

实体中关于发行人的声明。

Issuer Identifier（发布者标识符）

可验证发行人的标识符。发布者标识符是一个区分大小写的https 格式的URL，包含scheme、主机和可选端口号和路径组件，但没有任何查询或片段组件。

Message（消息）

OpenID依赖和OpenID提供者之间的请求或响应，。

OpenID Provider (OP，OpenID提供者）

OAuth 2.0验证服务器为终端用户和提供声明给认证事件与终端用户的依赖方赋予验证的能力。

Request Object（请求对象）

JWT包含一组请求参数声明。

Request URI（请求URI）

包含请求对象的资源引用的URL。请求URI包含必需由授权服务器检索的内容。

Pairwise Pseudonymous Identifier（成对匿名标识符(PPID))

不能关联的依赖方实体身份和实体的另一个PPID依赖方的标识。

Personally Identifiable Information（个人身份信息(PII)）

可以用来识别自然人的信息（a），这些信息涉及谁,或 (b)是可能直接或间接有关涉及这些信息自然人。

Relying Party (RP)(依赖方)

需要用户验证和OpenID提供者的声明之OAuth 2.0客户机应用程序。

Sector Identifier（企业标识符）

主机组件依赖方所使用的URL的组织，这是一个输入的计算成对Subject标识符的依赖方。

Self-Issued OpenID Provider（自发行OpenID提供者）

解决自签名ID令牌的个人的，自托管OpenID提供者。

Subject Identifier（子标识符）

当地独特的,在客户端使用的，从不在终端用户的发行人重新分配标识符。

UserInfo Endpoint（用户信息终结点）

受保护的资源。当面对客户提供访问令牌时，返回关于终端用户授权、许可等信息。用户信息终结点URL必须使用 https 方案和可能包含的端口号、路径和查询参数组件。

Validation（验证）

目的是为了检查完整性或构造的正确性操作。

Verification（验证）

目的是为了测试或证明真理、事实、值的准确性操作。

Voluntary Claim（自愿声明）

要求指定的客户端是可用的但不是终端用户要求的特定任务必不可少的。

重要提示:本节术语定义是本规范的实现实施需求的规范部分。在本规范的文本中所有的大写的单词,如 “Issuer Identifier”。只要读者遇到引用这些定义术语时，必须遵循在本节中所见的对这些术语定义。

更多的背景使用的一些术语，参看网络安全术语表第2版 (RFC4949)，ISO/IEC 29115实体验证保证 (ISO29115)和 ITU-T X.1252 [X.1252]。

 

1.3 概述（Overview）

OpenID Connect协议,抽象层面,遵循以下步骤。

1、RP(客户端)发送一个请求到OpenID提供者(OP)。

2、OP验证终端用户和获得授权。

3、OP 应答ID令牌和通用的访问令牌。

4、 RP可以使用访问令牌给用户令牌终结点发送请求。

5、用户信息终结点返回终端用户声明。

 

原文：https://openid.net/specs/openid-connect-core-1_0.html