为获取 Access Token 访问令牌，客户端必须完成用户授权流程。OAuth 2.0 协议统一规范了四种标准授权方式：
隐式授权模式（Implicit）：协议保留该模式，生产环境不推荐使用
授权码授权模式（Authorization Code）：官方推荐、安全性最高的主流授权方案
资源所有者密码凭据授权模式（Resource Owner Password Credentials）：简称密码模式
客户端凭据授权模式（Client Credentials）：纯客户端身份认证的授权模式
隐式模式又称简单模式，是早期轻量化的 OAuth 交互方案，最初为无独立服务端的纯前端、JavaScript 应用设计。该模式流程精简，省略授权码中转环节，认证服务器会直接在重定向链接中返回访问令牌。由于令牌直接暴露在浏览器 URL 地址栏中，极易遭到网络拦截、日志抓取与恶意窃取，存在严重安全漏洞，因此目前已逐步淘汰，不建议任何业务场景使用。隐式模式整体逻辑与授权码模式相近，核心差异为：认证服务器直接返回令牌，而非临时授权码。核心流程如下：
客户端向 OAuth 认证服务器发起授权请求
用户查看授权提示并确认批准授权申请
认证服务器重定向至预设 redirect_uri，在 URL 中直接拼接 Access Token 完成返回
授权码模式适用于拥有独立业务服务端的应用，也是 OAuth 2.0 标准主推的安全授权方案。授权码 Code 属于一次性临时凭证，核心作用是安全换取 Access Token 与 Refresh Token。认证服务器提供专属的令牌兑换接口：
https://域名/exchange?code=&client_id=&client_secret=接口请求需要传入 code、client_id 以及 client_secret 完成校验，验证通过后，服务端返回合法的 Access Token 和 Refresh Token。
同时授权码具备一次性失效机制，兑换令牌后立即作废，无法二次复用。
引入授权码中转机制，核心目的是大幅提升令牌的传输安全性：
隐式模式会将令牌直接暴露在前端链接中，极易被抓包、窃听与劫持
即便攻击者非法截取到授权码，若无业务服务端加密保管的 client_secret，也无法兑换有效令牌
授权码换取令牌的过程为服务端到服务端的内网加密交互，且强制依赖 HTTPS 加密传输，数据包无法被解析破解
借助授权码的隔离设计，彻底规避令牌前端暴露的风险，因此 OAuth 2.0 体系优先推荐采用授权码模式完成授权交互。
在密码模式中，用户需要主动向客户端提供账号与密码，由客户端携带用户凭据向服务提供商发起授权申请。该模式的前提是用户对当前应用具备高度信任，且客户端严禁持久化存储用户账号密码。常见适用场景为系统内置程序、企业内部专属产品等封闭可信环境。
典型业务场景：
同一企业旗下多条产品线，统一接入企业自研 OAuth 2.0 认证体系。内部产品可自定义授权页面，无需展示第三方权限申请提示，仅做纯身份核验；产品自研页面收集用户账号密码后，直接转发至认证服务器完成鉴权授权，简化内部使用流程。
使用密码模式有核心约束：流程中认证服务器必须严格校验客户端身份，通过 client_id 识别接入方，仅放行受信任的内部客户端，避免用户账号凭据泄露。
当合作双方具备强信任关系，或是调用方为无交互界面的纯后端服务、定时任务、中间件模块时，可采用客户端凭据模式。该模式脱离用户主体，无需用户参与授权确认，认证服务器仅校验客户端自身身份信息，核验 client_id 与密钥合法后，直接下发 Access Token，满足服务与服务之间的接口调用需求。
