OpenID Connect Core 1.0(一)介绍

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

原文地址:https://www.cnblogs.com/athinker/p/9740801.html

时间: 2024-11-07 09:12:54

OpenID Connect Core 1.0(一)介绍的相关文章

OpenID Connect Core 1.0(四)使用授权码流验证(上)

3.1 使用授权码流验证(Authentication using the Authorization Code Flow) 本节描述如何使用授权码流执行验证.当使用授权码流时,会从令牌终结点返回的所有令牌. 授权码流返回授权码给客户端,这个授权码可以直接交换一个ID Token和一个Access Token.这给User Agent提供了不暴露任何令牌的好处,因为可能还有其他恶意的应用程序访问User Agent.授权服务器也可以在验证客户端之前通过Access Token交换的授权码.授权码

OpenID Connect Core 1.0(九)声明(Claims)

5 声明(Claims) 这一节说明客户端如何获取关于终端用户声明和验证事件.它还定义了一组标准的基本声明配置.预定义一组可请求的声明,使用特定的scope值或能用于请求参数中的个人声明.声明可以直接来自OpenID提供者或分布式来源. 5.1 标准声明(Standard Claims) 这个规范定义了一组标准的声明.他们可以请求的返回或用户信息的响应,此在 5.3.2节或在第二节中的ID Token. sub string 在发行人终端用户的主体标识符. name  string 终端用户的全

IdentityServer4 ASP.NET Core的OpenID Connect OAuth 2.0框架学习保护API

IdentityServer4 ASP.NET Core的OpenID Connect OAuth 2.0框架学习之保护API. 使用IdentityServer4 来实现使用客户端凭据保护ASP.NET Core Web API 访问. IdentityServer4 GitHub: https://github.com/IdentityServer/IdentityServer4 IdentityServer 框架支持以下功能: 身份验证服务所有应用程序(Web,本机,移动,服务)的集中登录

一个功能完备的.NET开源OpenID Connect/OAuth 2.0框架——IdentityServer3

今天推荐的是我一直以来都在关注的一个开源的OpenID Connect/OAuth 2.0服务框架--IdentityServer3.其支持完整的OpenID Connect/OAuth 2.0标准,使用它就可以轻易地搭建一个单点登录服务器. 说是一直关注,是因为1年前,要为一个平台搭建一个OAuth 2.0服务器,当时由于IdentityServer3还处于开发阶段,核心还不稳定,扩展功能也不完备.无奈只好熟读OAuth 2.0的规范,并根据www.asp.net网站上的一个简单示例自己实现了

IdentityServer4 使用OpenID Connect添加用户身份验证

使用IdentityServer4 实现OpenID Connect服务端,添加用户身份验证.客户端调用,实现授权. IdentityServer4 目前已更新至1.0 版,在之前的文章中有所介绍.IdentityServer4 ASP.NET Core的OpenID Connect OAuth 2.0框架学习保护API . 本文环境:IdentityServer4 1.0  .NET Core 1.0.1 下面正式开始. 新建IdentityServer4服务端 服务端也就是提供服务,如QQ

(译)欢迎来到OpenID Connect(一)

什么是OpenID Connect OpenID Connect1.0是一个位于OAuth2.0之上的简单的身份层.其允许客户端通过授权服务器验证终端用户身份,通过互操作性和REST-like性获取终端客户的基本概要信息. OpenID连接允许所有类型的客户,包括网络.手机.和JavaScript客户,请求和接收经过身份验证的会话和最终用户的信息.规范套件是可扩展的,提供可选特性,例如加密身份数据.发现OpenID提供者.会话管理,这些都是有意义的. http://openid.net/conn

【.Net Core 2.0 生态】-- 好文收藏

随笔分类 - .NET Core - dotNet实训营 .Net Core 2.0 生态(1).NET Standard 2.0 特性介绍和使用指南 .Net Core 2.0 生态(2).NET Core 2.0 特性介绍和使用指南 .Net Core 2.0生态(3):ASP.NET Core 2.0 特性介绍和使用指南 蒙 2017-08-21 13:56 周一

OpenID Connect的常见问题与答案

OpenID Connect的常见问题与答案 OpenID Connect是什么,它是怎么样工作的? OpenID Connect是可互操作的身份验证协议基于OAuth 2.0规范族.它使用简单的REST / JSON消息流实现"让简单的事情变得简单和复杂的事情变为可能"的设计目标.开发者可以轻松集成.比较之前任何一种身份认证协议. OpenID Connect允许开发者验证跨网站和应用程序的用户,而无需拥有和管理密码文件.app builder,它提供了一个安全的可核查的,回答这个问

Net Core 2.0生态1

Net Core 2.0生态 阅读目录 前言:答读者问(time by:2017.8.19) 项目升级到ASP.NET Core 2.0 新增功能:Razor Pages介绍 模板更新 Entity Framework Core 2.0提供DbContext池 监视器.无代码更改配置.应用程序监视器 Razor支持C# 7.1 简化应用程序的主机配置 总结 ASP.NET Core 2.0 发布日期:2017年8月14日 ASP.NET团队宣布ASP.NET Core 2.0正式发布,发布Vis