OAuth 2.0中authorization code（授权码）的功能及往返流程作用

这个往返设计是OAuth 2.0授权码模式的核心安全机制，本质是为了在不可信的前端公网传输环境下，从架构层面避免Access Token泄露，核心作用可以归纳为三点：

• 彻底隔离敏感令牌与不可信前端通道
  授权码是通过浏览器重定向的方式传回客户端的，整个传输路径经过用户端浏览器，属于完全不可信的公网链路：浏览器地址栏、访问历史、请求Referer头、页面注入的第三方脚本都有可能窃取链路中传输的内容。如果直接在这一步返回具备资源访问权限的Access Token，令牌一旦被窃，攻击者就能直接操作用户的受保护资源。
  而授权码本身是*一次性、超短有效期（通常10秒到1分钟）*的临时凭证，单独拿到授权码没有任何使用价值——后续兑换令牌必须搭配只有客户端后端安全存储的Client Secret才能完成，就算授权码在前端链路被截获，攻击者拿不到后端密钥，根本换不到有效Access Token。
• 实现客户端身份的强校验
  授权服务器返回授权码的环节，只完成了用户身份核验、用户授权意愿确认，没法确认接收授权码的请求是不是真的来自提前备案的合法客户端——前端重定向链路是可以被篡改、伪造的。
  等到第6步客户端从自身后端发起令牌兑换请求时，走的是服务端到服务端的私密可信通道，授权服务器可以同时校验两个核心信息：一是当前授权码是否合法、是否归属该客户端，二是请求携带的Client Secret是否和客户端备案信息匹配，直接拦住伪造客户端的欺诈请求。
• 把凭证泄露的风险压到最低
  就算出现极端情况授权码被第三方截获，它本身就和发起授权时的客户端ID、回调地址做了绑定，而且仅能使用一次、有效期极短，攻击者几乎没有可利用的时间和操作空间，风险和直接在前端通道传输可直接使用的Access Token完全不在一个量级。

说白了这个设计就是做了通道拆分：不可信的前端公网通道只传用完就作废的临时凭证，真正能访问用户资源的Access Token只在服务端之间的私密通道传输，从根源上堵死了前端链路泄露令牌的可能。

内容的提问来源于stack exchange，提问作者TMOTTM