REST 中如何安全地处理用户登录问题？

在设计一个 App 与服务端交互的 REST 风格的 API 时，一直不知道如何处理有关用户登录的各种问题，如：

• 判定用户是否已经登录
• 如何对每一次 api 请求进行验证
• 服务端与客户端通信时确保用户授权信息不被泄露。

简而言之，如何设计用户登录？

另：有设计过 REST API （最好是已上线的应用）的童鞋，急切地想向您求教
My Email ：Fei2037%#gmail.com My QQ：Feiox#%qq.com
实在找不到了，只能在这里求老师 ~

回复内容：

在设计一个 App 与服务端交互的 REST 风格的 API 时，一直不知道如何处理有关用户登录的各种问题，如：

• 判定用户是否已经登录
• 如何对每一次 api 请求进行验证
• 服务端与客户端通信时确保用户授权信息不被泄露。

简而言之，如何设计用户登录？

另：有设计过 REST API （最好是已上线的应用）的童鞋，急切地想向您求教
My Email ：Fei2037%#gmail.com My QQ：Feiox#%qq.com
实在找不到了，只能在这里求老师 ~

API Server 如何处理 Authentication 其实和 REST 怎么设计没什么直接关系，REST 只是一种针对基于 HTTP 的应用（即 Web 应用）进行资源管理的设计原则，或者说就是指导你如何安排资源的一种设计理念而已。

至于处理用户认证（登录等），那是在 REST 设计完了之后的事情，属于服务器端的应用业务逻辑。

换言之，不管你如何设计（是否 REST，或者 REST 的正不正确，彻不彻底等等），都不会影响你处理用户认证的业务逻辑，这根本就不是非此即彼的事情。

但是很多人搞不清楚这一点，以为实践了 REST（更不要说大部分实践都是错的，或者不够彻底的）就一切都和以前不同了，甚至以为一旦用了 REST，任何事情（比如身份认证）都有且仅有一条正确的路可走了……这一点真有些哭笑不得。

以本问为例我们来做一个分析吧。

首先，服务器端的身份验证基本上有两类方式：一是基于 Cookie 的验证，一是基于 Token 的验证。选择哪一种要看你的实际情况。基于 Cookie 的验证历史悠久了，原理和做法无需赘言；近几年涌现了大量的公共 API 服务，它们基本上都使用了基于 Token 的验证，这主要是因为：

1. 处理跨域资源分享（CORS）——虽然 Cookie＋CORS 也不是完全不可能，但是比较难搞

2. 无状态性——有利于服务端扩展（伸缩性强）

3. C/S 解藕——服务器端和客户端可以完全分离，进而静态资源可以用 CDN 来处理，服务器端完全变成 API Service

4. CSRF Free——不依赖 Cookie，完全不担心跨域伪造请求攻击（这点尚有疑虑，有待考证）

……呃，忽然觉得有点跑题了，我的意思是你首先得选择一个验证方式，很明显基于 Token 的认证是趋势。

接下来，假定选择了基于 Token 认证这条路，你首先得搞明白 Token 是怎么玩的。简单地说：客户端先发送正确的认证信息（比如电子邮件＋密码），服务器端检查 OK 之后生成一个 token 返回给客户端，之后客户端所有的请求都要包含这个 token，服务器端只需要验证该 token 是否有效即可。这里有一张图，对比了 Cookie－based Authtication 和 Token－based Authentication，挺不错的：

好，按照 REST 的设计原则，我们需要一个 Endpoint 供用户来请求认证并获取 Token，比如像这样：

POST /authentication

在这里，“资源”就是认证（按照 REST 的要求，用名词来表示资源），使用 POST 方法去请求，附带数据为认证用的信息，返回结果看你的业务逻辑，但至少要有一个 token。客户端拿到 token 之后，先把它存起来（比如存到 SessionStorage 里），设置请求时的 HEADER 里 Authorization 的值为 Bearer ，完事了。

综上所述，这事和 REST 的关系也就是设计一个获取 Token 的 Endpoint 而已，没啥了不起的，剩下的事情都属于业务逻辑，该怎么写就看你的需求了。