OAuth2的四种授权方式

OAuth2的作用

• 核心作用：颁发token，也就是令牌，token中一般包含用户信息和权限信息等
• 保护Web应用程序：OAuth2提供了一种安全的授权机制，使得第三方应用可以在用户授权的情况下访问其信息，从而保护用户的隐私和数据安全。
• 简化用户登录：通过OAuth2，用户可以在一次授权后，直接登录多个应用，无需在每个应用中重复输入用户名和密码，简化了用户的登录流程。
• 提供更灵活的权限管理：OAuth2允许用户对第三方应用进行细粒度的权限控制，只授予其所需的最小权限。这有助于防止潜在的安全风险，例如过多或不必要的数据泄露。
• 支持跨平台和跨设备访问：无论是Web应用、桌面应用还是移动应用，OAuth2都能提供统一的授权机制，使得用户的信息可以在不同的平台和设备之间无缝流转。
• 促进服务间的互操作性：OAuth2提供了一种标准化的授权流程，使得不同的服务和应用可以互相认证和授权，促进了服务间的互操作性和生态系统的健康发展。

OAuth2的四种授权方式

• 参考
• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

OAuth2相关名词

以QQ扫码登录为例子，我们都体验过在第三方应用上使用QQ扫码登录，比如CSDN，我们并没有在CSDN上直接注册账号，但是通过QQ扫码登录，授权之后，CSDN就会通过你的QQ信息在自己的网站上注册账号，就会对你的历史记录等进行保存。

• Third-party application：第三方应用程序，也叫客户端，在这里就是CSDN。
• HTTP service：HTTP服务提供商，这里的QQ。
• Resource Owner：资源所有者，就是用户。
• User Agent：用户代理，如Web浏览器、桌面应用程序或移动应用程序。
• Authorization server：认证服务器/授权服务器，即服务提供商专门用来处理认证的服务器，就是QQ中提供认证授权的服务器。
• Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器，就是QQ中保存资源的服务器。

授权码模式

• 授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
• 支持refresh token功能最完整、流程最严密的授权模式，通常使用在公网的开放平台中。适用于有自己的服务器的应用，它是一个一次性的临时凭证，用来换取access_token和refresh_token。一旦换取成功，code立即作废，不能再使用第二次。对安全性要求较高，web项目中一般使用授权码模式。
• 三方登录都是使用的这种方式保证安全

授权码模式的步骤

• 用户访问客户端，客户端将用户导向认证服务器。
• 选择是否给予客户端授权。
• 如果用户给予授权，认证服务器将用户导向客户端事先指定的重定向URI，同时附上一个授权码。
• 客户端收到授权码后，附上重定向URI，向认证服务器申请令牌。这一步是在客户端后台的服务器上完成的，对用户不可见。
• 认证服务器核对授权码和重定向的URI，确认无误后，向客户端发送访问令牌和更新令牌。
  

简化模式

• 不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
• 流程简单，适用于纯静态页面应用。该模式下，access_token容易泄露且不可刷新，不安全。

简化模式的步骤

• 用户访问客户端，客户端向用户显示授权页面，请求用户授权。
• 用户同意授权后，客户端将用户导向认证服务器。
• 认证服务器将用户导向客户端指定的重定向URI，并在URI中附加访问令牌和刷新令牌。
• 客户端收到重定向URI后，从URI中提取访问令牌和刷新令牌。
• 客户端使用访问令牌向资源服务器请求资源。
• 资源服务器验证访问令牌后，向客户端返回资源。
• 客户端定期使用刷新令牌向认证服务器请求新的访问令牌。
  

密码模式

• 用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。
• 在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
• 这种模式主要用来做遗留项目升级为oauth2的适配方案。如果客户端是自家的应用，也可以支持refresh token。一般在内部系统中使用，调用者是以用户为单位。用户向客户端提供自己的用户名和密码，向“服务商提供商”换取access_token。一旦换取成功，code立即作废，不能再使用第二次。这种模式极度不安全，需要高度信任第三方应用，只适用于其他授权模式都无法采用的情况，原生APP可以使用，web不建议使用。

密码模式的步骤

• 用户向客户端提供用户名和密码。
• 客户端通过用户名和密码向认证服务器请求令牌。
• 认证服务器验证用户名和密码是否匹配，如果匹配，则向客户端返回访问令牌。
• 客户端使用访问令牌向资源服务器请求资源。
• 资源服务器验证访问令牌是否有效，如果有效，则向客户端返回资源。
  

客户端模式

• 客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
• 我们的应用要使用微信登录等第三方登录，我们的应用就要申请成为微信或者其他支持三方登录平台的客户端。

客户端模式的步骤

• 客户端向认证服务器进行身份认证，并要求一个访问令牌。
• 认证服务器确认无误后，向客户端提供访问令牌。
• 客户端使用访问令牌向资源服务器请求资源。
• 资源服务器验证访问令牌是否有效，如果有效，则向客户端返回资源。