Use case for multiple API Keys?

[abe-101]

https://github.com/dj-stripe/dj-stripe/blob/5f4734fe6ee1c3173645fe47358ba7ecf79a38a2/docs/api_keys.md?plain=1#L34C15-L34C63

This project keeps the API keys in the db the reason give is supporting multiple Stripe accounts per instance.

Can you give me an example use case for needing to support multiple Stripe accounts?

If your application is acting on behalf of other stripe accounts then the correct approach is to use Stripe Connect where the "other" account authorized you the platform to act on its behalf. Once authorized you can make all api call on their behalf by simply adding the account ID in the api header when calling the stripe api (or the sdk). No need for any secret api keys.

This is begging the question why would an application need to manage multiple APi keys?

[jleclanche]

Hi @abe-101

Some use cases would include eg. having multiple brands, each on their own stripe account, managed centrally by a single shared database.

[abe-101]

@jleclanche I hear you But theoretically even with multiple brands it can be done through connected accounts. Each brand would have its own stripe account that gave authorization to the platform account to act on its behalf. If something isn't clear I'd be happy to elaborate.

It's my understanding that the project is considering a V3 I would encourage a discussion of perhaps removing support for multiple API keys and instead fully support connected accounts.

Would removing removing support for multiple API keys simplify the db schema? If using Connected account you would add a stripe_account_id fields to all models that would store the account. and all operations would then use that id.

[jleclanche]

What is the reasoning behind wanting to remove this? It's a feature that we specifically contributed in as it was requested by several users. I've myself used it as it makes no sense to use Stripe Connect in these situations (it's just added costs).

[abe-101]

Are you sure Stripe Connect costs? I know with a standard account there are not extra fees (besides the stripe tax 2.9% +30 cents) With an express account I know there are other charges

[abe-101]

I don't know enough of your use case but I suspect it can be solved using connected accounts.

Assuming Connected account is a viable option I'd argue as many have that keeping API keys in the db is a bad idea and if that can be avoided, with some breaking changes it should be done in a new point release.

There is a big difference btw the billing db and API keys the billing db has no way to move money vs API key (if unrestricted) can definitely move money. The docs do warn about it and suggest a read-only key:

Please do keep your billing database encrypted. There's a copy of all your customers' billing data on it! You may also instead create a read-only restricted key with all-read permissions for dj-stripe. There is no added risk there, given that dj-stripe holds a copy of all your data regardless.

The issue with a read-only key is that you then need a second key to create anything (new customers, checkout sessions, transactions etc) but I have a strong feeling that most people just have one key - which is imo risky and bad practice

So as a project I argue we should promote and support the commonly excepted way of storing sensitive API keys as variables

[jleclanche]

You raise some good points but as a whole, I don't think having the API key in config is intrinsically safer than having it in a dedicated database table. Config values have as many opportunities to leak as database values.

The problem I can see is that there are SOPs to treat certain config values as sensitive and make them less likely to leak; and this way of operating is not compatible with those SOPs.

There might be a case of just waiting a bit before taking a decision, because Stripe is currently working on some different ways of handling test vs. live keys and the complexity of handling both test and live keys simultaneously was a significant influence for the design of this system.

[jleclanche]

@abe-101 answering #1529 I realized also that part of the use case was to be able to add irregular api keys (such as restricted keys) to the database as well. This is not something that scales with a single API key in the settings system.

[jleclanche]

Closing - we will keep this support.