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
Section titled “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
Section titled “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?).
Apple iCloud / KSuite (CalDAV)
Section titled “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
Section titled “iCal feeds”The feed URL (incl. its embedded token) is treated like a password and stored encrypted. Feeds are read-only.
Why write access?
Section titled “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
Section titled “Ending access”Every connection can be disconnected in Kalender Sync and additionally revoked directly at the provider — the links are in the overview table there.