Apps people connect

Your own applications are registered by you. Apps people connect are the opposite: AI clients, assistants and tools that someone else built. They identify themselves when they first connect, and each person decides whether to let them in.

Turn them on under Sign in. Plans that include them are on the pricing page. While they're off, only your registered applications can get tokens, and apps people already connected can't refresh theirs either.

Your discovery document is cached for up to an hour, so after you turn them on or off, clients may see the old setting for that long.

How apps identify themselves

• Client ID Metadata Documents are the way MCP clients identify themselves. The app's client_id is the URL of a JSON document it hosts, with its name and redirect URIs, so the consent screen can show where the app really comes from. See the document rules.
• Dynamic client registration is kept for older clients. The app registers itself and gets a client ID. See registration.

Anyone can publish a document or register an app, so MicroAuth labels both kinds unverified. Neither kind gets a client secret, and neither can ask for the roles scope or the scope for managing API keys. A scope they can't have is dropped from the request rather than refused.

Apps people connect that nobody has used for 30 days are removed, unless a person still has a working refresh token for them. Blocked apps are kept, so the block holds.

The consent screen

Before an app gets anything, the person sees:

• the app's name and the account they're signed in as, with Use another account, which signs them out of your sign in pages and brings them back to the same request so they can sign in as someone else;
• for an app known by its metadata document, the host of its client_id;
• where this request sends them back to: a warning when that is their own computer (localhost), as command line tools do, a note that it returns to an app on this device when it's a custom scheme, or the host otherwise;
• an unverified label on every app people connect;
• your API or MCP server, and each permission in plain words, using the descriptions you wrote. A permission without a description shows its name as written, such as docs:share, so describe every permission these apps can ask for. Sensitive permissions are highlighted.

App logos and links aren't shown. Each app appears with the first letter of its name.

The app only gets permissions the person holds and approved. The consent page stays open for 15 minutes. An app that asks with prompt=none before the person approved it gets consent_required.

Your own applications with the consent screen turned on show the same screen, marked as an app by your service and without the unverified label.

Asking for more later

When a tool needs a permission the app doesn't have, your server answers 403 with insufficient_scope, and the app asks again. This time the consent screen shows only the new permissions, and they join what the person already approved. Asking again with prompt=consent shows everything.

Each app can show a person the consent screen 10 times an hour. After that it gets access_denied, so an app can't wear someone down by asking over and over.

Taking access away

• People see the apps they've allowed under Account, Connected apps: each app's name and first letter, the unverified label, where it comes from, what it can do, when they allowed it and when it was last used. They can disconnect any of them after confirming. The list has every app that went through the consent screen. Your own applications without the consent screen don't appear there. While apps people connect are off, the page says unverified apps can't use the account for now, and a blocked app is marked Blocked.
• You see grants per person on their page under Users, and per app under Applications, Apps people connect, with where each app says it comes from and how many people use it. You can disconnect an app from one person, or block it for everyone on your service from its page.

After a disconnect, the app's refresh tokens stop working right away. Access tokens it already has keep working until they expire. Access tokens for apps people connect last at most 10 minutes, even when your service's access token lifetime is longer.

Connected apps get refresh tokens tied to their grant, so they keep working after the person signs out of your sign in pages. They expire after 30 days without use, and after a year at most. An app only gets refresh tokens when it lists refresh_token in its grant_types.

Block an app

Blocking an app stops it signing anyone in or refreshing tokens on your service. Access tokens it already has keep working until they expire, 10 minutes at most. An app known by its metadata document stays blocked when its document changes.

People keep their grants while an app is blocked, so unblocking it brings their access back without asking them again. To take access away for good, disconnect it from each person instead.

Activity

The Activity tab records apps being allowed, permissions being added, consent being declined, apps being disconnected, blocked and unblocked, registrations, and refresh tokens being reused. Tokens and secrets are never logged.