Questions about Authalla

Your app sends users to a sign-in page Authalla hosts, they sign in, and Authalla sends them back to your app with standard OpenID Connect tokens. You don't build sign-in screens, store credentials or send sign-in emails.

What you set up:

• A tenant: your users, your sign-in methods and your sign-in address, such as auth.acme.com.
• An app in the tenant, with the address users come back to after signing in, such as https://acme.com/auth/callback.
• Your code, which redirects to the tenant and reads the tokens. Any OpenID Connect library does this, so there is no Authalla SDK to install.

The installation guide walks through it, and a coding agent connected to our MCP server can do it for you.

No. Your coding agent can set Authalla up and write the integration, an OpenID Connect library in your language handles the protocol, and the Next.js starter is a working app to copy from.

The one idea worth knowing: users leave your app to sign in on a page Authalla hosts, and come back with tokens that say who they are. Everything else is configuration.

A tenant is a set of users and the way they sign in, with its own sign-in address. An app is something those users sign in to, such as your web app, your mobile app or your admin tool. Most products have one tenant per environment and an app in it for each thing users sign in to.

A user's account belongs to the tenant, so it works in every app in that tenant. Users in different tenants never meet, even with the same email address.

Yes. Create a tenant for each environment: Production, Staging and Development. Each has its own users, apps and sign-in address, so test sign-ups never reach your production users.

Your code is the same in every environment. Only three values in each environment's configuration differ: the tenant's address, the app's client ID and, for a server-side app, its secret.

The environments guide covers local development and preview deployments too.

Yes, exactly as it does on subdomains. The environments' domains don't need to have anything in common, because nothing in the sign-in depends on your app and Authalla sharing a domain or cookies.

The sign-in is a redirect: your app sends the browser to the tenant's sign-in address, and Authalla sends it back to an address you registered on the app. Each tenant gets its own sign-in address, so production can sign users in at auth.acme.com and development at auth.acme.dev. One product spread over several domains, such as acme.com and acme.fi, works the same way.

Yes. Point a subdomain such as auth.acme.com at Authalla with two DNS records, and Authalla issues and renews its certificate. Custom domains are in every plan.

Set up production's domain before your users start signing in. Passkeys belong to the address they were created on, so users who created one on the tenant's authalla.com address would sign in once by email and create a new one after a move. See custom domains.

No. Authalla hosts the sign-in pages and your app redirects to them. That is what lets passkeys, email codes, social sign-in and your customers' own identity providers work without any of that code in your app, and it keeps credentials out of your app altogether.

You make the pages yours instead: your logo, colours, font and corner style, your own domain such as auth.acme.com, and English, Finnish or Swedish. See branding.

Yes. A redirect address on localhost matches any port, so http://localhost/auth/callback covers every developer's machine whatever port their app runs on.

Other redirect addresses must match exactly, as OAuth 2.1 requires, so there are no wildcards for preview deployments. Your CI adds each preview's address to the development tenant's app through the Management API when it deploys, and removes it afterwards. The environments guide shows how.

No. Put both apps in the same tenant, and one account works in both. On the web, a user signed in to one of your apps is signed in to the others in that tenant without typing anything again.

Register the mobile app as a native app. It signs in through the system browser with PKCE, using your platform's OAuth library, so no secret ships inside the app.

Any that has an OpenID Connect client library, which is nearly all of them: Node.js, Python, Go, Java, .NET, PHP, Ruby, and mobile apps through their platform's OAuth libraries. Authalla speaks standard OAuth 2.1 and OpenID Connect, with published discovery and keys, so there is no proprietary SDK.

To start from working code, clone the Next.js starter. Or connect your coding agent to our MCP server and ask it to add sign-in to your app in whatever stack you use.

With a passkey by default, and with a link or a code sent to their email as the fallback when a device can't use a passkey. There are no passwords at all.

You can also turn on social sign-in, such as Google, GitHub and Microsoft, and connect your business customers' own identity providers. Each tenant chooses its own methods, and the sign-in pages carry your logo and colours.

They type their email address and sign in with a passkey: the fingerprint, face or PIN that unlocks their phone or laptop. The first time, or on a device without a passkey, they get a link or a code by email instead, and can create a passkey from there.

There are no passwords in Authalla at all, so there is nothing to forget, reset, reuse or leak.

They sign in with a link or a code sent to their email, as on any new device, and create a new passkey there. Nobody has to reset anything for them.

You can remove the lost device's passkey from the user's page in the dashboard, and Sign out everywhere ends every session and app access the user had. This relies on email sign-in being on for the tenant, which it is unless you turn it off.

Passkey sign-in is multi-factor by design: possession of your device plus the biometric or PIN that unlocks it (NIST SP 800-63B-4, AAL2). There is no separate second factor such as an authenticator app or an SMS code.

No factor we offer is a password. An emailed code on its own, the fallback for devices without a passkey, is a single factor. Why we think "how many factors" is the wrong question: our article.

Yes: Google, GitHub, Microsoft personal accounts, Facebook, LinkedIn, X and Discord. You create the sign-in credentials in the provider's own console, such as Google Cloud, and paste them into the tenant; the dashboard shows the address to register there.

