Platform

Leaving Authalla

How to move to another provider, in the order that keeps your users signed in for the longest. This page also lists what doesn't come with you. Read it before you choose us, not only when you leave.


What moves easily, and what doesn't

Your apps talk to Authalla over standard OAuth 2.1 and OpenID Connect, so moving them to another provider means changing configuration, not code. There are no passwords to migrate, because Authalla never stores one.

DataComes with youHow
Users (ID, email, name, email verified, status, last sign-in, scopes, created and updated times)YesApplication API
Configuration: tenants, apps, theme, domains, social logins, resource servers, organizations and their membersYes, without secretsManagement API
Enterprise SSO and SCIM connectionsTheir settings, without secrets or certificatesManagement API
PasskeysNoUsers create them again with the new provider. See Passkeys
Sessions, refresh tokens, connected appsNoUsers sign in again, and connect their AI agents again
Activity logNoIt can only be read on the dashboard's Activity page
Client secrets and social login secretsNoAuthalla shows them once and never again. Your copy, or the provider's console, is the source

Before you start: use your own domain

Your tokens' issuer, and the callback URLs your social login apps and your customers' identity providers point at, all use the host your users sign in on. On {tenant-id}.authalla.com that host is ours, so every one of them changes when you leave. On a custom domain such as auth.yourcompany.com the host is yours, and you can point it at the new provider if it supports custom domains.

Set the custom domain up early. Changing the host later means updating every app and identity provider once now, and again when you leave.


Export your configuration

The Management API reads back everything you configured. With an Account API key that has read scopes, page through:

  • GET /management/v1/tenants, then for each tenant GET /management/v1/tenants/{tenant_id}/… for its apps, theme, domains, social-logins, resource-servers and organizations
  • …/organizations/{organization_id}/members for each organization's members, 200 at a time
  • …/organizations/{organization_id}/connection for each organization's SSO connection

Secrets are never returned: not client secrets, social login secrets, SSO client secrets or certificates. Each app's redirect URIs, scopes and settings come back, so you can recreate the apps elsewhere and issue new secrets there.


Export your users

The Application API lists a tenant's users. Get a client credentials token for an app with the users:read scope, then page through:

GET https://api.authalla.com/api/v1/users?limit=1000&offset=0

Each response has users and total, newest first. Increase offset by limit until you have them all. Each user has id, email, name, email_verified, status, last_login, scopes, created_at and updated_at.

What the export doesn't include:

  • Passkeys. See Passkeys.
  • Linked social and enterprise identities. A user who signs in with Google or their employer's IdP is matched by email at the new provider, as long as the new provider links accounts by email.
  • Organization memberships. Export them per organization from the Management API, as above.
  • SCIM externalId. Your customers' directories have it, and they send it again when they connect SCIM to the new provider.

To import, most providers take a JSON or CSV of users. Many can also create users on first sign-in, matched by email.

Keep your user IDs

The sub claim in your tokens is the user's Authalla ID, the same value as id in the export. The new provider gives each user a new sub. If your database keys users by sub, keep the export: it maps each old ID to an email, so you can map that email to the new ID after each user's first sign-in. Some providers also let you import the old ID as an external ID.


Passkeys

A passkey has two halves. The private key stays in the user's password manager or on their device; Authalla never has it. The public key is stored with us. Authalla has no way to export the public keys today, so passkeys don't move.

This is what users see after the move:

  • On the new provider, the user signs in another way first: by email, or with whatever the new provider offers.
  • They then create a new passkey. The old one stays in their password manager until they delete it.

This holds on a custom domain too. A passkey only works on the exact host it was created on, but without its public key the new provider can't check it, so users create one again whichever host they used.


Move enterprise SSO and SCIM

Each enterprise customer configured their identity provider with Authalla's details, so each one has to change it. Plan this with them before you switch.

  • SAML. The SP entity ID is urn:authalla:sp:{connection-id}, which is ours whatever your domain. The customer adds the new provider as a new SAML application, or changes the entity ID and ACS URL on the existing one.
  • OIDC. The customer changes the redirect URI, https://{your-domain}/oauth2/enterprise-sso-callback, to the new provider's.
  • SCIM. The customer's directory pushes users to https://{your-domain}/scim/v2 with a token from your Authalla app. Point it at the new provider's SCIM endpoint with a new token, and it sends its users again.

The connection export gives you each connection's identity provider settings, such as its OIDC discovery URL and client ID, but not client secrets or certificates. Ask each customer for those again.


Switch your apps

For each app, change three values: the issuer or discovery URL, the client ID and the client secret. With a custom domain, the issuer can stay https://auth.yourcompany.com if the new provider serves it. Without one, it changes from https://{tenant-id}.authalla.com to the new provider's.

When you switch:

  • Everyone signs in again. Sessions and refresh tokens don't move.
  • Access tokens Authalla already issued keep working until they expire, 15 minutes by default, on servers that still accept Authalla's issuer.
  • Users connect their AI agents again if you run an MCP server behind Authalla.
  • Social login keeps working once you add the new provider's redirect URI to each of your OAuth apps at Google, GitHub and the others. The apps are yours, so nothing has to be recreated there.

Delete your data

When nothing signs in through Authalla any more, delete each tenant on its General tab in the dashboard, or with DELETE /management/v1/tenants/{tenant_id}. Deleting a tenant deletes its users, passkeys, sessions, apps, connections and everything else it owns, at once. Activity log entries aren't deleted with it. They expire on their own schedule: 90 days for sign-ins, SCIM and hooks, and a year for team activity (see Audit logs).

Closing the account itself isn't self-serve yet. Email hello@authalla.com and we'll delete it and everything in it.

Previous
Data residency