实务中，为了安全性，设计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，且只给公司内部用，不开放出去，那么最实用的方法有两种： 限定IP地址； 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