JWT authentication/authorization 与 Azure 的 Stormpath
Stormpath for JWT authentication/authorization with Azure
我们正在研究 authentication/authorization 移动报告应用程序，该应用程序使用内部提供的 RESTful 网络 api 服务通过网络使用 hourly/weekly/monthly 商业敏感数据 运行 在 MS Azure 云中。
Stormpath 的产品看起来很有趣，因为它似乎为整个身份管理方面提供了一些重要的提升，包括注册用户、验证他们和生成 JWT 令牌等。
否则，我们将不得不编写自己的 auth/user 数据库表，并因此产生一些管理开销。
我不完全清楚的是我们当前由 Azure 提供的不安全、未经身份验证的原型 API 需要与 Stormpath 相交。
任何人，尤其是熟悉 Stormath 的人都可以对此进行详细说明吗？
我知道所有用户注册、密码恢复用例都将通过 Stormpath，我猜测为用户创建 JWT 令牌需要我们现有的服务与 Stormpath 通信。我们的 RESTful 调用的 HTTP(S) headers 中的令牌验证是否由我们的 Azure 服务在本地完成（通过一些代码插件），如果是，验证是在本地完成还是每个 RESTful 调用对 Stormpath 的代理调用有副作用 API 以验证令牌的有效性？
我想我对 Web API 管道中整个令牌验证步骤的性能问题很敏感。
我在别处读到微软自己有一个产品，即 Azure AD B2C，它似乎还没有为 US/North 美国以外的地区做好生产准备。
我们是否应该考虑将其作为 Stormpath 等外包产品的替代方案？
像 Stormpath 这样的东西看起来很有吸引力的一件事是双因素身份验证的可能性。
在不进行过多分析的情况下，一个典型的用例场景是注册或密码恢复将要求将 SMS 发送到用户的预注册智能手机号码，以提供更强的验证（以及他们的 pre-registered设备）是移动应用程序的预期用户，该应用程序使用 RESTful 服务来使用和可视化商业敏感数据。
我在 Stormpath 工作，负责我们的 .NET 库。
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Stormpath 充当您的 API 访问令牌的来源。当使用您的移动应用程序的人需要登录时，您的后端 API 使用 Stormpath 生成访问令牌，或者移动应用程序直接与 Stormpath 对话以获取访问令牌。无论哪种方式，令牌都允许移动应用程序向您的 API.
发出 authenticated 请求
Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
可以使用中间件在本地验证访问令牌 (JWT) 完整性，例如 ASP.NET 中的 UseJwtBearerAuthentication。为了提高安全性，您可以将令牌发送到 Stormpath 以进行进一步验证（对于撤销和其他情况），但代价是网络请求。本地（快速）验证是默认设置，但我们为您提供两种选择。
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet. Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
使用 Stormpath 或 Azure AD B2C "outsourcing" 您的身份和用户管理。好处是您不必自己编写，您可以专注于编写您的业务和应用程序逻辑。功能相似，尽管 Stormpath 在移动端更灵活一些（因为您不必被迫使用 browser/page-based 流程）。
我们正在研究 authentication/authorization 移动报告应用程序，该应用程序使用内部提供的 RESTful 网络 api 服务通过网络使用 hourly/weekly/monthly 商业敏感数据 运行 在 MS Azure 云中。 Stormpath 的产品看起来很有趣，因为它似乎为整个身份管理方面提供了一些重要的提升，包括注册用户、验证他们和生成 JWT 令牌等。 否则，我们将不得不编写自己的 auth/user 数据库表，并因此产生一些管理开销。
我不完全清楚的是我们当前由 Azure 提供的不安全、未经身份验证的原型 API 需要与 Stormpath 相交。 任何人，尤其是熟悉 Stormath 的人都可以对此进行详细说明吗？
我知道所有用户注册、密码恢复用例都将通过 Stormpath，我猜测为用户创建 JWT 令牌需要我们现有的服务与 Stormpath 通信。我们的 RESTful 调用的 HTTP(S) headers 中的令牌验证是否由我们的 Azure 服务在本地完成（通过一些代码插件），如果是，验证是在本地完成还是每个 RESTful 调用对 Stormpath 的代理调用有副作用 API 以验证令牌的有效性？
我想我对 Web API 管道中整个令牌验证步骤的性能问题很敏感。
我在别处读到微软自己有一个产品，即 Azure AD B2C，它似乎还没有为 US/North 美国以外的地区做好生产准备。 我们是否应该考虑将其作为 Stormpath 等外包产品的替代方案？
像 Stormpath 这样的东西看起来很有吸引力的一件事是双因素身份验证的可能性。 在不进行过多分析的情况下，一个典型的用例场景是注册或密码恢复将要求将 SMS 发送到用户的预注册智能手机号码，以提供更强的验证（以及他们的 pre-registered设备）是移动应用程序的预期用户，该应用程序使用 RESTful 服务来使用和可视化商业敏感数据。
我在 Stormpath 工作，负责我们的 .NET 库。
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Stormpath 充当您的 API 访问令牌的来源。当使用您的移动应用程序的人需要登录时，您的后端 API 使用 Stormpath 生成访问令牌，或者移动应用程序直接与 Stormpath 对话以获取访问令牌。无论哪种方式，令牌都允许移动应用程序向您的 API.
发出 authenticated 请求Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
可以使用中间件在本地验证访问令牌 (JWT) 完整性，例如 ASP.NET 中的 UseJwtBearerAuthentication。为了提高安全性，您可以将令牌发送到 Stormpath 以进行进一步验证（对于撤销和其他情况），但代价是网络请求。本地（快速）验证是默认设置，但我们为您提供两种选择。
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet. Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
使用 Stormpath 或 Azure AD B2C "outsourcing" 您的身份和用户管理。好处是您不必自己编写，您可以专注于编写您的业务和应用程序逻辑。功能相似，尽管 Stormpath 在移动端更灵活一些（因为您不必被迫使用 browser/page-based 流程）。