我是靠谱客的博主 独特宝贝,这篇文章主要介绍微服务安全架构-OAuth2.0微服务安全架构-OAuth2.0,现在分享给大家,希望可以做个参考。

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

微服务安全架构-OAuth2.0

OAuth2.0 主要解决开放系统间资源授权的问题, 基于令牌(Token)的方式进行资源授权,在无需暴露用户密码的情况下,使应用能够获取用户对数据的有限访问权限,支持WebApp、浏览器、原生APP、服务器之间的授权。最常见的场景就是微信、微博等第三方联合登录。

OAuth2.0协议是解决资源授权问题,不解决身份认证问题,所以要结合身份认证服务进行应用。

<!--more -->

OAuth2.0 主要有4种角色:资源拥有者,资源服务器,授权服务器,客户端应用,角色之间的关系如下图

OAuth2.0 有4种模式,授权码模式、简单模式、用户密码模式、客户端模式,分别在不同的场景下使用。

如果访问令牌的拥有人是机器,采用客户端模式。适用于服务器间通信,客户凭证(令牌)可以使用对称加密或非对称加密,支持共享密码或证书的方式进行。 如果访问令牌的拥有人是用户,并且是Web服务端请求,适合授权码模式。微信、微博等第三方联合登录就采用此方式 如果访问令牌的拥有人是用户,原生APP的方式,如果APP与授权服务器不是信任的(APP是第三方)适合授权码模式,如果都是一个公司的可以采用用户名密码的方式。 如果访问令牌的拥有人是用户,Web浏览器的工,如果Web网页与授权服务器不是信任的(Web网页是第三方)适合简单模式,如果都是一个公司的可以采用用户名密码的方式。

下面分别介绍4种模式:

1、授权码模式(Authorization Code)

流程图:

A 用户通过前端渠道向认证服务器获取授权码,并指定"重定向URI"参数,做为用户同意后接收授权码的入口;

B 认证服务器询问用户是否同意授权;

C 用户同意后,授权服务器会重定向到用户A步骤指定的“重定向URI”参数,并携带授权码;

D 在服务端收到授权码后,再次向授权服务器申请令牌(把C步骤收到的授权码做为参数换取令牌),一般授权码只能使用一次,保证安全。

E 授权服务器在核对授权码正确后,再重定向到“重定向URI”,发放令牌,一般是access token 和 refresh token

F 用户在access token 有效期内访问资源服务器时,资源服务器向授权服务器校验access Token 是否有效,来确定是否给用户相应的资源。如果access token 无效时,重复获取授权码或使用refresh token换取access token.

授权码模式是最安全的流程,令牌的传递不经过user-agent,由资源服务与授权服务之间通讯校验授权是否正确。现在多数情况是使用Redis缓存授权码。

2、简单化模式(Implicit)

流程图:

A 用户通过前端渠道向认证服务器获取授权码,并指定"重定向URI"参数,做为用户同意后接收授权码的入口;

B 用户提供认证信息;

C 授权服务器会重定向到用户A步骤指定的“重定向URI”参数,通过Fragment返回Access Token;

D 向后台请求解析Aceess Token 脚本;

E 通过后台返回的script解析出access token 访问资源。

简化模式比较简单,适用于无后台的单页Web应用。

3、密码模式

流程图:

A 资源拥有者通过客户端访问资源时,直接将用户名和密码传递给用客户端。

B 客户端将资源拥有者的用户名和密码传递给授权服务器。

C 正确校验后,授权服务器返回Access Token.

密码模式适合于App或Web应用和授权服务同是一个厂家,都是可信任的场景。

4、客户端模式

流程图

A 直接由客户端将用户认证信息发送到授权服务器进行认证;

B 正确校验后,授权服务器返回 access Token,客户端使用access token 就可以访问资源。

客户端模式适用于没有用户参与,直接是机器对机器的模式。

5、刷新令牌机制

流程图:

A 客户端认证后向授权服务器申请access Token;

B 正确校验后,授权服务器返回 access Token 和 Refresh Token;

CD 客户端使用Access Token 访问资源,资源服务器校验Token正确后,正常响应请求;

EF 过一段时间后客户端使用Access Token 再次访问资源,资源服务器校验Token失效,不能正常响应请求的资源;

G 客户端用Refresh Token 向授权服务器换取新的Acces Token;

F 授权服务校验Refresh Token 正确后向客户端发放新的Access Token和新的Refresh Token;

刷新Token可以简化认证模式。

在互联网应用模式下大多数使用授权码模式进行资源授权或联合登录。如果是企业内部的应用多数使用用户密码的模式进行授权,并且有OSS单点登录服务器进行用户身份认证。

转载于:https://my.oschina.net/thinker4self/blog/3017860

最后

以上就是独特宝贝最近收集整理的关于微服务安全架构-OAuth2.0微服务安全架构-OAuth2.0的全部内容,更多相关微服务安全架构-OAuth2内容请搜索靠谱客的其他文章。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(109)

评论列表共有 0 条评论

立即
投稿
返回
顶部