点击下方“IT牧场”，选择“设为星标”
当企业应用系统逐渐增多后，每个系统单独管理各自的用户数据容易形成信息孤岛，分散的用户管理模式阻碍了企业应用向平台化演进。当企业的互联网业务发展到一定规模，构建统一的标准化账户管理体系将是必不可少的，因为它是企业互联网云平台的重要基础设施，能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力，为企业带来诸如跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供了必要条件。
-
服务端无状态：Token 机制在服务端不需要存储 session 信息，因为 Token 自身包含了所有用户的相关信息。
-
性能较好，因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。
-
支持移动设备，支持跨程序调用，Cookie 是不允许垮域访问的，而 Token 则不存在这个问题。
-
用户输入登录信息（或者调用 Token 接口，传入用户信息），发送到身份认证服务进行认证（身份认证服务可以和服务端在一起，也可以分离，看微服务拆分情况了）。
-
身份验证服务验证登录信息是否正确，返回接口（一般接口中会包含用户基础信息、权限范围、有效时间等信息），客户端存储接口，可以存储在 Session 或者数据库中。
-
客户端将 Token 放在 HTTP 请求头中，发起相关 API 调用。
-
被调用的微服务，验证 Token 权限。
-
服务端返回相关资源和数据。
-
获取凭证，第三方应用客户端使用客户端编码/安全码、资源所有者用户名/密码等证件信息从授权服务器上获取 Access Token 资源访问凭证。
-
登录授权，客户端携带 Access Token 凭证访问服务器资源，资源服务器验证 Token、第三方应用凭证信息、资源所有者 User 合法性，通过 Token 读取资源所有者身份信息（user）加载资源所有者的权限项执行登录。
-
访问鉴权，第三方应用客户端访问服务端资源，系统验证访问者 Access Token 合法性、权限信息，验证凭证（Access Token）正确，此时资源服务器就会返回资源信息。
-
凭证续约，Access token 访问凭证过期需要进行凭证续约，刷新 Token 凭证有效期。
-
系统授权采用 OAuth2 开放式授权标准密码模式。
-
Token 采用 JWT 标准。
-
授权码模式（authorization code）用在客户端与服务端应用之间授权码。
-
简化模式（implicit）用在移动 app 或者 web app（这些 app 是在用户的设备上的，如在手机上调起微信来进行认证授权）。不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了“授权码”这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
-
密码模式（resource owner password credentials）应用直接都是受信任的（都是由一家公司开发的）密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向“服务商提供商”索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。
-
客户端模式（client credentials）用在应用 API 访问客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向“服务提供商”进行认证。严格地说，客户端模式并不属于 OAuth 框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求“服务提供商”提供服务，其实不存在授权问题。
作者：mars
来源：https://juejin.cn/post/6906149001520037902
干货分享
最近将个人学习笔记整理成册，使用PDF分享。关注我，回复如下代码，即可获得百度盘地址，无套路领取！
•001：《Java并发与高并发解决方案》学习笔记；•002：《深入JVM内核——原理、诊断与优化》学习笔记；•003：《Java面试宝典》•004：《Docker开源书》•005：《Kubernetes开源书》•006：《DDD速成（领域驱动设计速成）》•007：全部•008：加技术群讨论
加个关注不迷路
喜欢就点个"在看"呗^_^
原文始发于微信公众号（IT牧场）：微服务架构统一安全认证设计与实践
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论