使用 OAuth 2 令牌构建测试模式/实时模式 [英] Architecturing testmode/livemode using OAuth 2 token

问题描述

标题有点晦涩.我对特定架构模式的一些反馈感兴趣.

The title is a bit obscure. I'm interested about some feedbacks on a specific architecture pattern.

我们以 Stripe API 为例:当你使用这个 API 时，系统基本上分为两个部分:实时模式和测试模式.如果您到达/customers"端点，您可以根据所使用的 API 密钥类型检索测试模式客户或实时模式客户.

Let's take as an example the Stripe API: when you are using this API, the system is basically broken into two parts: live mode and test mode. If you hit the "/customers" end-point, you can either retrieve test mode customers or live mode customers, based on the type of API key used.

我在问自己如何使用 OAuth 2 访问令牌实现这样的模式.

I'm asking myself how I could implement such a pattern using an OAuth 2 access token.

在我的工作流程中，我有一个通过我的 API 进行通信的应用程序页面 (JavaScript).我有一个实时"/测试"开关，所以基本上我的整个网站都被复制到两个不同的环境中.

In my workflow, I have a single application page (JavaScript) that communicates through my API. I have a "live"/"test" switch, so basically my whole website is replicated into two distinct environments.

当我登录到我的应用程序时，我的授权服务器会创建一个唯一的访问令牌(OAuth 2 Bearer 令牌)，为每个请求发送该令牌.但显然，我的访问令牌与会话"相关联，而不是环境"(实时或假)，所以如果我想实现切换实时模式/测试模式，我不能依赖令牌，因为令牌是通用".

When I log in into my application, my authorization server creates a unique access token (OAuth 2 Bearer token), that is send for each requests. But obviously, my access token is tied to the "session", not an "environment" (live or false), so if I want to implement a switch live mode / test mode, I cannot rely on the token, because the token is "generic".

我想过两种选择:

• 根据实时模式或测试模式，我会向我的所有请求发送一个额外的标头(例如 X-Livemode，它要么是真要么是假).然后，在我的后端，我重用这个标头来自动为我的所有请求添加一个过滤器.

• Depending on live mode or test mode, I send an additional header to all my request (like X-Livemode which is either true or false). Then, in my back-end, I reuse this header to automatically adds a filter on all my requests.

如果我切换到实时模式或测试模式，我会向我的授权服务器询问另一个访问令牌.这意味着访问令牌将具有额外的上下文信息.但是，这似乎有点复杂，我不确定 OAuth 2 规范是否允许令牌具有此类附加信息.

If I switch to live mode or test mode, I ask my authorization server another access token. This would means that access token would have additional context information. However this seems a bit complicated, and I'm not sure that OAuth 2 spec allows token to have such additional information.

我不确定这篇文章是否清楚:p.

I'm not sure if this post is clear or not :p.

问题的第二部分是实现这样一个系统的最佳方法是什么，其中所有资源基本上在实时/测试模式之间重复?

The second part of the question, is what is the best way to implement such a system where all the resources are basically duplicated between live / test mode ?

据我所知，它应该像向所有资源添加isLivemode"属性一样简单，并确保我的所有 SQL 查询都知道这一点.这是正确的吗?

In my understand, it should be as simple as adding a "isLivemode" property to all resources, and make sure that all my SQL queries are aware of this. Is this correct?

谢谢！

推荐答案

我过去使用的一个更简单的解决方案(虽然有点变通)只是附加实时"或测试"(base64 或十六进制编码)到 api 密钥，如下所示:

A much simpler solution I've used in the past (albeit a bit of a workaround) is just to append "live" or "test" (base64 or hex encoded) to the api key, like so:

想象一下您的实际密钥是:

Imagine your actual key is:

9a0554259914a86fb9e7eb014e4e5d52

在您的密钥演示中，向用户展示您的密钥:

In your key presentation, present your key to the user as:

9a0554259914a86fb9e7eb014e4e5d526c697665

然后使用正则表达式去除已知字符.

Then use a regular expression to strip off the known characters.

或者，如果您有能力处理键值映射，更OAuth2 规范"的方法是为实时和测试生成唯一键，并对请求进行键值映射查找以确定是否存在属于现场或测试.

Alternatively, if you're equipped to handle key-value maps, a more "OAuth2-spec" approach would be to generate unique keys for live and test and do a key-value map lookup on the request to determine if one belongs to live or test.

这篇关于使用 OAuth 2 令牌构建测试模式/实时模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！