不解微信 access_token 的作用

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐关注

› Meteor

› JSLint - a JavaScript code quality tool

› jsFiddle

› D3.js

› WebStorm

推荐书目

› JavaScript 权威指南第 5 版

› Closure: The Definitive Guide

这是一个创建于 3420 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近准备试试看微信的 JSSDK

可是有一个地方不是让我很理解... 微信是需要使用 access_token 来访问的. 而 access_token 是使用 appsecret 生成的. 需要服务器保存. 2小时内有效.

我不解的是这样的好处是什么? 保证 appsecret 的安全么? 可是这个 access_token 还是明文的啊. 在 js 端可以看到的啊. 如果别人需要用你的 access_token 只要定时趴一下你的页面不就行了? 这个和直接一个key有什么区别

微信

APPSECRET

不解

15 条回复 • 2015-07-13 16:01:43 +08:00

defia

2015-07-12 20:36:13 +08:00

这是你后端保存与微信服务器交互用的啊。

agate

2015-07-12 20:40:37 +08:00

@defia 不是很理解, 可以具体介绍一下么? 我不理解的是 access_token 一样是明文的. 而且有 2小时有效期. 这样不是等于一个"密码"么.

tini26

2015-07-12 20:45:41 +08:00

只有你的设备能看得见的明文，对别人来说看不到，就是密文

crabRunning

2015-07-12 20:46:38 +08:00 via Android

客户端只看到自己的而已

qiayue

2015-07-12 20:46:42 +08:00

access_token 不能暴露在网页里啊，网页里（其实是js里）需要的是已经计算好的签名 signature
而签名是根据当前网页 URL 来计算的，所以别人获取到了也没意义

wy315700

2015-07-12 20:47:54 +08:00

access_token是你的服务器和微信通讯用的，不是在客户端和微信通讯用的

你不会直接在网页里用JS和微信服务器通讯吧

agate

2015-07-12 20:55:23 +08:00

@qiayue 哦~~~ 我理解错了. 原来 signature 是根据 url 计算的哦. 明白了. 谢谢你的解释

@defia @crabRunning @tini26 @wy315700 谢谢大家

djyde

2015-07-12 20:55:48 +08:00

是明文，但是除非别人已经拿到了你的手机设备，否则别人不太可能远程获取到。

agate

2015-07-12 21:10:07 +08:00

@djyde 是我不好... 误解了 signature 和 access_token 的区别. 明文的应该是 signature. 而且我不知道 signature 是根据 url 生成的...

但是我又有疑惑了. 那既然这样为啥不直接使用 appsecret 来生成 signature ?

sivacohan

2015-07-12 21:15:17 +08:00

@agate

access_token表示用户对你的服务暂时授权了。
appsecret是腾讯分给你的用于区分你的服务和别人的服务，同时对你的服务进行加密的。
仔细想一下，就清楚这几个地方了。

iyoood

2015-07-12 21:16:10 +08:00

appsecret是没有时效的

agate

2015-07-12 21:32:50 +08:00

@sivacohan @iyoood 根据微信的文档我的理解是

appsecret(没有时效) -[api]-> access_token(2小时) -[根据url和返回的token生成] -> signature

这些不都是发生在我服务器这端的么? 为什么中间需要一个这个 access_token?

mgcnrx11

2015-07-12 21:47:07 +08:00

用了OAuth2.0协议，就继续用下去呗

2015-07-13 10:24:15 +08:00

引用文档：
1、为了保密appsecrect，第三方需要一个access_token获取和刷新的中控服务器。而其他业务逻辑服务器所使用的access_token均来自于该中控服务器，不应该各自去刷新，否则会造成access_token覆盖而影响业务；
2、目前access_token的有效期通过返回的expire_in来传达，目前是7200秒之内的值。中控服务器需要根据这个有效时间提前去刷新新access_token。在刷新过程中，中控服务器对外输出的依然是老access_token，此时公众平台后台会保证在刷新短时间内，新老access_token都可用，这保证了第三方业务的平滑过渡；
3、access_token的有效时间可能会在未来有调整，所以中控服务器不仅需要内部定时主动刷新，还需要提供被动刷新access_token的接口，这样便于业务服务器在API调用获知access_token已超时的情况下，可以触发access_token的刷新流程。
----------------------------------------------------
业务服务器使用由中控获取的access_token比把appsecrect放在每一个的业务服务器要安全吧，就算万一中控的appsecrect泄露，只需要修改中控就可以了，不会影响到业务服务器

coolicer

2015-07-13 16:01:43 +08:00

没看到 js 可以取 access_token