44

我开始设计 REST Web 服务，但不清楚最佳身份验证方法。该服务将允许个人用户访问/管理他们自己的数据，因此需要某种类型的用户身份验证。我一直在研究这些选项：

  • 身份验证

OAuth 似乎更多的是关于授权而不是身份验证。我计划在服务中本地处理授权，所以我不是在寻找解决方案。但是，OAuth 是否也适用于身份验证？

  • 开放ID

OpenID 确实提供了一种身份验证解决方案，但这更适合于允许用户使用他们的第 3 方凭据（Google、Yahoo 等）。虽然我愿意支持这一点，但这不是我主要关心的问题，我会绝对允许用户使用本机凭据（电子邮件/密码）进行注册。

  • HTTP 基本身份验证

这很容易实现，但据我了解，这可能不是一个非常安全的方法。此外，似乎需要为每次访问交换凭据，但我更希望用户进行一次身份验证，然后通过会话令牌继续访问。

  • 自定义身份验证

基本上，推出我自己的登录/令牌生成服务，并需要一个有效的令牌来访问所有其他资源（显然，一切都将通过 SSL）。

除了创建 Web 服务之外，我还将构建一个代表用户使用这些服务的客户端（Web）应用程序，但我不希望该应用程序必须存储用户信息/凭据/等。所以，像这样：

用户（使用电子邮件/密码或第 3 方凭据进行身份验证）--> Web 应用程序（使用应用程序 ID 进行身份验证）--> Web 服务

再一次，我希望其他人也可以构建客户端，所以中间层可以是任何 3rd 方应用程序：

用户（使用电子邮件/密码或 3rd 方凭据进行身份验证）--> 3rd 方应用程序（使用应用程序 ID 进行身份验证）--> Web 服务

我的最高要求是：

  • 安全（显然）
  • 本机凭据
  • 支持第 3 方凭据（Google、Yahoo、LinkedIn 等）
  • 支持多个客户端（Web 应用程序、移动应用程序、第 3 方应用程序等）
  • 客户端凭据（只是一个应用 ID？）
  • 过期的登录会话
  • 不需要授权

所以，我的问题是，基于上述（如果这太模糊，请告诉我），是否有“最佳”方法？OAuth 或 OpenID 是否合适，或者我是否让这太复杂了，而应该只滚动我自己的身份验证？

编辑：

我想我需要实现以下内容：

1）本机凭证/令牌（基于 SSL 的 HTTP 基本身份验证？）

2) 一个 OpenID“依赖方”，允许我的 api 使用托管在其他地方的 OpenID（即“支持第 3 方凭据”）

3) 一个 OAuth“消费者”，允许我的 api 访问 3rd 方服务（如访问用户的 LinkedIn 个人资料）。

4) 一个 OpenID“提供者”，允许人们在别处使用 api 的原生 ID（可选）

5) 允许第 3 方应用程序代表用户访问我的 API 的 OAuth“提供者”（可选）

这看起来是对的，还是我让它变得比需要的更复杂？

4

8 回答 8

13

您可以考虑 JWT (JSON Web Token) 请参阅JWT 草案 rfc。它肯定会满足您的安全和会话到期要求。然而，作为一个草案标准，它现在不太可能被广泛使用，这可能很快就会改变，因为 JWT 是 OAuth 2.0 的一部分。JWT 很容易在大多数语言中实现，并且已经有很多库。作为一个简单的解释，一个 JWT 令牌由 3 部分组成，头、正文和签名。标头和正文是经过 basee64url 编码的 json 对象（字母与 base64 的最后两个字符不同），然后使用 HMAC256（或标头中指定的另一种算法）签名，RFC 解释了如何准确生成此签名。您可能想查看此在线令牌生成器。

JWT 对 http 标头和查询参数很友好。

于 2014-09-08T15:16:26.483 回答
11

需要考虑的一个不错的选择是“共享密钥身份验证”。这是 Amazon Web 服务和 Windows Azure 存储服务使用的身份验证类型。我们在开发的 REST 服务中使用了共享密钥认证。您可以在 Google 中快速搜索“共享密钥身份验证”，您将获得很多详细信息。

我在这里写了一篇关于此的博客文章。

