使用 Akka-Http 进行身份验证

Posted 2023-03-04

【中文标题】使用 Akka-Http 进行身份验证

【英文标题】：Authentication with Akka-Http

【发布时间】：2016-05-11 03:39:36

【问题描述】：

我们正在开发一个 ios 应用，用户需要使用电子邮件+密码（或手机号码）进行身份验证。我们的后端由几个使用 Akka-Http 的微服务组成。它需要快速、可扩展、并发，并且身份验证+授权应该在我们的多个服务中工作。 我试图弄清楚要使用哪种身份验证方法。 Akka-HTTP 目前提供 Basic Auth 和 OAuth2 的部分实现。

所以起初我们考虑的是基本身份验证（太简单且功能不足）、Oauth1（太复杂），因此我们转向 OAuth-2.0，因为它是一种标准。

然后我们考虑了 AWS Cognito，因为它结合了 Oauth-2.0 和 OpenID Connect，它提供了 OAuth2 缺乏的身份验证机制。 http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

然后我们意识到 OAuth2 仅用于使用第三方进行身份验证 - 实际上我们不需要第三方身份验证提供程序 - 也许我们需要自己做，而使用 Cognito 是一种过度杀伤，会创建额外的 api在我们的微服务之外调用...

所以我阅读了一些关于使用 WSSE 规范创建我们自己的自定义身份验证提供程序的内容： http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html 而且我还发现了这个使用Spray的例子，但我确信它与Akka-Http没有什么不同： http://danielasfregola.com/2015/06/29/how-to-create-a-spray-custom-authenticator/ 看起来太简化了，而且没有令牌过期...

所以我的问题是，我错过了什么吗？我应该选择什么方法，在哪里可以找到它的示例？

我觉得我在绕圈子，我们将不得不从头开始编写我们自己的自定义身份验证提供程序，这有点没有意义。毕竟几乎每个人都需要身份验证，这应该是一个标准。

【问题讨论】：

坦率地说，我认为你过于复杂了，除非有你没有提到的具体要求。我通常将 API 放在 HTTPS 后面，允许移动客户端使用用户名/电子邮件和密码进行身份验证并返回类似 UUID 的令牌。我将令牌存储在某种分布式缓存中（memcached、ehcache、redis 或类似的）。

你的微服务在哪里运行？

我认为你的场景中根本不需要 OpenID Connect，所以一个简单的 OAuth2-Service 发出 accessTokens（参见 jwt.io），其中包括 userId、role 和 expirationTimestamp 应该是你的所有服务需要独立验证/授权请求。 imo 唯一有点棘手的是刷新令牌处理。

这就是我们最终所做的，我们实现了自己的简单刷新令牌行为

【参考方案1】：

我最近一直在使用 SoftwareMill 的 akka-http-session 库，发现它简单且易于集成。它支持基于案例类的会话、JWT、具有可插入存储的刷新令牌、使用标头和 CSRF 令牌以及一些用于路由的简单指令。