A user who signs in with Google and later by email with the same address is the same user. Work accounts on Microsoft Entra ID, Okta or Google Workspace connect as a business customer's identity provider instead. See SSO connections.

Yes. Add each business customer as an organization and connect its identity provider, such as Microsoft Entra ID, Okta or Google Workspace, over OIDC or SAML. Their staff sign in through it when they type an email address on the customer's domain.

You don't have to do the setup yourself: send the customer's IT admin a link to a setup page where they configure and test the connection. This is in every plan, with no fee per connection. See organizations.

Not once you have set it up. The sign-in pages and emails carry your logo, colours and product name, there is no "Powered by" line, and with a custom domain and a sender address of your own, the addresses are yours too.

Until then, the pages show the Authalla logo and the emails come from noreply@authalla-mail.com under your product name. See branding and sender addresses.

Yes. Turn off Allow user registration on the tenant, and only users you have created can sign in. Create them in the dashboard, through the Application API or your coding agent, or have a business customer's identity provider send them through SCIM.

Creating a user sends no email; once you tell them, they sign in with their email address. With registration on, which is the default, anyone can sign up.

English, Finnish and Swedish, for both the sign-in pages and the emails. Your app can ask for a language when it sends the user to sign in; otherwise the tenant's default language is used, then the browser's.

Yes. The dashboard's Activity page lists every sign-in, failed sign-in and sign-out, with the app and the sign-in method, and every change to your configuration with who made it. Sign-in events are kept for 90 days and configuration changes for a year.

See audit logs.

From the tokens. After sign-in your app gets an ID token that says who signed in, and an access token to send to your API. Your API checks the access token's signature against the tenant's published keys, which any JWT library does, and reads the user's ID from its sub claim.

The user's ID never changes, so it is the key to use in your own database. Sessions & tokens lists every claim.

For your own data, yes. Authalla keeps who a user is and how they sign in: their email address, name and sign-in methods. Everything your product knows about them, such as their plan, settings or what they own, stays in your database, keyed by the user's ID from the token.

Authalla doesn't store custom attributes on users. To put your own data in the tokens, such as a role or a customer ID, the Sign-in hook calls your endpoint at each sign-in and adds what it returns.

Authalla tells your app who the user is; your app decides what they may do. Most products keep roles in their own database, keyed by the user's ID.

When you want them in the tokens instead, there are three ways. The Sign-in hook adds data from your own system, such as a role, to the tokens under one Authalla claim. Your API can be registered as a resource server whose scopes, such as invoices:read, you grant to users one by one or to everyone. And users who sign in through a business customer's identity provider carry that customer's organization ID in their tokens.

Access and ID tokens last 15 minutes. An app that asks for the offline_access scope also gets a refresh token, which renews them without the user noticing and lasts 30 days from its last use. Each tenant can change all three.

To sign a user out, send them to the tenant's logout endpoint, which your OpenID Connect library finds on its own. To end every session and every app's access for a user at once, for example when a device is stolen, use Sign out everywhere in the dashboard or the API. See revoke access.

Authalla doesn't send event webhooks. The usual way is simpler: when your app sees a user ID it hasn't seen before, that is a new user, and it creates its own record then.

To run your own code during every sign-in, before the app gets its tokens, use the Sign-in hook.

Yes. Create them through the Application API, one at a time, or in batches of up to 1,000 through SCIM. There are no passwords to move: on their first sign-in, users enter their email address, get a code or a link, and can then create a passkey.

Creating a user sends no email, so tell your users about the change yourself. Each user gets a new Authalla ID, which the Application API returns when it creates them, so store it next to your own ID for that user.

From your coding agent. Add Authalla's MCP server to Claude Code, Codex, VS Code or Zed, then open the sign-in link it gives you and name your account: that is the whole sign-up. Ask it to add sign-in to your app, and it creates the tenant and the app and writes the code for your stack.

In Claude Code, for example:

claude mcp add --transport http authalla https://api.authalla.com/mcp

Then, in your project:

Add Authalla sign-in to this app. Create a Development tenant
and an app for http://localhost:3000.

Adding the Authalla agent skill (npx skills add authalla/agent-skills) gives the agent our integration guide as well. The setup for the other agents is at the top of the home page, and you can also sign up in the dashboard and do it by hand.

Every account starts with a three-month free trial of the whole product, with no user limit and no credit card. After the trial, every plan has every feature; see pricing.

Authalla is a Finnish company with no US parent, and your users' identity data is stored on EU-owned servers in Finland.

Sign-in emails are sent through Brevo, a French company that stores data on its own servers and on Google Cloud in Belgium. The European page lists every company involved and where each one sits.

Your apps speak standard OAuth 2.1 and OpenID Connect, so moving them to another provider means changing configuration, not code. Your users and everything you configured, apart from secrets, can be exported through our APIs, and there are no passwords to migrate.

Passkeys don't move: at the new provider, users sign in another way first and create new ones. Using your own sign-in domain from the start keeps the addresses your apps and identity providers point at yours. The Leaving Authalla guide walks through the move and lists what doesn't come with you.