Google Sign-In configuration

A Google button on the sign-in page. People use the account they already have, you stop managing passwords, and leavers lose access when their Google account is disabled rather than when somebody remembers to lock them here. New accounts can be created automatically for the email domains you name.

Creating the credentials on Google's side is covered in the Google Sign-In integration guide.

On RedminePRO Cloud

Availability

Plus and above.

Get a Client ID and secret from Google

You need a Google Cloud project you can edit. The Client ID and Client secret come from an OAuth client of type Web application whose redirect URI is the Authorized redirect URI the settings page shows. The integration guide has the step by step.

Turn it on

Administration → Plugins → RedminePRO Google Sign-In. Paste the Client ID from your Google credentials and press Apply. Then, next to Client secret, choose Change, paste the secret and press Save client secret. The secret has no field on the settings page itself, and Change opens another page, so press Apply first or an unsaved Client ID is lost. The button appears on the sign-in page, and Test configuration works, only once both are stored.

Permissions

None of its own. This decides how people prove who they are; what they may do afterwards is governed by their roles exactly as before.

Settings

Administration → Plugins → RedminePRO Google Sign-In:

Test configuration checks connectivity by fetching Google's configuration and signing keys. Nobody is signed in by it and no secret is written to a log.

Allowed email domains is the control that matters. Leaving it blank is the safe default: sign-in works for people who already have an account, and nobody new is created. Naming a domain means anyone at that domain who reaches your sign-in page gets an account.

Before turning on Force Google sign-in (SSO-only), sign in with Google yourself and confirm it works. Administrators keep a password route as a break-glass path, but everyone else loses theirs the moment it is on.

Using it

1. A person opens the sign-in page and chooses the Google button.
2. Google asks them to approve, once.
3. They arrive signed in. If Auto-link by verified email matched an existing account, it is that account, not a second one.
4. Otherwise, if their domain is listed, an account is created and joins Default groups for new users.

Troubleshooting

Google reports a redirect mismatch. The value in Google differs from Authorized redirect URI on the settings page, which shows the exact string to paste. A trailing slash or the wrong protocol is enough to break it.

Google says "Access blocked: [your domain or app name] has not completed the Google verification process", Error 403: access_denied. Usually the app's audience is External, it is still in Testing, and the person signing in is not one of its test users. Add them under Audience → Test users in Google Auth Platform, or publish the app with Publish app on the same page.

Sign-in succeeds but no account exists. Allowed email domains does not include their domain, and nothing is created automatically. Add the domain, or create the account first.

Someone ended up with a second account. Auto-link by verified email was off, or the existing account's email differs from their Google address, or that account is locked. Linking only attaches to an active one.

Nobody can sign in after enabling SSO-only. Administrators keep a password route as a break-glass path; use it and turn the setting off. This is why it should only be enabled after a successful Google sign-in.

No client secret stored yet. The secret was never saved: Apply saves the other settings but never the secret. Choose Change next to Client secret, paste the secret and press Save client secret. It is stored encrypted and never displayed. Once one is stored, the settings page says so in place of this message.

Connecting Google Cloud Console

You create one OAuth client in Google Cloud Console and paste two values into the workspace. The workspace shows you the exact redirect address to register, so nothing has to be typed twice. The workspace asks Google for basic profile information only: who signed in, their verified email address, their name and their profile picture.

On RedminePRO Cloud

The feature is preinstalled. Start at the next section.

On your own Redmine

Install the feature first, see the Google Sign-In configuration page, then follow the same steps. Your workspace must be reachable over HTTPS at a hostname Google can redirect back to.

Before you start

• An administrator account on the workspace.
• A Google Cloud project you can create credentials in, and the rights to edit its consent screen.
• Decide which email domains, if any, should get accounts created automatically.

On the external side

1. Open Google Cloud Console. Create a project or pick one.

2. Open Google Auth Platform, which older guides call the OAuth consent screen. On a project that has never used it, choose Get Started. Enter the App name and a User support email. Then choose the audience: Internal if everyone who signs in is in your Google Workspace and the project belongs to its organisation, External otherwise. Add a contact email address, agree to the Google API Services: User Data Policy, and create it.

3. In Google Auth Platform, open Clients, then Create client. Set Application type to "Web application" and give the client a name you will recognise later. Older guides send you to APIs & Services → Credentials for this.

4. Under Authorized redirect URIs, choose Add URI and paste the exact value the settings page shows as Authorized redirect URI. It is https://<your-workspace-host>/auth/google/callback and must match character for character: a trailing slash, or http in place of https, is enough to break it. Authorized JavaScript origins is not needed. On your own Redmine, if the value starts with http:// or names the wrong host, first set Protocol to HTTPS and Host name and path to your public host under Administration → Settings → General.

5. Choose Create. Copy the Client ID and Client secret from the "OAuth client created" dialog. The secret is shown once. Afterwards Google shows only its last four characters, and a lost secret is replaced with Add Secret on the client's page.

6. In Redmine: Administration → Plugins → RedminePRO Google Sign-In. Paste the Client ID, set Allowed email domains only if new accounts should be created automatically, and press Apply. Next to Client secret, choose Change, paste the secret and press Save client secret. Then press Test configuration. The next section covers the other settings.

7. External audience only: while the app's Publishing status is Testing, Google can refuse anyone who is not a listed test user. Before rolling out, choose Publish app on the Audience page, or, for a small pilot, add each person under Test users with Add users (Google allows up to 100). The workspace asks Google only for basic identity: openid, email and profile. None of them is a sensitive scope, so Google asks for no verification review before you publish.

In RedminePRO

1. Administration → Plugins → RedminePRO Google Sign-In.
2. Paste the Client ID and press Apply. Then choose Change next to Client secret, paste the secret and press Save client secret. The secret is stored encrypted and never displayed again: the settings page shows only whether one is stored.
3. Press Test configuration. It fetches Google's configuration and signing keys to prove the workspace can reach them. Nobody is signed in by it and no secret is logged.
4. Set Allowed email domains if you want accounts created automatically. Leaving it blank is the safe default: sign-in works for people who already have an account and nobody new is created.
5. Optionally pick Default groups for new users.
6. Leave Force Google sign-in (SSO-only) off until you have signed in with Google yourself at least once.

Verify it works

Sign out, open the sign-in page, and use the Google button with your own account. You should arrive signed in as your existing account rather than a new one. That is Auto-link by verified email doing its job.

Then, before turning on SSO-only, have one other person try it. SSO-only removes the password form for everyone except administrators, and the time to discover a misconfiguration is before that, not after.

What is stored

In the workspace's settings, the Client ID and the Client secret, the second encrypted at rest and never written to a log.

Against each account linked to Google, one record holding:

• Google's permanent identifier for the person. Every later sign-in matches on it.
• Their Google email address at the time of linking.
• The address of their Google profile picture, refreshed at each Google sign-in. My account shows the picture under Connected sign-in. The image is loaded from Google each time and never copied.
• When the link was made, and when they last signed in with Google.

Disconnect on My account deletes the record.

An account created automatically is filled from Google once: its login and email are the Google address, and its first and last name are the name on the Google profile. Linking an existing account copies nothing onto it, and no later sign-in changes an account's name or email.

Nothing else. No Google password ever reaches the workspace, no token is kept after sign-in, and nothing is requested beyond the openid, email and profile scopes.

Troubleshooting