admin管理员组文章数量:1568355
概述
OAuth2 实质是为第三方应用颁发一个具有时效性的Token令牌,使其他服务或第三方应用能够通过令牌获取相关 资源。 常见的场景: 比如进入某个网站没有账号信息, 但可以通过QQ、微信、支付宝等账号进行登陆, 在这个 登陆过程中采用的就是Oauth2协议; OAUTH2不仅支持认证,还具备授权功能, 比如通过QQ登录获取用户头 像,基本资料等。
OAuth2角色
- resource owner : 资源所有者,具备访问该资源的实体, 如果是某个人, 被称为end-user。
- resources server: 资源服务器,受保护的资源服务器, 具备提供资源能力, 如订单服务, 商品服务等。
- client: 客户端,这并不是指用户,而是对资源服务器发起请求的应用程序,比如前后分离项目, 前端服务访问管理接口, 访问后台业务功能接口。
- authorization server: 授权服务器, 能够给客户端颁发令牌, 这个就是我们上面所讲的统一认证授权服务器。
- user-agent: 用户代理,作为资源所有者与客户端沟通的工具, 比如APP, 浏览器等。
OAuth2 协议流程
OAuth2包含四种授权模式:
-
授权码模式;
-
隐式/简化授权模式;
-
密码模式;
-
客户端模式。
-
Resource Owner 与 Client 之间 , 资源所有者向Client发起认证请求, Client再返回认证授权信息。
-
Client 收到 Resource Owner 的认证请求后, 会去Authorization Server 申请访问令牌, Authorization Server会让Client 进行认证, 通过之后会返回Access Token。
-
Client 拿到 Authorization Server 的 Acceess Token , 访问Resource Server,Resource Server 验证之后, 返回被保护的资源信息。
-
Resource Server 可以通过JWT在本地进行验证, 也可以访问 Authorization Server, 对Client 的请求的合法性进行验证。
OAuth2 授权码模式
- 客户端携带 client_id, scope, redirect_uri, state 等信息引导用户请求授权服务器的授权端点下发 code。
- 授权服务器验证客户端身份,验证通过则询问用户是否同意授权(此时会跳转到用户能够直观看到的授权页面,等待用户点击确认授权)。
- 假设用户同意授权,此时授权服务器会将 code 和 state(如果客户端传递了该参数)拼接在 redirect_uri 后 面,以302(重定向)形式下发 code。
- 客户端携带 code, redirect_uri, 以及 client_secret 请求授权服务器的令牌端点下发 access_token。
- 授权服务器验证客户端身份,同时验证 code,以及 redirect_uri 是否与请求 code 时相同,验证通过后下发 access_token,并选择性下发 refresh_token,支持令牌的刷新。
示例:
1、授权请求:
response_type=code // 必选项
&client_id={客户端的ID} // 必选项
&redirect_uri={重定向URI} // 可选项
&scope={申请的权限范围} // 可选项
&state={任意值} // 可选项
2、授权响应参数:
code={授权码} // 必填
&state={任意文字} // 如果授权请求中包含 state的话那就是必填
3、令牌请求:
grant_type=authorization_code // 必填
&code={授权码} // 必填 必须是认证服务器响应给的授权码
&redirect_uri={重定向URI} // 如果授权请求中包含 redirect_uri 那就是必填
&code_verifier={验证码} // 如果授权请求中包含 code_challenge 那就是必填
4、令牌响应:
"access_token":"{访问令牌}", // 必填
"token_type":"{令牌类型}", // 必填
"expires_in":{过期时间}, // 任意
"refresh_token":"{刷新令牌}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填
OAuth2 隐式/简化模式
- 资源拥有者(用户)通过代理(WEB浏览器)访问客户端程序,发起简化模式认证。
- 客户端(Client)向认证服务器(Auth Server)发起请求, 此时客户端携带了客户端标识(client_id)和重定向地址(redirect_uri)。
- 客户端(Client)拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
示例:
1、授权请求:
response_type=token // 必选项
&client_id={客户端的ID} // 必选项
&redirect_uri={重定向URI} // 可选项
&scope={申请的权限范围} // 可选项
&state={任意值} // 可选项
2、授权响应参数:
&access_token={令牌信息} // 必填
&expires_in={过期时间} // 任意
&state={任意文字} // 如果授权请求中包含 state 那就是必填
&scope={授权范围} // 如果请求和响应的授权范围不一致就必填
思考:为什么要有授权码和简化模式?看完这两种模式, 可能会有些疑问, 为什么要这么麻烦, 直接一次请求 返回TOKEN不就可以吗?
我们可以看出, 两者主要差别, 是少了code验证环节, 直接返回token了, code验证是客户端与认证服务器在后台进行请求获取, 代理是获取不到TOKEN的, 如果缺少这个环节, 直接返回TOKEN, 相当于直接暴露给所有参 与者, 存在安全隐患, 所以简化模式,一般用于信赖度较高的环境中使用。
OAuth2 密码模式
- 资源拥有者直接通过客户端发起认证请求。
- 客户端提供用户名和密码, 向认证服务器发起请求认证。
- 认证服务器通过之后, 客户端(Client)拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
示例:
1、令牌请求:
grant_type=password // 必填
&username={用户ID} // 必填
&password={密码} // 必填
&scope={授权范围} // 任意
2、令牌响应:
"access_token":"{访问令牌}", // 必填
"token_type":"{令牌类型}", // 必填
"expires_in":"{过期时间}", // 任意
"refresh_token":"{刷新令牌}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填
此模式简化相关步骤, 直接通过用户和密码等隐私信息进行请求认证, 认证服务器直接返回token, 这需要整个 环境具有较高的安全性。
OAuth2 客户端模式
- 此模式最为简单直接, 由客户端直接发起请求。
- 客户端与服务器信赖度较高, 服务端根据请求直接认证返回token信息。
- 客户端(Client)拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
这种模式一般在内部服务之间应用, 授权一次, 长期可用, 不用刷新token。
示例:
1、令牌请求:
grant_type=client_credentials // 必填
client_id={客户端的ID} // 必填
client_secret={客户端的密钥} // 必填
&scope={授权范围} // 任意
2、令牌响应:
"access_token":"{访问令牌}", // 必填
"token_type":"{令牌类型}", // 必填
"expires_in":"{过期时间}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填
增强Token技术解决方案
优势与应用场景
基于Token的鉴权方案,实现方式有多种,增强Token属于其中一种,为什么要采用增强Token方式,它能够解决怎样的问题?
普通Token认证方式,没有附带必要的用户信息,如果要查询,需要再次调用OAuth2的用户资料认证接口,会增加传输开销;JWT虽然能够附带一定用户信息,但受限于长度,存储空间有限; 如果既要保障性能, 又要求能够存储一定的信息,就可以采用增强Token方案,它是将信息存储至Redis缓存中,作为资源服务,接收到Token之后, 可以直接从Redis中获取信息。 它可以适用于微服务架构下,有一定用户信息要求的场景,比如订单服务、资金服务需要获取用户的基本资料,但如果是跨IDC,跨区域,需要暴露外网的情况下,不推荐采用此方案,因为需要保障数据的安全性。
版权声明:本文标题:深入浅出单点登录---4、基于OAuth实现的统一认证 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://www.elefans.com/dongtai/1726253394a1062697.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论