# Permissions in detail

Kalender Sync only requests what syncing requires — and none of it grants access to emails, files or contacts. Here's the full breakdown, e.g. for IT reviews.

## Google Calendar

| Scope | Purpose |
| --- | --- |
| `openid`, `profile`, `email` | Authentication — who is signed in |
| `calendar.events` | Read + write calendar entries (for the busy blockers) |
| `calendar.calendarlist.readonly` | Fetch the list of available calendars |

Google uses incremental consent — the checkboxes in the consent dialog should stay ticked, otherwise sync can't create blockers.

## Microsoft 365 / Outlook

| Scope | Purpose |
| --- | --- |
| `User.Read` | Authentication — who is signed in |
| `Calendars.ReadWrite` | Read + write calendar entries (for the busy blockers) |
| `offline_access` | Refresh token so sync runs in the background without re-login |

No admin consent required — except in strictly configured tenants ([what then?](https://docs.kalender-sync.de/en/connect-calendar/org-blocked/)).

## Apple iCloud / KSuite (CalDAV)

| Mechanism | Purpose |
| --- | --- |
| App-specific password | A dedicated password per connection, separate from the iCloud/KSuite identity |
| CalDAV `REPORT` / `PROPFIND` | Standard CalDAV operations for reading + writing |

No OAuth — app passwords are revocable at the provider any time and grant no access to other services of the account.

## iCal feeds

The feed URL (incl. its embedded token) is treated like a password and **stored encrypted**. Feeds are read-only.

## Why write access?

Kalender Sync creates its own blocker events in the target calendar, updates them and cleans them up on ending — that requires write permission. Your **original events are never modified**; only the self-created blockers are touched.

## Ending access

Every connection can be [disconnected](https://docs.kalender-sync.de/en/connect-calendar/disconnect/) in Kalender Sync and additionally revoked directly at the provider — the links are in the overview table there.