xx软件最终是通过会见令牌请求到我的民众号里的文章。会见令牌是通过授权码换来的。你有想过为何要用授权码换令牌，而不直接发表会见令牌呢？OAuth 2.0 的角色资源拥有者、客户端(即第三方软件)、授权服务和受掩护资源。

资源拥有者=> 我客户端 => xx软件授权服务 -> 民众号开放平台的授权服务受掩护资源 -> 我的民众号里的文章一定要授权码吗?第 4 步授权服务生成授权码，倘若我们不要授权码，这步直接返回会见令牌access_token。那就不能重定向，因为这样会把宁静保密性要求极高的会见令牌袒露在浏览器，增加会见令牌失窃风险。这显然不行的呀！即若无授权码，就只能把会见令牌发给第三方软件的后端服务： 看着似乎没问题？我会见xx软件，xx软件说要排版文章我得给它授权，否则vx民众号不干，然后xx软件就引导我跳转到了民众号的授权服务。到授权服务之后，开放平台验证xx的正当性及我的登录状态后，生成授权页面。

我赶快扫码同意授权，于是开放平台知道可以把我的文章数据给xx软件。于是，开放平台生成会见令牌 access_token，而且通事后端服务方式返回给xx软件。xx就能正常事情。

可是当我被浏览器重定向到授权服务，我和xx间的毗连就断了，相当于此时我和授权服务建设毗连后，将一直“停留在授权服务页面”。我再也没有重连到xx。但这时xx已拿到我授权后的会见令牌，也使用会见令牌获取了我的号里的文章数据。

这时，思量我的感受。xx应该要通知到我，可是如何做呢？现在毗连可是断了的呀！ 为了让xx通知到我，我必须跟xx重建 “毗连”。即第二次重定向，我授权后，又重新重定向回到xx的地址，这样我就跟xx有了新毗连。

为重建毗连，又不能袒露会见令牌，就有这样的暂时、间接凭证：授权码。因为xx最终要拿到高宁静要求的会见令牌，并非授权码，授权码可以袒露在浏览器。

有了授权码，会见令牌可以在后端服务间传输，同时还可重建我&xx间的毗连。所以，通过授权码，既思量了我的用户体验，又思量了通信宁静。执行授权码流程时，授权码和会见令牌在xx和授权服务间到底怎么流转的？授权码许可类型的通信历程间接通信间接通信就是指获取授权码的交互。我：“xx，我要会见你了。

” xx：“我把你引到授权服务，我需要授权服务给我一个授权码。” 授权服务：“xx，我把授权码发给浏览器了。” 小兔软件：“ 那我从浏览器拿到了授权码。

”xx和授权服务间，并无直接通信，而是通过中间人(浏览器).直接通信授权码换取会见令牌的交互，是“直接”的。三方软件xx获取到授权码后，向授权服务提倡获取会见令牌 access_token 的请求。三方软件要代表资源拥有者去会见受掩护资源 授权服务卖力发表会见令牌，受掩护资源卖力吸收并验证会见令牌。开发微信小法式场景好比获取用户登录态信息的历程：通过 wx.login(Object object) 获取登录凭证 code，该步是在小法式内部通过挪用微信提供的 SDK 实现的再通过该 code 换取用户的 session_key 等信息，即官方文档的 auth.code2Session 方法，同时该方法也是被强烈建议通过开发者的后端服务来挪用参考https://leokongwq.github.io/2017/02/28/why-oauth2-use-authorization-code.htmlhttps://developers.weixin.qq.com/miniprogram/dev/api-backend/open-api/login/auth.code2Session.htmlhttps://segmentfault.com/q/1010000014642301https://tools.ietf.org/html/rfc6749。

本文来源：澳门人威尼斯官方-www.xiamenkp.com