refresh token和access token的具体问题

[不吃天鹅肉]

如题，本人纯小白，正在自学访问api这块，现在有一个api需要授权。我先访问获取token的api返回值包括refresh token 和access token，再用token访问另一个api，这两个的概念我懂，就是在accesstoken过期以后用refresh token获取最新的accesstoken，可是具体步骤还是一脸懵。假设获取token的api是A,实际要访问的api是B，那么我再accesstoken过期以后是用refreshtoken重新访问B就获取到了吗？还是访问A，可是访问A应该怎么把这个refreshtoken传入进去呢！ 或者是我的这两个猜测都不对，那么我应该怎么重新获取呢！麻烦写具体一点，谢谢各位

[X-i-n]

一句话版本：到文档里找专门的刷新token的接口（这个接口可以和请求token的接口是同一个，也可以是不同的接口，完全看接口提供方如何设计），通过refresh token申请新的access token，然后才去请求实际的业务接口。如果refresh token也过期了，那就重新走一遍获取token的接口，申请一套新的access token + refresh token。 用一个假想中的案例做讲解吧，讲一下api设计流程你就明白了： 比如现在我们需要为一个系统写一套api，https://api.abc.com，其中有这么几个接口： /user/list用于获取所有用户 /user/info用于获取某个用户的详细信息 /depart/list用于获取所有部门 即使从未接触过开发，也应该明白，从数据安全角度来看，这类接口绝不可以不做任何验证就允许所有人匿名访问，但提供今日热点的接口 /news/today就不会因为向匿名访客开放而产生安全问题。 因此可以看出，鉴权是接口的非必选部分，可以因为接口数据比较敏感，也可以因为虽然数据不敏感，但由于业务需要（降低压力、鼓励用户）而加上鉴权，完全取决我们自己（当然也要适当地考虑合理性）。 而鉴权的形式则是五花八门，这完全取决于如何去设计。 让用户请求所有接口的时候，都带上用户名密码，行吗？当然可以。为所有账户分配一个各不相同的具有唯一性的api secret，每次请求接口都带上这个字符串，可以吗？当然可以。后者的好处是可以不修改密码，而通过api secret实现权限控制（比如api secret泄露），又不需要暴露账户信息（想象一种场景，账户在自己手里，委托别人进行开发，只需要交出api secret即可，对方只能进行开发，不能看到账户详情，更不能管理账户，而且你还可以随时销毁旧的，生成新的）。 展开得有点多了，还是从最初的需求开始设计吧： 1. 首先提供一个任何人都可以访问的登录接口 /auth/token 供用户申请访问业务接口所需的临时token，用户传入用户名、密码、API KEY之类的信息，认证通过后，在服务器上生成一个专属的字符串做为请求接口用的临时token，记下这个临时token以及颁发时间（方便设置过期条件）并返回给用户。千万不要纠结每种认证参数的名字，只需要知道这东西是一把钥匙，知道它用于哪把锁就行。可以给账号认证接口用的安全字符串（和密码类似，除非手工重置，否则永久有效）起名字叫token、api key、api secret、授权码、安全码……，也可以给认证成功后，用于访问接口的临时安全字符串起名叫token，叫ticket，叫任何其它你喜欢的名字，这完全取决于设计者的喜好（尽量将接口规范、命名、业务流程设计得便于理解，比如ticket最好是用在一次性有效的票据性质的参数名里）。 2. 这一步可以发挥的空间更大了，不过按refresh token + access token的设计，在第一步中的/auth/token需要返回这两个token，当access token过期，通过向/auth/refresh接口传入refresh token来获取新的access token，然后才能用于业务接口请求。 也有这样的接口设计：服务器的临时code + api secret获取一次性ticket，用ticket去申请token，在有效期内只要成功请求过业务接口，这个token的有效期自动延期。

[不吃天鹅肉]

引用 1 楼 X-i-n的回复:

一句话版本：到文档里找专门的刷新token的接口（这个接口可以和请求token的接口是同一个，也可以是不同的接口，完全看接口提供方如何设计），通过refresh token申请新的access token，然后才去请求实际的业务接口。如果refresh token也过期了，那就重新走一遍获取token的接口，申请一套新的access token + refresh token。 用一个假想中的案例做讲解吧，讲一下api设计流程你就明白了： 比如现在我们需要为一个系统写一套api，https://api.abc.com，其中有这么几个接口： /user/list用于获取所有用户 /user/info用于获取某个用户的详细信息 /depart/list用于获取所有部门 即使从未接触过开发，也应该明白，从数据安全角度来看，这类接口绝不可以不做任何验证就允许所有人匿名访问，但提供今日热点的接口 /news/today就不会因为向匿名访客开放而产生安全问题。 因此可以看出，鉴权是接口的非必选部分，可以因为接口数据比较敏感，也可以因为虽然数据不敏感，但由于业务需要（降低压力、鼓励用户）而加上鉴权，完全取决我们自己（当然也要适当地考虑合理性）。 而鉴权的形式则是五花八门，这完全取决于如何去设计。 让用户请求所有接口的时候，都带上用户名密码，行吗？当然可以。为所有账户分配一个各不相同的具有唯一性的api secret，每次请求接口都带上这个字符串，可以吗？当然可以。后者的好处是可以不修改密码，而通过api secret实现权限控制（比如api secret泄露），又不需要暴露账户信息（想象一种场景，账户在自己手里，委托别人进行开发，只需要交出api secret即可，对方只能进行开发，不能看到账户详情，更不能管理账户，而且你还可以随时销毁旧的，生成新的）。 展开得有点多了，还是从最初的需求开始设计吧： 1. 首先提供一个任何人都可以访问的登录接口 /auth/token 供用户申请访问业务接口所需的临时token，用户传入用户名、密码、API KEY之类的信息，认证通过后，在服务器上生成一个专属的字符串做为请求接口用的临时token，记下这个临时token以及颁发时间（方便设置过期条件）并返回给用户。千万不要纠结每种认证参数的名字，只需要知道这东西是一把钥匙，知道它用于哪把锁就行。可以给账号认证接口用的安全字符串（和密码类似，除非手工重置，否则永久有效）起名字叫token、api key、api secret、授权码、安全码……，也可以给认证成功后，用于访问接口的临时安全字符串起名叫token，叫ticket，叫任何其它你喜欢的名字，这完全取决于设计者的喜好（尽量将接口规范、命名、业务流程设计得便于理解，比如ticket最好是用在一次性有效的票据性质的参数名里）。 2. 这一步可以发挥的空间更大了，不过按refresh token + access token的设计，在第一步中的/auth/token需要返回这两个token，当access token过期，通过向/auth/refresh接口传入refresh token来获取新的access token，然后才能用于业务接口请求。 也有这样的接口设计：服务器的临时code + api secret获取一次性ticket，用ticket去申请token，在有效期内只要成功请求过业务接口，这个token的有效期自动延期。

感谢您的解答，但是我还有一点疑惑，拿我现在想要请求的数据来说，我获取token的这个api需要传入参数apikey和集团授权id，然后返回refresh token 和 access token，那么假如token过期，我能否这样理解，必然有一个api是传入参数为refresh token(或者包括)，然后返回参数为access token(或者包括)，我只需要访问这个api就可获得新的token，而这个api可以是和获取token的api同一个，也可以是不同的。当然，也可以是用服务器code和secret。 我这么理解有误吗？

[X-i-n]

这个就要看接口实际如何设计的了，具体以文档为准。如果按通常大家的理解去看这两个变量的作用，你说的没错。但是，最终一切还是以文档为准。