实务中，为了安全性，设计API时需要使用oauth那套规则吗？大厂都是怎么做的？

Question

如题，我在学习API接口时，如果需要获取某个用户的信息，可以写成如下的形式： api/getUserInfo?userId=123 这里的问题是，用户的id是自增的，很容易就被人猜出来有多少用户，而且可以去修改参数调取别人的资料。 我现在要做一个稍微正式点的网站，需要考虑安全问题。我的第一个想法是，用一个guid来代替userId，这样就不会暴露用户id，其他人也不能随便改个id就取到用户信息。甚至，我可以在前后端分别用加密解密的方式，对这个guid进行一次加密操作，让其他人更无法破解。 但是我看到有人说应该用oauth，我看了一下，好多例子都是关于“第三方应用获取授权”的，根本不是一个单一系统中的。 请问，在实务中，为了安全性，有必要使用oauth吗？

Answer 1

有没有必要使用oauth我不好回答，但是有方案来解决你的api/getUserInfo?userId=123得问题，
可以参考这里hashids-id加密方案，这样的话用户ID就没有任何规律可循了

Answer 2

前台只能获取当前用户所有信息,后台也只有有权限的管理员才能看到用户的信息.一般是不会设计这种接口的.除非是极少数.这个时候一般的会有两种情况.一种无状态的API,一种有状态的例如session.
有状态的好处理,直接根据当前的session来获取当前的用户,并且查看是否有权限.
无状态的,就要根据你们的规范来.如果是在header中存的用户的token,则将用户token获取到查询.如果是通过其他方法,请自行查找.
最基本的套路都是根据当前用户是否有权限来获取.

Answer 3

你的问题跟 OAuth 没关系。

api/getUserInfo?userId=123
这里的问题是，用户的id是自增的，很容易就被人猜出来有多少用户，而且可以去修改参数调取别人的资料。

不管 ID 是什么，也不管别人是否可以猜到 —— 没有权限看的 id ，就不能看 ，先实现这个“功能”就好了。

Answer 4

简单起见，你可以在用户登录的时候，利用用户名等数据生成一个token，然后返回给客户端，每个请求都带上这个token，后台做一个filter，对每个请求的token进行验证，验证的方式决定的安全的高低，比如添加token的时效性等。

Answer 5

一般使用openid不直接使用userId

Answer 6

如果是后台API，且只给公司内部用，不开放出去，那么最实用的方法有两种：

1. 限定IP地址；
2. HTTP Basic认证。

如果是前端API，那么只应该给已登录的用户用，登录通常会有个Session的（体现在浏览器里就是Cookie），用Session来认证就可以了。

另外，公开用户ID也没什么不可以的，用户量、订单量这类数据基本没啥可保密的。当然，有些公司并不用自增键作为用户或订单ID，而是用日期加一串规则，这样也可以。

Answer 7

可以不用 oauth 加密实现 可以参考 JWT

Answer 8

你这问题和oauth 没有关系
一般情况下，userid 是在后台session 中存储的，前台url 根本不需要知道，即使需要知道，后台在用的时候，也是需要进行权限验证才可以用的。
二般情况下，一个非常low的网站，或者app 后台没有session，那么前台在用的时候 userid 肯定是经过加密的，后台在用的时候也是要校验之后再用

Answer 9

而且可以去修改参数调取别人的资料

防止用户资料被别人调取，需要做的是验证调取者的身份，而不是隐藏user_id。

Answer 10

你说的是 hashid 吧 composer require elfsundae/laravel-hashid

Answer 11

OAuth 本意是用来将接口提供给第三方使用，当然也可以自己用，这个不难学，只要看几篇文章就会。但是，OAuth 并不能保证足够的安全，这方面还是要开发人员自己注意。比如说，在具体的业务接口设计方面，有几个原则需要遵守：

1. 参数最少化。因为 token 就已经能关联到用户的所有信息，所以除此之外不要再有任何与用户有关的参数。也就是说，鉴权完成之后，token 就可以帮助隐藏 userid 之类的信息了。token 是临时性的，比 userid 更安全。
2. 通信加密。与其将某个参数值进行加密，不如对整个通信进行加密，也就是使用 HTTPS。
3. 用户隔离。任何一个用户都不能通过接口返回的信息来推断任何其他用户可能的信息。