The Hidden Risks of OAuth Calendar Access

You clicked "Allow." Now what?

Every time you connect a calendar app through Google or Microsoft, you go through an OAuth flow. A screen asks if you want to grant the app permission to access your calendar. You click "Allow" because that is the whole point. But what you actually authorized is worth understanding.

OAuth tokens typically grant broad access. Depending on the scopes the app requested, it may be able to read every event on your calendar, including attendee lists, event descriptions, locations, and conference links. Some apps request write access too, meaning they can create, modify, or delete events on your behalf. The permission screen tells you this, but be honest: you skimmed it.

What the app can see (and store)

Once an app has an OAuth token, it can pull your calendar data to its own servers. That is the entire mechanism. Your events, your attendees, your meeting titles, your private notes in event descriptions. All of it flows to a third-party server where it is stored, indexed, and processed according to that company's privacy policy.

For contractors and consultants managing multiple client calendars, this is especially dangerous. Your calendar contains the names of every company you work with, the people you meet with, and often the projects you are working on. A single OAuth connection can expose your entire client roster to a third party.

Most calendar apps store this data indefinitely. Even after you stop using the app, your historical calendar data may persist on their servers. Some apps share aggregated or anonymized data with partners. Some have been caught sharing more than that.

What happens if the app is compromised

Data breaches happen to well-funded companies with dedicated security teams. They will happen to smaller calendar startups too. When an app that holds your OAuth token is breached, the attacker gets access to everything the token allows. That means your calendar data, your attendee lists, and potentially the ability to create or modify events on your calendar.

Token revocation is not instant. When a breach is discovered (often weeks or months after it occurs), you can revoke the app's access from your Google or Microsoft account settings. But between the breach and your revocation, the token was live. And if the app cached your data on its servers, revoking the token does not delete what was already copied.

There is also the supply chain risk. OAuth apps often depend on third-party libraries and services. A vulnerability in any of those dependencies can expose your data even if the app itself was built responsibly.

The scopes problem

OAuth scopes are supposed to limit what an app can do. In practice, most calendar apps request the broadest scopes available because it is easier to develop against. Google's Calendar API has granular scopes, but the most commonly requested one, calendar.readonly, grants access to every calendar and every event in the account. Not just the calendar you wanted to connect. All of them.

Microsoft's Graph API has a similar pattern. The Calendars.Read permission grants access to all calendars in the mailbox. If you have a shared calendar from a colleague, the app can read that too.

You cannot selectively grant access to one calendar through OAuth. It is all or nothing. That is a fundamental design limitation, not a bug that will get fixed.

The safest OAuth token is the one you never issue

The only way to eliminate OAuth risk entirely is to not use OAuth. That sounds obvious, but it rules out most calendar aggregation tools on the market. They need server-side access to your calendar data because their architecture requires it. Sync engines, AI features, cross-device push notifications: all of these need a server, and a server needs a token.

manyCalendars takes a different approach. It reads your calendar data directly from the browser tabs you already have open. No OAuth tokens. No server-side data storage. No API calls on your behalf. Your calendar data stays in your browser and never touches our infrastructure.

You can also import calendars via ICS feeds, which are read-only by design and do not grant any write access. No token to steal, no scope to abuse, no server to breach.

If you are a consultant juggling calendars across multiple client organizations, the question is simple: do you want your calendar data on someone else's server, protected by their security practices? Or do you want it to never leave your machine in the first place? Try manyCalendars free and keep your tokens to yourself.