最详细的一篇关于Oauth2.0认证模式

OAuth（开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不 需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。OAuth2.0是OAuth协议的延续版本，但不向 后兼容OAuth 1.0即完全废止了OAuth1.0。很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服 务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准

Oauth协议目前发展到2.0版本，1.0版本过于复杂，2.0版本已得到广泛应用。

参考：https://baike.baidu.com/item/oAuth/7153134?fr=aladdin

Oauth协议：https://tools.ietf.org/html/rfc6749

Oauth2的认证流程

• 流程图
  

引自OAauth2.0协议rfc6749 https://tools.ietf.org/html/rfc6749

• 概念：

  • 客户端

    本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏 览器端）、微信客户端等。

  • 资源拥有者

    通常为用户，也可以是应用程序，即该资源的拥有者。

  • 授权服务器（也称认证服务器）

    用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌 （access_token），作为客户端访问资源服务器的凭据。l例如：微信的认证服务器、支付宝的认证服务器

  • 资源服务器

    存储资源的服务器，例如：微信、支付宝等包含用户信息服务器，可以通过认证服务器认证之后，通过access_token获取微信、支付宝保存的用户信息

Oauth2的四种模式

授权码模式

简单来讲就是经过用户授权之后获取code，然后通过code到认证服务器获取access_otken

• 认证流程

  

• 流程说明

  • 资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会附加客户端的身份信息。如：

    /server/oauth2/authorize? client_id=test&response_type=code&scope=app&redirect_uri=http://xx.xx/notify
    

    client_id：客户端接入标识。

    response_type：授权码模式固定为code。

    scope：客户端权限。

    redirect_uri：跳转uri，当授权码申请成功后会跳转到此地址，并在后边带上code参数（授权码）。例如：http://xx.xx/notify?code=qwe12

  • 浏览器出现向授权服务器授权页面，之后将用户同意授权。

  • 授权服务器将授权码（AuthorizationCode）转经浏览器发送给client(通过redirect_uri传递，url后面拼接参数)。

  • 客户端拿着授权码向授权服务器索要访问access_token，请求如下：

    /server/oauth2/token? client_id=test&client_secret=gdjbcd&grant_type=authorization_code&code=qwe12&redirect_uri=http://xx.xx/notify
    

    client_id：客户端准入标识。

    client_secret：客户端秘钥。

    grant_type：授权类型，填写authorization_code，表示授权码模式 code：授权码，就是刚刚获取的授权码，注意：授权码只使用一次就无效了，需要重新申请。

    redirect_uri：申请授权码时的跳转url，一定和申请授权码时用的redirect_uri一致

  • 授权服务器返回令牌(access_token)

这种模式是四种模式中最安全的一种模式。一般用于Web服务器端应用或第三方的原生App调用资源服务的时候。 因为在这种模式中access_token不会经过浏览器或移动端的App，而是直接从服务端去交换，这样就最大限度的减 小了令牌泄漏的风险

密码模式

密码模式使用较多，适应于第一方的单页面应用以及第一方的原生App

• 认证流程

  

• 流程说明：

  • 资源拥有者将用户名、密码发送给客户端（需提前配置好，发送给客户端或者第三方系统）

  • 客户端拿着资源拥有者的用户名、密码向授权服务器请求令牌（access_token），请求如下：

    /server/oauth2/access_token? client_id=web&client_secret=123321&grant_type=password&username=shanghai&password=123456
    

    client_id：客户端准入标识。

    client_secret：客户端秘钥。

    grant_type：授权类型，password表示密码模式

    username：资源拥有者用户名。

    password：资源拥有者密码

  • 授权服务器将令牌（access_token）发送给client

这种模式十分简单，但是却意味着直接将用户敏感信息泄漏给了client，因此这就说明这种模式只能用于client是 我们自己开发的情况下。因此密码模式一般用于我们自己开发的，第一方原生App或第一方单页面应用 或者是可信任的第三方系统。

客户端模式

• 认证流程

  

• 流程说明

  • 客户端向授权服务器发送自己的身份信息，并请求令牌（access_token）

  • 确认客户端身份无误后，将令牌（access_token）发送给client，请求如下：

    /server/oauth2/access_token?client_id=test&client_secret=123321&grant_type=client_credentials
    

    client_id：客户端准入标识。

    client_secret：客户端秘钥。

    grant_type：授权类型，填写client_credentials表示客户端模式 这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。因 此这种模式一般用来提供给我们完全信任的服务器端服务。比如，合作方系统对接，拉取一组用户信息

客户端模式适应于没有用户参与的，完全信任的一方或合作方服务器端程序接入。

客户端模式和密码模式比较类似，通过一个流程就可以获取到access_token，相对简单的两种认证方式，一般可以直接应用于客户端或者第三方系统

简化模式

• 认证流程

  

• 流程说明

  • 资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会 附加客户端的身份信息。如：

    /server/oauth2/authorize? client_id=test&response_type=token&scope=app&redirect_uri=http://xx.xx/notify
    

    参数描述同授权码模式 ，注意response_type=token，说明是简化模式。 表明直接需要access_token

  • 浏览器出现向授权服务器授权页面，之后将用户同意授权

  • 授权服务器将授权码将令牌（access_token）以Hash的形式存放在重定向uri的fargment中发送给浏览 器。

    注：fragment 主要是用来标识 URI 所标识资源里的某个资源，在 URI 的末尾通过 （#）作为 fragment 的开头， 其中 # 不属于 fragment 的值。如https://domain/index#L18这个 URI 中 L18 就是 fragment 的值。大家只需要 知道js通过响应浏览器地址栏变化的方式能获取到fragment 就行了

一般来说，简化模式用于第三方单页面应用，这种模式只需要前端就可以完成认证流程，无需和后端的交互，所以一般应用于vue、react等前后端分离的单页面前端应用，可以直接获取到access_token。

认证中心

在微服务中，如果需要进行认证，那么一定是会有统一的认证中心，下面是微服务和认证中心的流程

• 认证流程

  

• 流程描述

  （1）接入方（需要使用平台资源的统称为接入方）采取OAuth2.0方式请求统一认证服务(UAA)进行认证。
  （2）认证服务(UAA)调用统一账号服务去查询该用户信息及其权限信息。（第三方应用接入不需要该步骤）

  （3）认证服务(UAA)验证登录用户及第三方应用合法性。

  （4）若接入方身份合法，认证服务生成jwt令牌返回给接入方，其中jwt中包含了权限信息。
  （5）接入方携带jwt令牌对API网关内的微服务资源进行访问。

  （6）API网关对令牌解析、并验证接入方的权限是否能够访问本次请求的微服务。
  （7）如果接入方的权限没问题，API网关将Token转发至微服务。

  （8）微服务收到请求，明文token中包含登录用户的身份和权限信息，后续微服务使用用户身份及权限信息。

• 服务职责

  • 统一账号服务

    提供商户和平台运营人员的登录账号、密码、角色、权限、资源等系统级信息的管理，不包含用户业务信息。

  • 统一认证服务(UAA)

    它承载了OAuth2.0接入方认证、登入用户的认证、授权以及生成令牌的职责，完成实际的用户认证、授权功能。

  • API网关

    作为系统的唯一入口，API网关为接入方提供定制的API集合，它可能还具有其它职责，如身份验证、监控、负载 均衡、缓存等。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理 所有的非业务功能。

微信公众号「指尖上的代码」，欢迎关注～

原创不易, 点个赞再走呗~ 欢迎关注，给你带来更精彩的文章！

你的点赞和关注是写文章最大的动力～