When developing a SaaS that will create draft payments for multiple connected accounts, should I create one certificate for my application for signing requests?
When looking at the PHP SDK it always creates a new keypair for every ApiContext.
I don't see the benefit of this, now Bunq ends up storing [potentially] 100s of public keys and one SaaS platform ends up storing 100s of private keys...
If you look at the serialized data from the context it contains a lot of keys & tokens:
- api_key
- installation_context.token
- installation_context.private_key
- session stuff
So the session stuff is ephemeral, it is valid for a week and can be generated from the other stuff.
The installation context has a few keys (public client & server, private client) and a token. I'm thinking that I could just always pass the same public key to the API and reuse it.
The token is then passed to the session-server
endpoint when creating a new session, since the token identifies an installation no unique signing key is required.
PS. I'm also working on auto-generating a proper SDK that actually looks like and uses modern PHP features instead of the monstrosity that Bunq ships, where for some reason everything is static and nothing is typed. (Oh and also it is never updated and doesn't run on PHP8)
Did anyone do this? Reusing the same keypair for multiple installations?