微服务架构下的鉴权，怎么做更优雅？( 四 ) _微服务

2. 简化模式（implicit）简化模式（Implicit Grant Type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了 "授权码" 这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。流程如下：

客户端将用户导向认证服务器。
用户决定是否给于客户端授权。
假设用户给予授权，认证服务器将用户导向客户端指定的 "重定向 URI"，并在 URI 的 Hash 部分包含了访问令牌。
浏览器向资源服务器发出请求，其中不包括上一步收到的 Hash 值。
资源服务器返回一个网页，其中包含的代码可以获取 Hash 值中的令牌。
浏览器执行上一步获得的脚本，提取出令牌。
浏览器将令牌发给客户端。

3. 密码模式（Resource Owner Password Credentials）密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向 "服务商提供商" 索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。流程如下：

用户向客户端提供用户名和密码。
客户端将用户名和密码发给认证服务器，向后者请求令牌。
认证服务器确认无误后，向客户端提供访问令牌。

4. 客户端模式（Client Credentials）

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向 "服务提供商" 进行认证。严格地说，客户端模式并不属于 OAuth 框架所要解决的问题。
在这种模式中，用户直接向客户端注册，客户端以自己的名义要求 "服务提供商" 提供服务，其实不存在授权问题。流程如下：客户端向认证服务器进行身份认证，并要求一个访问令牌。认证服务器确认无误后，向客户端提供访问令牌。

五、思考总结

正如 David Borsos 所建议的一种方案，在微服务架构下，我们更倾向于将 Oauth 和 JWT 结合使用，Oauth 一般用于第三方接入的场景，管理对外的权限，所以比较适合和 API 网关结合，针对于外部的访问进行鉴权（当然，底层 Token 标准采用 JWT 也是可以的）。
JWT 更加轻巧，在微服务之间进行访问鉴权已然足够，并且可以避免在流转过程中和身份认证服务打交道。当然，从能力实现角度来说，类似于分布式 Session 在很多场景下也是完全能满足需求，具体怎么去选择鉴权方案，还是要结合实际的需求来。