面向客户端的RESTAPI身份验证

我看到过许多关于不同的RESTful API认证解决方案的帖子，鉴于当前的场景，我有一些问题

我已经构建了一个RESTAPI，它将允许我的软件服务（我们是一家B2B公司）的客户端以编程方式访问资源。现在我已经让API正常工作了，我想以最标准化的方式保护它。我需要允许基于API的调用方访问某些资源。也就是说，并非API的所有用户都可以访问所有资源

我有以下格式的URL：

https://mydomain/api/students
https://mydomain/api/students/s123
https://mydomain/api/students/s123/classes
https://mydomain/api/students/s123/classes/c456

到目前为止，我已经提出了以下可能的解决方案：

为每个客户端提供一个唯一的密钥，它们可以使用该密钥最终生成一个加密令牌，该令牌将在每个REST调用结束时作为GET参数传递，以对每个请求进行（重新）身份验证。这种方法是否太昂贵

在HTTP授权标头中提供一个值，如图所示。这和#1差不多吗？（除非我无法将URL粘贴到浏览器中）人们是否还会使用这些标题

使用OAuth2（我还不太清楚）。OAuth 2是否实际将客户端验证为登录用户？这不违背RESTAPI无状态的精神吗？我希望OAuth是适合我的解决方案（因为它是一个公共标准），但是在读了一点之后，我不太确定。RESTAPI调用是否过度和/或不适当

我的目标是为每个希望使用API的客户机提供一个不必更改的API，而是提供一个可供所有客户机使用的标准文档

---

如果我不清楚的话，我很乐意发布更多的细节

您可能需要准备两种类型的客户端：

• 受信任的客户端-由您编写。他们可以拥有实际用户的用户名和密码，并且可以在每次请求时将数据发送到服务器，可能是HTTP auth头中的数据。你所需要的只是他们加密的连接

• 第三方客户端-由一些随机开发人员编写。您可以在服务中注册它们，并为它们中的每一个添加唯一的API密钥。之后，如果用户想要使用他们的服务，您必须向她显示一个提示，允许她访问第三方客户端。之后，第三方客户端将被分配到具有给定权限的用户帐户，并将获得用户特定的访问令牌。因此，当客户端将其API密钥和用户特定令牌与请求一起发送时，它会以用户的名义发送请求

OAuth可以帮助您控制第二种情况

您的URL对客户端没有意义。通过REST，您必须通过发送带有语义注释的链接（例如链接关系），将客户端与URL结构分离。因此，您的文档不必包含关于URL结构的任何内容（可能对服务器端调试有用，但仅此而已）。你必须谈论不同类型的链接。通过在服务器端生成这些链接，您可以检查实际用户（或第三方客户端）的权限，并跳过她无权访问的链接