Build Apps That Act on Behalf of Your Users with OAuth on OSC
OSC now supports an OAuth 2.0 authorization flow that lets your app authenticate other OSC users and operate inside their own workspaces. No shared credentials, no platform-level API keys. Each user owns their own resources.
When you build an app that other OSC users sign in to, you face a choice about whose infrastructure backs it. A single shared tenant means one API key, one billing account, and one namespace for every user who shows up. It is simple to implement and a security problem from day one. Anyone who compromises your server-side credentials has access to everything you provisioned for everyone. The alternative is to make each user's resources genuinely theirs. Their workspace, their token balance, their data. Your app operates inside their context, not yours. That is what the new OAuth authorization flow on OSC makes possible.
The Shared-Tenant Trap
Most apps that wrap an infrastructure platform end up using a single platform API key for all users. It is the path of least resistance: one key, one tenant, one billing account. The app provisions resources on behalf of everyone who signs in, and the platform sees only your account. This creates problems as the app grows. You pay for every user's resources. One misbehaving user can exhaust quotas for everyone. There is no natural separation between tenants. And when something goes wrong, the blast radius is the entire user base. The right model is multi-tenancy at the platform layer: each user authenticates against OSC directly, and resources are provisioned inside their own workspace. Your app is the intermediary, not the owner.
How the OAuth Flow Works
OSC implements a standard OAuth 2.0 authorization code flow with PKCE. Your app redirects the user to the OSC consent page. They sign in (if they are not already) and approve. OSC redirects back to your app with an authorization code. Your server exchanges the code for an access token and a refresh token. The access token is a standard OSC Personal Access Token (PAT) scoped to that user's workspace. Pass it as a Bearer token to OSC platform APIs and the SDK, and every create-instance and list-instances call runs inside their context. Resources appear in their dashboard. Tokens are deducted from their plan. PKCE (S256 method) is mandatory. The authorization code expires after 10 minutes. Access tokens are valid for 3600 seconds; refresh tokens for 7200. Both tokens should be stored server-side only, never in the browser.
Two Apps Already Shipping This
Two apps deployed on OSC use this flow in production today. Intercom Site (live at intercom.apps.osaas.io) lets visitors deploy cloud intercom systems inside their own OSC workspace. Sign in with your OSC account, and the app provisions an Intercom Manager instance, a WebRTC SFU, and a CouchDB database, all appearing in your own workspace. Media Convert (live at mediaconvert.apps.osaas.io) lets visitors transcode video using OSC infrastructure provisioned in their own workspace. It handles token refresh on top of the base flow, since transcoding jobs can outlive the 3600-second access token lifetime, so users never see an auth error mid-job.
What You Need to Implement
On the server side, your app needs four things: a route that generates a PKCE pair and state, redirects to the OSC authorization endpoint, and stores the verifier in the session; a callback route that verifies state, exchanges the code for tokens, and stores both in the session; a refresh function that calls the token endpoint with grant_type=refresh_token before the access token expires; and any API calls that pass the session's access token as Bearer auth. For the OSC TypeScript SDK, you initialize a Context object with the user's PAT and all subsequent calls run inside their workspace. For direct HTTP calls to platform APIs such as the deploy or billing endpoints, pass the token in the x-pat-jwt header rather than Authorization. Register your OAuth app under My Apps, OAuth Apps tab, in the OSC dashboard. You get a client_id and a client_secret. If you prefer not to pre-register, the dynamic client registration endpoint at /api/connect/register returns a short-lived credential pair your app can use without any manual setup step.
Read the Full Guide
The developer guide covers the complete flow end-to-end: PKCE generation, authorization URL construction, code exchange, token refresh, and security considerations for redirect URI validation and open redirect protection. If you are building an app intended for other OSC users and want each visitor to own their own resources, this is the right starting point.
Frequently Asked Questions
Do I need a paid plan to register an OAuth app?
Yes. Custom OAuth app registration is available on paid plans. If you prefer not to pre-register, your app can use dynamic client registration at runtime, which works on any plan.
Where do provisioned resources appear when a user authorizes my app?
All resources created through the user's access token appear in that user's own OSC workspace. They consume tokens from their own plan, not yours. You never share infrastructure across users or manage a platform-level service account.
What happens to the access token when it expires?
The access token is valid for 3600 seconds. Use the refresh token (valid for 7200 seconds) to obtain a new pair transparently. Open Media Convert ships a reference implementation of this refresh middleware you can copy directly.
Related Posts
Host Your Own Application on Open Source Cloud
Introducing My Apps: connect your GitHub repository, deploy your application, and get a live URL in minutes. With custom domains for paid tiers and built-in OAuth 2.1 support, OSC is now your open source application platform.
My Agent Tasks: Close the Loop Between Your Code, Your Services, and Your AI Agents
OSC now lets you create scheduled AI agent tasks that run against your own code and your own unmodified open source services. Your agents work on the same repo that deploys to My Apps, against the same real PostgreSQL, Valkey, and ClickHouse instances, on a cron you control.
From Vibe Coding to Agentic Engineering: What Your Infrastructure Needs to Keep Up
Vibe coding gets you to a working prototype fast. Agentic engineering gets it to production and keeps it there. Here is what the infrastructure gap looks like up close.