Skip to main content

Google Calendar Integration: Setup and Security Overview

Technical guide for IT and security teams on Bliro's Google Calendar integration: authentication model, OAuth scopes with justifications, and tool-level permissions.

Written by Martin Thoma

This guide is for IT and security teams evaluating Bliro's integration with Google Calendar. It covers the authentication model, the permissions Bliro requests during consent, and how Bliro enforces tool-level permissions through its AI agents.

Overview

Bliro connects to Google Calendar using user-delegated OAuth 2.0 against Google's OAuth 2.0 service. Bliro acts on behalf of the signed-in user and cannot perform any action in Google Calendar that the user themselves is not permitted to perform. The integration is delivered through Bliro's registered Google OAuth application, which has been verified by Google.

  • App name: Bliro

  • Publisher: bliro GmbH

  • Verification: Google-verified – the app's branding and scope use have been reviewed and approved by Google

How the Integration Works

When a user connects Google Calendar in Bliro, the following happens:

  1. Bliro initiates an OAuth 2.0 authorization request against accounts.google.com.

  2. The user signs in with their Google account and approves the requested scopes on Google's consent screen.

  3. Google issues an access token and a refresh token bound to the signed-in user.

  4. Bliro uses the access token to call the Google Calendar and Google People APIs on behalf of that user.

  5. When the access token expires, Bliro silently refreshes it using the refresh token until the user disconnects or an administrator revokes access.

All Google requests are scoped to the user's own identity and Google account permissions. Bliro never holds an application-level (service-account) credential against your Google Workspace.

Prerequisites

  • The user has a valid Google account with access to Google Calendar (Google Workspace or personal Google account).

  • (Workspace customers) Your Google Workspace admin permits the Bliro OAuth app under Security → API Controls → App access control. If your Workspace restricts which OAuth apps can be authorized, an administrator must permit the Bliro app before users can complete the OAuth flow.

  • The user is signed in to Bliro.

Setup: Connecting Bliro to Google Calendar

  1. In Bliro, open Integrations and select Google Calendar.

  2. Click Connect. Bliro redirects you to the Google sign-in page (accounts.google.com).

  3. Choose the Google account whose calendar you want to connect.

  4. Review the Google consent screen and click Continue. The requested permissions are listed in detail in the next section.

  5. Bliro redirects you back to the integration page.

  6. Configure the Tools & Permissions that Bliro is allowed to use on your behalf.

Requested Permissions (OAuth Scopes)

During consent, Bliro requests exactly the following eight scopes for the Google Calendar integration. Each is listed below with its purpose and justification.

Scope

Justification

openid

Standard OpenID Connect scope. Required to comply with current authentication standards and to identify the user when connecting to Google Services.

.../auth/userinfo.email

Provides the user's primary Google account email address, used as the unique identifier linking the Google account to the Bliro user account.

.../auth/userinfo.profile

Provides the user's name and basic profile information (display name, profile photo, locale). Used to personalize the Bliro UI and to identify the user in audit logs and CRM attribution.

.../auth/contacts.readonly

Reads the user's saved Google Contacts so the assistant can resolve names mentioned in voice commands to the correct email address. Read-only – Bliro does not create or modify contacts in Google Contacts.

.../auth/contacts.other.readonly

Reads "Other contacts" – people the user has emailed or interacted with but has not explicitly saved as a contact. Without this scope, the assistant would frequently fail to resolve a name to an email address even though the user has clearly corresponded with that person before. Read-only.

.../auth/directory.readonly

Reads the Google Workspace directory for the user's own organization. Required when the user wants to schedule an internal handover meeting. Access is limited to basic directory information already visible to the user within the Workspace admin-configured directory; it does not include calendar contents of colleagues. Read-only.

.../auth/calendar

Reads upcoming events and creates, updates, or cancels follow-up meetings. Write access is required because creating a follow-up meeting after a customer visit is one of the core workflows Bliro automates. Bliro requests this single broader scope rather than combining multiple narrower scopes in order to keep the consent screen concise and to reduce administrative complexity.

.../auth/calendar.settings.readonly

Reads the user's calendar settings (default timezone, working hours, etc.) – essential for correct scheduling logic. Read-only; Bliro never modifies these settings.

Tools and Permissions

Even with the Google scopes granted, Bliro does not perform any Google Calendar operation by default. Each individual action Bliro can take is modeled as a tool with its own permission level (Always Allow, Ask for Permission, or Deny), configured by an organization administrator.

Bliro currently ships a fixed set of predefined tools for Google Calendar covering event search, event creation, and contact search. Custom tool creation is not yet available for calendar integrations; only the predefined tools shipped with the integration can be enabled or disabled.

For a full explanation of the tool model, permission levels, the Ask for Permission flow, and how Bliro enforces denied tools, see AI Tools and Permissions.

Security Considerations

  • User-delegated only. Bliro never holds a service-account or application-level credential against your Google Workspace. Every API call is authenticated as the user, and Google applies that user's account permissions on each request.

  • Token storage. Refresh tokens are stored encrypted at rest. Access tokens are short-lived and held only for the duration of an operation.

  • Auditability in Google Workspace. OAuth token grants and revocations, as well as token use, are reflected in Google Workspace Admin audit logs (Reports → Audit and investigation → OAuth log events / Token log events), where Workspace customers can review activity through native Google tooling.

  • Workspace policies. Any context-aware access, MFA, or session policy your Google Workspace admin enforces applies equally to Bliro's calls.

Disconnecting and Revoking Access

Users can disconnect Google Calendar at any time from the integration screen in Bliro by clicking Disconnect. This deletes the refresh token from Bliro's side and ends Bliro's ability to call Google on the user's behalf.

In addition, the user can revoke Bliro's access directly in Google under https://myaccount.google.com/permissions → Bliro → Remove access. Google Workspace admins can revoke or block the Bliro app organization-wide via the Admin Console under Security → API Controls → App access control.

IT Security Material

For Bliro's broader approach to security and privacy, see our Trust Center.

Contact and Help

Questions about the Google Calendar integration, scope justifications, or central administration? Contact [email protected].

Did this answer your question?