网站这么上百度,天王手表官方网站,临沂哪里做网站,电子商务网站建设与管理王生春在微服务场景中#xff0c;身份认证通常是集中处理#xff0c;这也是有别于单体应用一把梭哈的模式#xff0c;其中#xff0c;在微软微服务白皮书中#xff0c;提供了两种身份认证模式#xff1a;网关#xff0c;没错#xff0c;原话是If youre using an API Gateway,… 在微服务场景中身份认证通常是集中处理这也是有别于单体应用一把梭哈的模式其中在微软微服务白皮书中提供了两种身份认证模式网关没错原话是If youre using an API Gateway, the gateway is a good place to authenticateimgSTSsecurity token serviceDiagram showing authentication through backend microservices.如果使用网关进行集中身份认证微服务如果没有设置了额外的安全性来验证消息就必须确保微服务在没有经过网关的时候不能直接被访问。从图中也可看到用户信息是由网关进行转发请求时增加的。如果使用STS进行集中身份认证是可以直接访问服务需要使用安全令牌服务(STS)的专用身份验证单独的服务微服务对用户进行身份验证。由STS颁发token然后在请求微服务时就需要在请求中携带token。我们文章后续主要就是围绕着STS安全令牌服务中间件IdentityServer4来具体展开的。1.引言1.1 实际遇到的问题在之前一个单体web系统中采用的是前后端分离前端是Vue 2.0后端使用的ASP.NET Web Api 2.0提供后台服务登录模块采用了JWT(JSON WEB TOKEN)的身份认证方式在用户请求时后台自定义解析JWT然后把解析的部分结果装进HttpContext.Principal,供后续授权操作。那时会遇到一个问题前端并没有mock开发而是连接后端测试环境开发前端在开发调试时后端同步发布最新接口再加上IIS老版本发布web服务会有一个初次访问非常慢的问题这时前端就会炸锅“后端挂了请求不到JWT”这个过程其实挺影响开发效率的那时就萌生了把身份认证和授权单独作为一个项目部署由于本身属于项目基础设施改动的频率几乎为0业务层面也可以按需拆分这可能就是我最早微服务思路的萌芽吧1.2 其他问题微信公众号开发做过微信公众号开发我们大多数应用都希望用户通过微信进行操作然后留存用户信息我们需要经过如下步骤向微信官方申请AppIdAppsecret,还有单独一个加密密钥然后请求https://open.weixin.qq.com/connect/oauth2/authorize?appidwx6953deeefe22a83bredirect_uriyour_addressresponse_typecodescopesnsapi_userinfostateSTATE#wechat_redirect这里用户访问需要用户授权然后微信浏览器会重定向至上一步的redirect_uri指定的网址且还会在querystring加上code这个code记住然后就可以通过codehttps://api.weixin.qq.com/sns/oauth2/access_token?appid{0}secret{1}code{2}grant_typeauthorization_code在后台获取access_tokenopenidaccess_token是凭证openid是微信的用户体系最后就能通过https://api.weixin.qq.com/sns/userinfo?access_token{0}openid{1}langzh_CN,就能通过上一步中获取到的access_token,获取微信用户的信息类似的还有华为开放平台鉴权2.OAuth 2.0无论是微信公众号还是华为开发平台他们为了构造自己的生态运用自己庞大的用户基数去为第三方提供服务如果可以的话顺便收钱但是他们面临的问题不能直接把用户的信息直接暴露不然就是侵权行为更不可能把用户的用户名和密码直接暴露怎么办第三方应用程序需要知道当前操作的用户身份就需要身份验证这时OAuth协议应运而生OAuth2.0引入了一个授权层分离两种不同的角色客户端资源所有者用户只有用户同意以后服务器才能向客户端颁发令牌客户端通过令牌Token去请求数据从某种意义上说OAuth2.0是一种委托协议把原本可能需要用户名和密码才能拿到的数据通过授权Authorization产生的access-token并以此来进行相关访问。简单说系统用户允许某个应用代表他们访问用户自己能够控制的资源。OAuth 2.0包含如下主要内容2.1 授权方式实际上OAuth2.0有4种授权方式授权码-authorization-code隐藏式-implicit密码式-password客户端凭证-client credentials不管哪一种授权方式第三方应用申请令牌之前都需要像微信公众号开发那样必须先到系统备案说明自己的身份然后会拿到两个身份识别码客户端 IDclient ID和客户端密钥client secret。这是为了防止令牌被滥用没有备案过的第三方应用是不会也不可能拿到令牌的。2.2 端点Authorization Endpoint 授权端点Token Endpoint Token端点2.3 Scope代表资源所有者在被保护的资源那里的一些权限可以把被保护的资源分为不同的scope这个粒度由开发者自定义常见的有角色2.4 Access Token用来访问被保护资源的凭据代表了给客户端颁发的授权也就是委托给客户端的权限OAuth2.0没有对Token的格式和内容定义只有有一个要求Access-token要描述出资源所有者授予权限的范围也就是scope以及Access-token的有效期2.5 Refresh Token获取Access token的凭据由授权服务器颁发它是一个可选项具备让客户端应用逐渐降低访问权限的能力可以在Refresh Token请求重新获取Access Token时做一个设计根据实际需求给一个权限越来越低的token3.OpenId Connect 1.0上一节说过OAuth 2.0是一种授权机制是一种委托协议但是不是一个身份认证协议。OAuth2.0的Access Token不含有身份认证信息也不是为客户端准备的本身也不对客户端透明Access Token真正的受众是被保护的资源。“ 当然我们不排除一些简单的系统鉴权要求它只需限制对是否具有有效安全令牌的用户的访问并不需求身份认证。 OAuth2.0设计的Access Token不含有身份认证信息但是JWT具有自包含特点其实我们是可以把Access-Token设计为即具有身份信息又包含授权信息。在一些简单的单体应用中把身份认证和授权揉在一起根据Access_Token解析身份信息和然后再根据身份信息配合设计的权限规则db存储过滤请求的确可以这样做事实上有一些开源项目包括我自己都这样干过。 在一些实际场景下这种使用access-token作为身份认证的凭据是成立的因为token是经过身份认证后刚被创建的再加上后续验证与数据存储的交互可以确保无虞。 但是如果是在OAuth2.0中这并不是获取access-token的唯一方法。Refresh Token和assertions可以在用户不存在的情况下获取access token。而在某些情况下用户无需身份验证即可获得access token。另外用户不存在access-token通常还会存在很长时间。记住重要的一点OAuth是一个授权协议保护的是资源突出一个保护那么必须保证用户是存在的access-token受众是受保护的资源客户端是授权的提出者因此受保护的资源不能仅通过token的单独存在来判断用户是否存在因为 OAuth 协议的性质和设计在客户端和受保护资源之间的连接上用户是不可用的。”当应用程序需要知道当前用户的身份时就需要进行身份认证。通常这些应用程序代表该用户管理数据并需要确保该用户只能访问允许他访问的数据。目前最常见的身份验证协议是SAML2p、WS-Federation和OpenID Connect——SAML2p是最流行和部署最广泛的。OpenID Connect是三者中最新的一个但是却被认为是未来的发展方向因为它对现代应用程序具有最大的潜力。它从一开始就为移动应用场景而构建并被设计为对API友好。OpenID Connect是基于OAuth 2.0协议之上的简单身份层是在OAuth2.0之上做的一个扩展兼容OAuth2.0身份验证和API访问这两个基本的安全问题被组合成一个协议——通常只有一次到**安全令牌服务STS**的往返所以这里没有详细介绍OAuth2.0的授权流程的原因因为OpenId Connect几乎包含了整个OAuth2.0OAuth 2.0与OpenID Connect1.0 映射表OAuth2.0OpenID Connect 1.0资源所有者用户客户端依赖方授权服务器被保护资源身份提供商OpenId Connect 1.0包含如下主要内容3.1 ID Token包含了用户的认证信息3.2 UserInfo端点获取用户信息3.3 预设一组标识身份的scopes和claimsprofileemailaddressphone3.4 OpenID Connect 流程授权码流程-Authorization Code Flow隐式流程-Implicit Flow混合流程-Hybrid Flow4.OpenID Connect 与 OAuth 2.0下一篇我们将正式开始介绍对OpenID ConnectOAuth2.0这两种协议的实现中间件:IdentityServer4其经过高度优化可以解决当今移动、本机和web应用程序等典型的安全问题。在不同的文献对可能会同一角色使用不同的术语所以IdentityServer又可称为安全令牌服务(STS)、身份提供者(IDP)、授权服务器(AuthServer)、IP-STS等等。它的主要职责也就是OAuth2.0与OpenID Connect职责的综合也是IdentityServer4的职责保护资源使用本地用户存储或通过外部身份提供程序对用户进行身份认证提供session管理和单点登录管理和认证客户端向客户端颁发身份标识和访问令牌验证Token我们来回顾一下两个协议的要点也是IdentityServer4的要点必须先到系统备案授权端点获取Toekn端点获取用户信息端点刷新Token端点ID token不同的权限scope我们将在后续文章中一一对应职责与要点参考链接http://www.ruanyifeng.com/blog/2019/04/oauth_design.htmlhttp://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.htmlhttps://www.cnblogs.com/linianhui/p/authentication-based-on-oauth2.html#auto-id-3https://www.cnblogs.com/linianhui/p/oauth2-extensions-protocol-and-json-web-token.html#auto_id_2https://www.cnblogs.com/linianhui/p/oauth2-authorization.html#auto_id_17https://www.cnblogs.com/linianhui/p/oauth2-extensions-protocol-and-json-web-token.html#auto_id_2https://www.cnblogs.com/linianhui/p/oauth2-extensions-protocol-and-json-web-token.html#auto-id-2https://www.scottbrady91.com/OpenID-Connect/OpenID-Connect-Flowshttps://identityserver4.readthedocs.io/en/latest/intro/big_picture.html长按二维码关注点外卖先领券
