For developers
Ship an app that never holds your users' data.
Sign people in with SproutOS and hand each of them a Postgres database of their own. You get the app; they get the rows. It is the same amount of work as any other OAuth integration, and it is the one thing that actually lowers switching costs in consumer software rather than promising to.
Why you would want this
Holding everybody's data is a liability you have been taught to call an asset.
- You stop being the custodian
- The rows live in a database the user pays for and controls. A breach of your servers is not a breach of their history, and a subject access request is a link to their own database rather than an engineering week.
- Your storage bill stops tracking your signups
- Per-user data is on the user's account, metered to them. Growth costs you compute, not a storage line that grows forever whether or not the user ever comes back.
- You compete on the app, not on the moat
- Users who can leave easily are users who stayed because they wanted to. That is a harder bar and a much better signal than a retention number propped up by an export button nobody can use.
The integration
Authorization Code with PKCE, and one extra scope.
SproutOS publishes an authorization server metadata document, so a conforming client can discover the endpoints rather than hard-code them. If you have integrated an OAuth provider before, there is exactly one new idea here — the database scope.
- 1
Register a client
Exact HTTPS redirect URIs, Authorization Code with PKCE. Public clients use S256 and ship no secret.
- 2
Send them to authorize
client_id, redirect_uri, response_type=code, code_challenge, code_challenge_method=S256, state, and the scopes you need. Validate state before exchanging the code.
- 3
Ask for a database, optionally
database:create spends the user's SproutOS credit. Add intent=create_personal_database and the consent screen explains the billing. The user can decline that permission and still sign in.
- 4
Hold a credential you do not own
Database credentials belong to the grant that created them. Connection URIs are returned once. Rotating your application credential does not touch the user's, or another application's.
- 5
Let them revoke you
From their settings, without asking you. Revocation stops new API calls and revokes the credentials that grant owns — and whatever the user chooses to keep stays theirs.
A grant may include database creation even when the account has no credit — the creation request returns HTTP 402 until there is some. Handle that case and the rest is an ordinary token exchange. The full reference is in the OAuth applications guide.
Switching costs fall when enough apps agree to stop holding the data.
One app doing this is a nice privacy story. Enough apps doing it is a market where a better product can actually win — and where your users' history is a reason to try you rather than a reason they cannot.
Start with the developer docs