Google Sign-In for EspoCRM: Follow the Identity All the Way Back

A successful Google login doesn’t automatically tell EspoCRM which local user to open or which records that user may access. Those are separate steps in the integration.

We’ll follow a test sign-in from the browser to the identity provider and back, then verify the permissions inside the application.

Name the protocol’s job

OAuth 2.0 provides an authorization framework. OpenID Connect, or OIDC, adds an identity layer used for sign-in. The browser moves through redirects while the application validates the resulting identity information.

In the diagram, the provider authenticates the person. The app callback handles the return. EspoCRM then establishes its own application session and applies its permissions.

Work through a fictional callback

Suppose a staging application displays this redirect URI:

https://crm.example.test/oidc-callback

This is a teaching example, not an EspoCRM default. Copy the actual Authorization Redirect URI shown by your installation. Register it exactly with the provider. Scheme, hostname, path, and any required trailing slash are part of the agreement.

If the registered address is https://crm.example.test/oidc-callback but the application sends an HTTP address, the provider should reject the mismatch. Adding a broader permission to the user doesn’t fix that disagreement.

Connect the two configurations

In the Google project, configure the consent and test-user settings appropriate to your environment, then create an OAuth client for a web application. Use the exact callback copied from EspoCRM. Keep the client secret in the application’s protected configuration.

In EspoCRM, choose OIDC under Administration > Authentication. Supply the client ID, secret, and required provider endpoints, then save. Use the EspoCRM OIDC guide for the fields supported by your version.

Google publishes its provider metadata at:

https://accounts.google.com/.well-known/openid-configuration

Consult those metadata and the Google OIDC documentation for endpoint values. Don’t construct a token URL by joining unrelated base URLs and paths. If the application needs manually entered endpoints, copy the matching values into the appropriate fields.

The Google integration used for calendar or mail synchronization is a different feature from sign-in. Configure the authentication flow you intend to test.

Verify identity mapping before broad rollout

Decide how an accepted provider identity maps to a CRM user, whether new accounts can be created, and what permissions a new account receives. Confirm those settings in your EspoCRM version instead of assuming an email match grants the right access.

Use a test identity with limited CRM permissions. Verify three things separately: the sign-in succeeds, the expected CRM identity is active, and an operation outside that identity’s role is denied.

Avoid copying tokens, authorization codes, or client secrets into diagnostic screenshots. A correlation identifier and the failure stage are usually better starting points for an investigation.

Practice a failure and a return visit

Use a private browser session to repeat the first-time flow. Then test a normal returning session and logout. Document whether logging out of the CRM also affects the provider session. A fresh browser session and an existing application session exercise different paths.

Remove temporary test access when finished. You are ready to expand the integration when you can explain the callback, identity mapping, application permission, and recovery path independently.