Multi-App Authentication

One login across your web app, SPA, mobile app, and desktop client.

Your product likely spans multiple applications—a web app, a mobile app, maybe a desktop client. Without shared authentication, users sign in separately to each one. With Scalekit’s Multi-App Authentication, you register each application as an OAuth client that shares a single user session. Users authenticate once and gain access everywhere.

Tip

👉 Check out the example apps on GitHub to see Web, SPA, Desktop, and Mobile apps sharing one session.

Who this is for

You likely need Multi-App Authentication if:

• You ship multiple apps (web app, mobile app, desktop companion, or SPA)
• Users expect to stay signed in across surfaces
• You want centralized session control and auditability across apps
• You want each app to have its own OAuth client and scopes

What it solves

• Friction in user experience: Repeated logins across your product suite
• Security gaps: Inconsistent session handling and token management
• Engineering overhead: Multiple auth implementations to build and maintain

How it works

1. Register each application as an OAuth client in Scalekit.
2. User logs into any app.
3. Scalekit creates a session for that user.
4. Other apps detect the session and skip the login prompt.
5. Logging out of any app terminates the shared session.

Revoking the Scalekit session does not automatically clear your application’s local state. Each app must clear its own session and stored tokens. A failed refresh token exchange is a reliable signal that the shared session has been revoked.

For proactive sign-out across all applications, configure back-channel logout URLs so Scalekit can notify each app when the shared session is terminated.

How session sharing works

Each application is registered separately in Scalekit and receives its own OAuth client, with credentials based on application type:

• Web app → client_id: webc_xxx + client_secret
• Single page app → client_id: spac_xxx
• Desktop app → client_id: ntvc_xxx
• Mobile app → client_id: ntvc_xxx

Even though each app has a different client_id, they all rely on the same Scalekit user session. Separate clients per app give you clearer audit logs, safer scope boundaries, and easier long-term maintenance.

Quickstart

1. Create applications in Scalekit

   Create applications in Scalekit for each of your apps. During setup, select the app type. Use the guide below to choose the right one.

2. Configure redirect URLs for each app

   Redirects are registered endpoints in Scalekit that control where users are sent during authentication flows. Configure redirect URLs for each application.

3. Implement login flow for each app

   Once your applications are registered, each app follows an OAuth-based authentication flow. Use this detailed guide for implementing login/signup flow in your apps.

4. Manage sessions and token refresh

   After users successfully authenticate in any of your app, you receive session tokens that manage their access. Use this detailed guide to manage sessions in your apps.

   Note

   As part of the auth flow, your app will receive an access token. Validate it by checking the issuer, audience (which must include the application’s client_id), iat, and exp. Store tokens securely, and use the /oauth/token endpoint with the refresh_token grant to obtain new access, refresh, and ID tokens when needed.

5. Implement logout

   Initiate logout by calling the /oidc/logout endpoint with the relevant parameters. Clear your local application session when refresh token exchange fails, or configure back-channel logout to proactively sign users out across all applications sharing the same session.

   You can follow this detailed guide to implement logout in your apps.

Choose your app type

App Type	Description	Has Backend?	Uses Secret?	Auth Flow
Web app (Express, Django, Rails)	Server-rendered or backend-driven apps with secure secrets.	✓	✓	Authorization Code
SPA (React, Vue, Angular)	Frontend-only apps running fully in the browser.	✗	✗	Auth Code + PKCE
Mobile (iOS, Android)	iOS or Android apps using system browser flows.	✗	✗	Auth Code + PKCE
Desktop (Electron, Tauri)	Electron or native desktop apps with deep links.	✗	✗	Auth Code + PKCE

Key takeaways

• Each application has its own OAuth client but shares a single Scalekit user session
• Any application can initiate login or logout
• OAuth scopes and token validation rules remain consistent across apps
• Refresh token failure is a reliable signal of session revocation
• Back-channel logout enables proactive sign-out across all connected applications

Troubleshooting

1. ”Invalid redirect_uri” error

   The exact URI (including trailing slashes and query parameters) must match what’s configured in Dashboard > Developers > Applications > [Your App] > Redirects. Common mismatches:

   • http vs https
   • Missing or extra trailing slash
   • Different port numbers in development

2. Session not shared between apps

   Verify all applications are registered in the same Scalekit environment. Apps in different environments maintain separate session pools and cannot share authentication state.

3. User prompted to login on every app

   Check that:

   1. All apps use the same Scalekit environment URL
   2. The browser allows third-party cookies (required for session detection)
   3. The user is using the same browser across apps

4. Refresh token rejected

   The Scalekit session may have been revoked from another application, or the refresh token has expired. Redirect the user to log in again to establish a new session.