Connected app credentials

Registering your own Google or Microsoft application, so people can sign in with one click.

Settings → App credentials.

To let anyone sign in with Google or Microsoft, your organisation registers its own application with that provider and puts the client id here. This is done once.

It is your application rather than ours on purpose: the consent screen names the application a person is trusting with their mail, and a shared client id would route every customer's mailbox through one project with one quota and one revocation switch.

The redirect URI is shown on the screen with a copy button. Paste it into the provider exactly — scheme, host, port and no trailing slash. A mismatch here is the commonest cause of a connection that fails at the last step.

Google: create an OAuth client of type "Web application" in Google Cloud Console, and enable the Gmail API and the Google Calendar API. While the consent screen is in Testing, only accounts listed as test users can connect.

Microsoft: register an application in Microsoft Entra ID, add the redirect URI as a Web platform, and grant the delegated Microsoft Graph permissions. Some tenants require an administrator to consent before anyone can connect. Note that Microsoft client secrets expire — a connection that stops working months later is usually an expired secret rather than anything you changed.

The client secret goes into the encrypted store and is never shown again or returned by any screen.