Applications

An application is one of your own apps that people sign in to. Register each one under Applications in the dashboard. Each gets a client ID, and web apps also get a client secret.

Apps that other people build, such as AI clients, don't go here. They identify themselves when they connect, and you see them next door, under Applications, Apps people connect. See apps people connect.

Types

Type	Use it for	Secret
Web	Apps with a server, such as FastAPI with UserAuth. The server keeps the tokens	Yes. The app authenticates with it at the token endpoint
Single page	Browser apps with no server of their own	No. PKCE protects the code instead
Native	Mobile and desktop apps, and command line tools	No. PKCE protects the code instead

Every type uses the authorization code flow with PKCE. There is no implicit flow and no password grant.

If your browser app has a backend, register it as a web app and let the backend hold the tokens. That keeps tokens out of browser JavaScript, and it's the only kind of app that can get the scope for managing API keys.

Redirect URIs

After sign in, MicroAuth sends the browser back to one of the app's redirect URIs. The URI in the request must match a registered one exactly, character for character.

• Use https. Plain http only works on localhost, 127.0.0.1 and [::1], for development.
• No wildcards, no fragments (#...) and no user names. Write the scheme in lowercase.
• Native apps may also use a custom scheme. A reverse domain name you control, such as com.example.app:/callback, is the safest choice, but any valid lowercase scheme works, such as myapp:/callback. Reserved schemes such as javascript, data, file and mailto are refused.
• For native apps, http://localhost, http://127.0.0.1 and http://[::1] redirects match on any port, as long as the rest is identical, because a command line tool picks a free port each time.
• An app can have up to 20 redirect URIs.

With UserAuth, the redirect URI is your app's URL followed by /auth/callback, such as https://app.example.com/auth/callback.

A request with an unknown client ID or redirect URI shows an error page on your sign in service. It never redirects, so nobody can use your sign in pages to send people to another site.

Sign out URLs

When your app signs someone out, it can ask MicroAuth to send them back to one of its sign out URLs. With a registered URL and the person's ID token, sign out happens right away. Otherwise the person confirms on a MicroAuth page first. UserAuth sends people to your app URL followed by after_sign_out, which is / by default. An app can have up to 20 sign out URLs.

Client secrets

A web app's secret is shown once, when you create the app. Keep it on your server. Rotate secret issues a new one, and the old one keeps working for 24 hours so you can deploy the new one without downtime. Rotating again ends any older secret at once.

Refresh tokens

Each app has a switch for refresh tokens. It's on for new apps, and turning it off ends the app's refresh tokens at once. With it on:

• The app gets a refresh token tied to the person's sign in session. Signing out ends it.
• An app that asks for offline_access gets a refresh token tied to its grant instead. It survives sign out and ends when the person disconnects the app. It expires after 30 days without use, and after a year at most.

Refresh tokens change on every use. See Sessions and tokens.

Consent screen

Your own apps don't show a consent screen by default, because people already trust them. For a partner app that you register yourself, turn on the consent screen so people see what it asks for before it gets access. Once someone allows it, it shows up under their Account, Connected apps, where they can disconnect it. Apps without the consent screen don't appear there.

Limits

How many applications a service can have depends on its plan, up to 100. See pricing.

Deleting an application stops its refresh tokens at once. Access tokens it already got keep working until they expire, 10 minutes by default.