前后端是怎么验证身份的?

2018-01-25 07:56:58 +08:00
 ericgui

我前几天看了一个写 RESTful API 的教程

前端用 React 后端用 Express JS 和 MongoDB

后端写了几个 API,然后前端是一个单页应用( SPA ),用 fetch 来请求 api,获取数据。

看着相当好。

后来我就觉得不对:这 api 连个验证都没有,岂不是谁都可以来请求这个 api。

这数据也不是机密数据吧,但如果任何人都可以请求 api,拿岂不是 api 暴露给任何人了,用个爬虫,轻松就把数据下载光了。流量和带宽,该多费钱。。。。。

所以能否请高人介绍一下,这前后端分离,一般是怎样验证这个“前端”是自己的、官方的,而不是爬虫或者什么其他人写的非官方前端。尤其是写 app 的时候,app 显然算是“前端”或者“客户端”,那么服务端怎么验证这个请求是从自己官方的客户端发出的呢?

JSON Web Tokens ( jwt )?

谢谢

11219 次点击
所在节点    程序员
56 条回复
Enochyun
2018-01-25 15:20:21 +08:00
oauth2 是干嘛滴?
POPOEVER
2018-01-25 15:21:59 +08:00
@v2chou wx.login 的时候把用户 OpenID 解出来自己存库啊,小程序里校验 api 只是对微信侧的验证支持,你自己 request api 那边的安全只能自己写 user 表后用 OpenID 来比对校验然后放行
ivydom
2018-01-25 21:09:01 +08:00
最好正好在做通用认证系统,简单说一下:

具体可以看这里: https://github.com/Authing/authing

### 认证流程