高级步骤是：

  1. 客户端组合了一组由 REST 服务定义的唯一数据（元素）。
  2. 使用只有客户端和 REST 服务知道的密钥签署此组合数据
  3. 将此签名作为 HTTP 标头的值发送到 REST 服务
  4. REST 服务计算签名的方式与客户端完全相同
  5. 将客户端发送的签名与计算的签名进行比较，如果相同，则假定其为有效请求，否则拒绝该请求
于 2014-02-21T02:01:34.743 回答
7

我的建议是对第一个请求进行身份验证，然后设置会话令牌。

前端应用程序将存储令牌并将其提供给每个后续请求。

令牌将有一个过期时间。令牌在一段时间内不使用就会过期。

令牌可以与原始 IP 地址相关联以增加安全性。

令牌可以作为 cookie 传输，也可以作为 URL 中的查询参数之一传输。

如果 SSL 客户端身份验证的麻烦是可以接受的，您可以使用相互 SSL 身份验证。必须为每个客户端提供服务器信任的证书。如果您必须以不同的方式对待客户，它可以是相同的证书，也可以是不同的证书。

于 2014-09-08T22:16:54.637 回答
2

根据您的要求，我认为OAuth 2.0实际上可能是一个有趣的选择。OAuth 确实是一种授权协议，但它也是Authenticates带有clientIdand的客户端clientSecret。您可以使用Client Credential Flowand 选择不包含Refresh Token，这样用户就有了Access Token，它会在一定时间后过期。由于 OAuth 是一种广泛使用的协议，它们已经有许多客户端和服务器端库供您和您的客户使用。

如果您认为 OAuth 对于您的应用程序来说太重或太复杂，我可能会坚持使用Basic Authenticationover HTTPS。但正如我在另一个类似问题的答案中所说的那样，我永远不会发明自己的身份验证机制。

有关更多信息，您还可以查看我之前针对类似问题给出的其他答案：https ://stackoverflow.com/a/15003777/849741

于 2013-11-01T13:42:49.973 回答
1

您可以使用 HTTP Basic Auth，其中传输的密码实际上不是密码而是令牌，客户端在不同的资源请求中获得，他/她/它必须提供他/她/它的密码一次且仅一次（甚至可能通过不同的渠道）。这并不能保护中间人攻击（因为没有消息签名），但想法是，您始终可以要求客户端以某种方式生成动态令牌（即在您自己的身份验证服务上），然后让它发送该令牌作为密码替换，因此实际密码不会不断地通过网络传输。是的，这看起来像是“自定义身份验证解决方案”之一，但实际上并不是因为您可以在令牌密码上施加您想要的任何规则，就像使用签名令牌作为会话绑定或在每个请求上重新计算的密码（不共享任何秘密），以便服务器可以验证消息 - 无论您需要什么。这个想法是将验证令牌作为 HTTP 基本身份验证请求的“密码”发送，而不是依赖更复杂的协议，同时不排除这些协议（由您选择）。

于 2014-03-18T23:38:19.627 回答
1

我已经实现并作为开源发布了一个允许身份验证的基本服务，如果需要，它可以很容易地更改为允许 3 元组登录。它大约有 2 年的历史，并在 Spring 上用 Java 编写，因此您可能想重新考虑该技术，但它确实有效，您可以了解它是如何完成的基本概念。在 google 上找到它，或关注我的博客文章。请注意，该应用程序不再在 cloudbees 上加载，但如果您在您的帐户上进行设置，一切都应该没问题。

于 2014-09-06T19:20:32.837 回答
0

如果您只需要授权，OAuth 2.0是可行的方法。您可以使用OpenID Connect，它提供身份验证并支持 OAuth2.0 进行授权。对于 OepnID Connect，如果您需要自己设置服务，有许多认证产品可用，也有许多在线服务可用。

于 2019-08-28T08:56:40.150 回答
0

我建议为您的 RESTful Web 服务使用 Spring Boot，因为这样您就可以使用他们的 Spring Security 根据他们的模板实现您自己的自定义身份验证。您可以通过分别扩展或实现其基本安全类和接口来实现您自己的自定义身份验证。如果需要，您还可以选择合并您在 Spring Boot 中列出的其他身份验证机制。

于 2017-07-27T20:30:34.537 回答