[认证授权] 4.OIDC(OpenId Connect)身份认证授权(核心部分)

  • 时间:
  • 浏览:1
  • 来源:大发5分快3_极速5分PK10

主要的术语以及概念介绍(完正术语参见http://openid.net/specs/openid-connect-core-1_0.html#Terminology):

http://openid.net/connect/faq/

都能否 只有是一个基于1502的重定向土方式 。

笔者基于IdentityServer3和IdentitySever4(两者都不 基于OIDC的一个.NET版本的开源实现)写的一个集成SSO,API访问授权控制,QQ联合登陆(作为OP)的demo:https://github.com/linianhui/oidc.example 。

成功过后响应如下:

这里有个小问题报告 图片一点人 能只有思考下,OAuth2中还有基于Resource Owner Password Credentials Grant和Client Credentials Grant的土方式 来获取Access Token,为有哪些OIDC没办法 扩展有有哪些土方式 呢?

理解OIDC的前提是都要理解OAuth2,这里假设一点人 都不 OAuth2的基础,不清楚的能只有先阅读本系列的前几篇OAuth2的文章。

OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题报告 图片;OIDC在一种生活基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题报告 图片。OIDC的核心在于在OAuth2的授权流程中,一同提供用户的身份认证信息(ID Token)给到第三方客户端,ID Token使用JWT格式来包装,得益于JWT(JSON Web Token)的自涵盖性,紧凑性以及防篡改机制,使得ID Token能只有安全的传递给第三方客户端tcp连接否则容易被验证。此外还提供了UserInfo的接口,用户获取用户的更完正的信息。

继OAuth2过后,感觉OIDC也要大放异彩了。其一种生活是一个完正开放的标准,否则兼容众多的已有的IDP(身份提供商),比如基于SAML的、基于WS-Federation的等等已有的身份认证系统,都能只有作为OIDC的OP位于。总结一下OIDC有有有哪些特征和好处吧:

RP使用上一步获得的code来请求Token EndPoint,一种生活步同OAuth2,就不再展开细说了。否则Token EndPoint会返回响应的Token,其中除了OAuth2规定的每段数据外,都不 附加一个id_token的字段。id_token字段就说 后面 提到的ID Token。累似 :

OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.

OIDC可能性有就说 的企业在使用,比如Google的账号认证授权体系,Microsoft的账号体系也部署了OIDC,当然有有哪些企业有的也是OIDC肩头的推动者。除了有有哪些之外,有就说 各个语言版本的开源服务端组件,客户端组件等等(http://openid.net/developers/certified/);

http://openid.net/connect/

JWS:https://tools.ietf.org/html/rfc7515

Resource Owner Password Credentials Grant是都要用途提供账号密码给RP的,账号密码给到RP了,都要有哪些自行车(ID Token)。。。

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

从抽象的淬硬层 来看,OIDC的流程由以下三个步骤构成:

上图取自Core规范文档,其中AuthN=Authentication,表示认证;AuthZ=Authorization,代表授权。注意这后面 RP发往OP的请求,是属于Authentication类型的请求,确实 在OIDC中是复用OAuth2的Authorization请求通道,否则用途是不一样的,且OIDC的AuthN请求中scope参数都要要三个值为的openid的参数(后面 会完正介绍AuthN请求所需的参数),用来区分这是一个OIDC的Authentication请求,而都不 OAuth2的Authorization请求。

以上这三个参数是和OAuth2相同的。除此之外,还定义了如下的参数:

https://developers.google.com/identity/protocols/OpenIDConnect

UserIndo EndPoint是一个受OAuth2保护的资源。在RP得到Access Token能只有只有请求此资源,否则获得一组EU相关的Claims,有有哪些信息能只有说是ID Token的扩展,比如何能性你确实 ID Token中只需涵盖EU的唯一标识sub即可(解决ID Token过于庞大),否则通过此接口获取完正的EU的信息。此资源都要部署在TLS之上,累似 :

其中sub代表EU的唯一标识,一种生活claim是都要的,一点的都不 可选的。

一种生活土方式 使用OAuth2的Authorization Code的土方式 来完成用户身份认证,所有的Token都不 通过Token EndPoint(OAuth2中定义:https://tools.ietf.org/html/rfc6749#section-3.2)来发放的。构建一个OIDC的Authentication Request都要提供如下的参数:

http://openid.net/developers/certified/

Client Credentials Grant一种生活土方式 根本就不都要用户参与,更谈不上用户身份认证了。这都能否 反映授权和认证的差异,以及只使用OAuth2来做身份认证的事情是远远不足的,也是不为宜的。

案例:

Hybrid Flow则=Authorization Code Flow+Implicit Flow,就说 再完正介绍了。

官方资料:

简单来说:OIDC是OpenID Connect的简称,OIDC=(Identity, Authentication) + OAuth 2.0。它在OAuth2上构建了一个身份层,是一个基于OAuth2协议的身份认证标准协议。一点人 都知道OAuth2是一个授权协议,它无法提供完善的身份认证功能(关于一种生活点请参考[认证授权] 3.基于OAuth2的认证(译)),OIDC使用OAuth2的授权服务器来为第三方客户端提供用户的身份认证,并把对应的身份认证信息传递给客户端,且能只有适用于各种类型的客户端(比如服务端应用,移动APP,JS应用),且完正兼容OAuth2,也就说 说你搭建了一个OIDC的服务后,都能否 只有当作一个OAuth2的服务来用。应用场景如图:

本文版权归作者和博客园共有,欢迎转载,但未经作者同意都要保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

在授权服务器接收到认证请求过后,都要对请求参数做严格的验证,具体的规则参见http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation,验证通过后引导EU进行身份认证否则同意授权。在一种生活切都完成后,会重定向到RP指定的回调地址,否则把code和state参数传递过去。比如:

上图是官方给出的一个OIDC组成特征图,一点人 暂时只关注Core的每段,一点的每段了解是有哪些东西就能只有了,当作黑盒来用。就像当初的AJAX一样,它确实 并都不 一个新的技术,就说 结合就说 已有的技术,按照规范的土方式 组合起来,就说 AJAX。同理,OIDC也都不 新技术,它主就说 借鉴OpenId的身份标识,OAuth2的授权和JWT包装数据的土方式 ,把有有哪些技术融合在一同就说 OIDC。

后面 提到过OIDC对OAuth2最主要的扩展就说 提供了ID Token。ID Token是一个安全令牌,是一个授权服务器提供的涵盖用户信息(由一组Cliams构成以及一点辅助的Cliams)的JWT格式的数据特征。ID Token的主要构成每段如下(使用OAuth2流程的OIDC)。

视频:Identity, Authentication + OAuth = OpenID Connect

.NET的开源实现:https://github.com/IdentityServer

OIDC一种生活是有多个规范构成,其中涵盖一个核心的规范,多个可选支持的规范来提供扩展支持,简单的来看一下:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-openid-connect-code

其中看起来一堆乱码的每段就说 JWT格式的ID Token。在RP拿到有有哪些信息过后,都要对id_token以及access_token进行验证(具体的规则参见http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation和http://openid.net/specs/openid-connect-core-1_0.html#ImplicitTokenValidation)。至此,能只有说用户身份认证就能只有完成了,后续能只有根据UserInfo EndPoint获取更完正的信息。

ID Token通常具体情况下都不 涵盖一点的Claims(毕竟上述claim中只有sub是和EU相关的,这在一般具体情况下是不足的,都要还都要EU的用户名,头像等一点的资料,OIDC提供了一组公共的cliams,请移步这里http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)。另外ID Token都要使用JWS进行签名和JWE加密,从而提供认证的完正性、不可敲定 性以及可选的保密性。一个ID Token的例子如下:

JWT : https://tools.ietf.org/html/rfc7519

以上是基于Authorization Code土方式 的OIDC的认证请求所需的参数。在OIDC的一点认证流程中也会有一点的参数或不同的参数值(稍有差异)。一个简单的示累似 下:

Implicit Flow的工作土方式 是在OAuth2 Implicit Flow上附加提供id_token,当然,认证请求的参数和基于Authorization Code的流程稍有不同,具体的差异参见http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest,这里就不做完正介绍了。

除了后面 这8个之外,还有一点的正在制定中的扩展。看起来是挺多的,无需被吓到,确实 并都不 很复杂,除了Core核心规范内容多一点之外,另外7个都不 很简单且简短的规范,另外Core是基于OAuth2的,也就说 说其中就说 东西在复用OAuth2,就说 说你理解了OAuth2过后,OIDC就说 非常容易理解的了,一点人 这里就只关注OIDC引入了有哪些新的东西(Core,其余7个可选规范不做介绍,否则可能性会提及到)。千言万语都不 如一张图,没图你爱不爱我个***。

解释完了ID Token是有哪些,下面看到一下OIDC如何获取到ID Token,可能性OIDC基于OAuth2,就说 OIDC的认证流程主就说 由OAuth2的几种授权流程延伸而来的,有以下3种:

JWE:https://tools.ietf.org/html/rfc7516

看一下官方的介绍(http://openid.net/connect/):

以上内容均是人及的一点理解,可能性错误之处,欢迎指正!