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

  • 时间:
  • 浏览:1

其中sub代表EU的唯一标识,你这个 claim是时要的,怎么能让 的都在可选的。

Hybrid Flow则=Authorization Code Flow+Implicit Flow,但是再完整版介绍了。

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

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

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

其中看起来一堆乱码的次要但是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获取更完整版的信息。

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

理解OIDC的前提是时要理解OAuth2,这里假设其他同学都在OAuth2的基础,不清楚的可不也能先阅读本系列的前几篇OAuth2的文章。

RP使用上一步获得的code来请求Token EndPoint,你这个 步同OAuth2,就不再展开细说了。怎么能让 Token EndPoint会返回响应的Token,其中除了OAuth2规定的次要数据外,都在附加一有1个id_token的字段。id_token字段但是上面提到的ID Token。类式:

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

http://openid.net/connect/

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

案例:

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

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

视频:Identity, Authentication + OAuth = OpenID Connect

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

除了上面这8个之外,还有怎么能让 的正在制定中的扩展。看起来是挺多的,并不一定被吓到,其实 并都在很简化,除了Core核心规范内容多怎么能让 之外,另外7个都在很简单且简短的规范,另外Core是基于OAuth2的,也但是说其中越来越 来很多越来越 来很多东西在复用OAuth2,越来越 来很多越来越 来很多说你理解了OAuth2以前 ,OIDC但是非常容易理解的了,其他同学这里就只关注OIDC引入了那些新的东西(Core,其余7个可选规范不做介绍,怎么能让 肯能会提及到)。千言万语都在如一张图,没图是我不好个***。

上面提到过OIDC对OAuth2最主要的扩展但是提供了ID Token。ID Token是一有1个安全令牌,是一有1个授权服务器提供的暗含用户信息(由一组Cliams构成以及怎么能让 辅助的Cliams)的JWT格式的数据底部形态。ID Token的主要构成次要如下(使用OAuth2流程的OIDC)。

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

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

继OAuth2以前 ,感觉OIDC也要大放异彩了。其你这个 是一有1个完整版开放的标准,怎么能让 兼容众多的已有的IDP(身份提供商),比如基于SAML的、基于WS-Federation的等等已有的身份认证系统,都可不也能作为OIDC的OP指在。总结一下OIDC有那些底部形态和好处吧:

UserIndo EndPoint是一有1个受OAuth2保护的资源。在RP得到Access Token可不也也能请求此资源,怎么能让 获得一组EU相关的Claims,那些信息可不也能说是ID Token的扩展,比如肯能你其实 ID Token中只需暗含EU的唯一标识sub即可(防止ID Token过于庞大),怎么能让 通过此接口获取完整版的EU的信息。此资源时要部署在TLS之上,类式:

以上是基于Authorization Code土土妙招的OIDC的认证请求所需的参数。在OIDC的怎么能让 认证流程中也会有怎么能让 的参数或不同的参数值(稍有差异)。一有1个简单的示类式下:

以上内容均是被委托人的怎么能让 理解,肯能错误之处,欢迎指正!

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

这里有个小大大问题其他同学可不也能思考下,OAuth2中还有基于Resource Owner Password Credentials Grant和Client Credentials Grant的土土妙招来获取Access Token,为那些OIDC越来越 扩展那些土土妙招呢?

官方资料:

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.

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.

解释完了ID Token是那些,下面看后一下OIDC怎么能不能获取到ID Token,肯能OIDC基于OAuth2,越来越 来很多越来越 来很多OIDC的认证流程主但是由OAuth2的几种授权流程延伸而来的,有以下3种:

上图是官方给出的一有1个OIDC组成底部形态图,其他同学暂时只关注Core的次要,怎么能让 的次要了解是那些东西就可不也能了,当作黑盒来用。就像当初的AJAX一样,它其实 并都在一有1个新的技术,但是结合越来越 来很多越来越 来很多已有的技术,按照规范的土土妙招组合起来,但是AJAX。同理,OIDC也都在新技术,它主但是借鉴OpenId的身份标识,OAuth2的授权和JWT包装数据的土土妙招,把那些技术融合在并肩但是OIDC。

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

Client Credentials Grant你这个 土土妙招根本就不时要用户参与,更谈不上用户身份认证了。这也能反映授权和认证的差异,以及只使用OAuth2来做身份认证的事情是远远不足英文的,也是不至少的。

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

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

OIDC你这个 是有多个规范构成,其饱暗含一有1个核心的规范,多个可选支持的规范来提供扩展支持,简单的来看一下:

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

成功以前 响应如下:

也可不也能是一有1个基于3002的重定向土土妙招。

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

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

从抽象的厚度来看,OIDC的流程由以下五个步骤构成:

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

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

OAuth2提供了Access Token来防止授权第三方客户端访问受保护资源的大大问题;OIDC在你这个 基础上提供了ID Token来防止第三方客户端标识用户身份认证的大大问题。OIDC的核心在于在OAuth2的授权流程中,并肩提供用户的身份认证信息(ID Token)给到第三方客户端,ID Token使用JWT格式来包装,得益于JWT(JSON Web Token)的自暗含性,紧凑性以及防篡改机制,使得ID Token可不也能安全的传递给第三方客户端线程怎么能让 容易被验证。此外还提供了UserInfo的接口,用户获取用户的更完整版的信息。

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