Restful api 怎么感觉有两个授权: 接口授权和登录授权

Question

对于restful api接口权限这里, 之前虽然做过相关开发, 但还是没底, 因为没有看到过特别完善的资料, 但在接口权限校验这里个人比较晕乎的是两点:

1. 接口权限
2. 登录认证

基本上在网上一搜 restful api 接口权限, 出来的基本上就是 oauth2, jwt, api_key等知识, 而且好像说的都差不多;

问题是 api 接口授权 和 登录授权 貌似不是一回事吧, 我都不知道网上那些资料说的到底是哪个授权?

个人认为:

1. 首先应该是要验证到底当前调用api的客户端, 有没有调用该api的权限, 这个貌似用oauth或者jwt 好像都能做 (可以在授权服务器上创建一个应用 配置前段逻辑代码部分有访问...api的权限, 然后分配access_token即可)
2. 如果客户端能够访问这个api接口, 那如果这个api接口需要用户登录才能访问呢? 好像 oauth或者jwt也都能生成access_token来实现

难道我这里的接口授权来一次oauth, 然后登录在来一次oauth么??

还有个疑问就是 oauth 的授权码模式经历了一大堆步骤最后就是仅仅通过一个access_token来进行授权校验 。。。。。。 总感觉是不是太简单了, 黑客们才不管你中间乱七八糟多少步呢, 我想他们只会去伪造你最后的access_token去访问敏感接口吧

Answer 1

REST 本质上就是充分利用 HTTP 协议，回到了 HTTP 本来的面貌，而不是请求就 GET/POST，状态就 200、302。所以，去看 HTTP 1.1 怎么定义就明白了，访问控制相关的错误代码是 4xx 号段，权限相关常用的有 401 未登录、403 禁止访问。这已经很清楚了，401 控制能不能访问某个系统或区域，403 在此基础上，控制某个具体的资源（或动作）是否有权访问。

再说回 oauth，它标识了登录与否，也就是说，access_token 与您的用户 ID 之间建立起了关系（通常的实现来说），然后用户 ID 又与此用户的授权表有关。仅当资源、接口来自另一个第三方时，才需要利用另一个系统的 oauth 与当前用户之间进行二次 access mapping。

当然，说到 oauth 我们经常见到另一种设计，就是在取得 access_token 后申请权限，需给出要申请的权限代号，这种情况我自己的开发过程中是映射到粗放的 role （一组许可资源的集合）上的，底层实现上与上面的没什么分别，都是在一个类似会话的数据中记录用户 ID 与授权动作之间的映射。

Oauth 只是协议，仅仅是一份数据交换的公约，要怎么实现，各显神通啦。

---

不过要抱歉了，书读得少，实用主义，能自己干的都自己编码实现，所以可能细节与某个您手头用的具体的组件的实现有出入。

---

补充点。

我公司的 APP 上有实现 Oauth，同时在第三方登录、微信公众号等上也有用到微信、QQ等的第三方 Oauth 接口。后来我觉得要在自己的私人项目上加上类似功能，但不想搞的太复杂，所以思考了下，相对经典的 Session 实现，不外乎这么两点：

1. 会话ID改了个名字叫 access_token，它并不必须通过 Cookie 和 URL 附加来传递，可以在 POST 里，可以包含在 JSON 或 XML 中，当然也可以在 URL 以参数的形式传递；
2. 服务端的会话（会话ID与用户ID的映射）是只读的，在权限颁发后程序不可写，避免程序员习惯性的把它当缓存或键值数据库使用。

这是我私人项目中 Java 中从普通请求中取会话 ID（同时也是 access_token）的代码，开始想过绕过 tomcat,jetty 从底层覆盖默认的获取会话ID的方法，但分析了源码后觉得不太靠谱，所以自己多写了些代码，顺便把整个会话的方法都做了。PHP 中这就不是个事，session_start 前先用 session_id 指定一下从其他地方取到的会话 ID 就搞定了，从此你的会话和 oauth 的 access_token 就完美统一了，剩下的就看你是不是要把会话的有效期延长了 （申明：实现不当而造成会话欺骗与我无关）。

所以，回过头再研究一遍经典的 WEB 会话再来看 Oauth 也许能更好的理解。当然这仅供参考，我的理解也许不好。

Answer 2

说下个人理解，其实吧，你强行区分了 接口权限 和 登录认证，但是在我看来，登录认证 就是 接口权限 的一部分，为什么？ 登录认证的作用不就是为了实现 用户在登录之后才能调用接口 这个功能吗，而接口权限呢，也是指定某类用户才能调用这个接口，你真的觉得有区别吗。