![auth_uml]( http://usercontents.authing.cn/white_paper/authing_auth_uml.png)

认证通过后,后端会生成基于 JWT 规范的 Token。客户端将 Token 放到 HTTP 协议中的```Authorzation```头中并加上标注```Bearer```即可进行登录验证。

流程如下:

- 用户使用用户名密码来请求服务器
- 服务器进行验证用户的信息
- 服务器通过验证发送给用户一个 token
- 客户端存储 token,并在每次请求时附送上这个 token 值
- 服务端验证 token 值,并返回数据

#### JWT

JWT 是由三段信息构成的,将这三段信息文本用.链接一起就构成了 JWT 字符串。就像这样:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
```

##### JWT 的构成
第一部分我们称它为头部( header),第二部分我们称其为载荷( payload, 类似于飞机上承载的物品),第三部分是签证( signature).

###### header
jwt 的头部承载两部分信息:

- 声明类型,这里是 jwt
- 声明加密的算法 通常直接使用 HMAC SHA256

完整的头部就像下面这样的 JSON:

``` javascript
{
'typ': 'JWT',
'alg': 'HS256'
}
```

然后将头部进行 base64 加密(该加密是可以对称解密的),构成了第一部分.
```
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
playload
```

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分

- 标准中注册的声明
- 公共的声明
- 私有的声明

标准中注册的声明 (建议但不强制使用) :

- ```iss```: jwt 签发者
- ```sub```: jwt 所面向的用户
- ```aud```: 接收 jwt 的一方
- ```exp```: jwt 的过期时间,这个过期时间必须要大于签发时间
- ```nbf```: 定义在什么时间之前,该 jwt 都是不可用的.
- ```iat```: jwt 的签发时间
- ```jti```: jwt 的唯一身份标识,主要用来作为一次性 token,从而回避重放攻击。


**公共的声明 :**

公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.

** 私有的声明 :**

私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息,因为 base64 是对称解密的,意味着该部分信息可以归类为明文信息。

定义一个 payload:

``` javascript
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
```

然后将其进行 base64 加密,得到 Jwt 的第二部分。

```
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
```

**signature**

jwt 的第三部分是一个签证信息,这个签证信息由三部分组成:

- header (base64 后的)
- payload (base64 后的)
- secret

这个部分需要 base64 加密后的 header 和 base64 加密后的 payload 使用.连接组成的字符串,然后通过 header 中声明的加密方式进行加盐 secret 组合加密,然后就构成了 jwt 的第三部分。

``` javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
```
将这三部分用.连接成一个完整的字符串,构成了最终的 jwt:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
```

注意:secret 是保存在服务器端的,jwt 的签发生成也是在服务器端的,secret 就是用来进行 jwt 的签发和 jwt 的验证,所以,它就是你服务端的私钥,在任何场景都不应该流露出去。一旦客户端得知这个 secret,那就意味着客户端是可以自我签发 jwt 了。
Zzde
2018-01-25 21:13:44 +08:00
我的做法(小程序没有登陆)

和前端协商一个固定的 Token
每次请求以
* sign(md5(token+time)
* time
为参数验证身份

time 有效时间为 10s (其实可以更短)
ai277014717
2018-01-26 10:55:42 +08:00
看过一个源码,每次调用接口会发送两个请求,第一鉴定 session,第二个头里面包含有效的 session。session 过期逻辑可以自己设置,访问量,ip,时间,推出登陆之类的。
RorschachZZZ
2018-01-26 12:09:06 +08:00
1 登录发 token。2 前端每次请求带着 token。3 后端在逻辑前面验证 token。
ericgui
2018-01-27 00:26:36 +08:00
@ai277014717 能分享一下源码么? github url ?
Lullaby
2018-01-27 13:15:16 +08:00
令牌桶 & IP 频次记录
ai277014717
2018-01-27 15:43:23 +08:00
@ericgui 我看的是 parse-server-ios-sdk https://github.com/parse-community/Parse-SDK-iOS-OSX
还有 js 和安卓 php 等等的版本。
ericgui
2018-01-28 11:25:00 +08:00
@ai277014717 感谢分享,这个 Parse 是干什么的?看了半天没看明白啥意思
sothx
2018-01-29 05:52:48 +08:00
目前很多开放平台的的权限验证基本都是 token,也可以用 session ( cookie )
注意下安全方面的设置就差不多了。
前端也可以做权限鉴权,根据用户的权限,加载对应权限的路由,虽然是不可信的,但是也在一定程度上提高了安全。
ai277014717
2018-01-29 09:39:31 +08:00
@ericgui leancloud 就是模仿 parse 的是 Facebook 开源的一套产品,主要是把 HTTP 部分封装,客户端再也不用调用接口了,还有集成推送,云编码等功能。从 server 到客户端 sdk,很有学习的价值。
YMB
2018-02-03 16:05:11 +08:00
我们公司的这部分服务端就是我编码的,采用的模式是较为普遍的 Access Token,参考了微信的部分机制,过段时间有时间准备调研更优的实现,准备做一个更加灵活的架构。有一些文章楼主可以参考下: https://mengkang.net/625.html
ericgui
2018-02-04 02:03:22 +08:00
@YMB 感谢!
mingyun
2018-06-09 19:58:31 +08:00
@ivydom 很详细,star 了
mingszu
2018-07-31 16:07:25 +08:00
说说我的看法:

首先 restful 也是基于 HTTP 协议,而 HTTP 事务本来就是无状态的,也就是每一次请求与响应都是相互独立的,而身份认证那些都是慢慢扩展出来的

认证方法
(一) HTTP 请求头例如 Authorization,用于存储用户名与密码来实现用户验证,就算是 restful 也是 http,你也可以每次都在请求头上带上你的用户名密码来验证,但是每次都传输用户名密码太不安全了
(二) session-cookie 模式:用户第一次登陆验证通过服务器将用户信息存储于 session 中,然后将 session 存储在本地服务器中,将 sessionid 发给客户端,客户端将 sessionid 存于 cookie,以后每次请求都带上 cookie,服务器根据 cookie 中的 sessionid 去查询 session,从而获取用户信息,就这样实现了身份认证
(三)基于 token 认证方式:用户第一次登陆验证通过时服务器将用户信息等生成 token,然后返回给客户端,客户端下次访问时带上 token,服务器解析 token 就可以获取用户信息;
token 与 session 相比:token 存储在客户端,session 存储在服务器,因此 token 适用手机 app 与服务器通信而 session 不适合
(四) oauth2 第三方授权
(五)签名:防篡改防重放,客户端将每一个请求参数与值即 key-value 对排序(末尾加上 appscret )排序然后生成签名然后发给给服务端,服务端验证自己生成的签名与客户端的是否相同(根据客户端发来的 appkey 查找对应的),相同即请求未被篡改,而根据时间戳就可以限制该客户端访问次数,从而避免流量丢失

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/425736

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX