# Sign in with Apple vs iCloud Data Authorization

Canonical: https://figment.so/blog/apple-sign-in-vs-icloud-data

Sign in with Apple authenticates who your user is — it does not open any iCloud data to your app. Getting iCloud data access requires a separate authorization, and Apple limits that authorization to Mail, Calendar, and Contacts in approved third-party apps. Everything else — iMessage, Photos, Notes, Drive — sits outside both mechanisms entirely.

## The core distinction: identity versus data

Apple runs authentication and data access on completely separate tracks.

**Sign in with Apple** is an identity provider. The user proves ownership of an Apple ID. Your app learns a stable identifier, an optional email address, and a signal about whether the account looks real. No data stores are involved.

**Apple's native iCloud data authorization** is a distinct consent flow for approved third-party apps that need to read or write iCloud Mail, Calendar, or Contacts. It operates at the account level, requires Apple's approval to offer, and covers exactly those three services. Developers can apply at [developer.apple.com/contact/request/icloud-oauth2/](https://developer.apple.com/contact/request/icloud-oauth2/) (login required; enrollment and approval terms apply).

Using Sign in with Apple does not enroll your app in iCloud data authorization. The two systems share no scope, no consent surface, and no grant mechanism.

## What Sign in with Apple grants

Sign in with Apple exposes two optional scopes and two values every authorization returns:

- **Stable user identifier.** An opaque string unique to this user on your developer team. Consistent across sessions; not shared across developer teams without user consent.
- **Real User Indicator.** A three-state signal (`likelyReal`, `unknown`, `unsupported`) that Apple derives from account activity and device history.
- **`email` scope** — The user's Apple ID email or a randomized Hide My Email relay address the user controls. The relay forwards to their real inbox; your app only sees the relay address.
- **`name` scope** — `givenName` and `familyName`. Returned only on the very first authorization. Subsequent logins omit it; store it at first use or it is gone.

That is the complete set. Sign in with Apple grants no access to mail content, calendar events, contacts, messages, photos, notes, files, or any iCloud data store.

## Apple's native iCloud data authorization: Mail, Calendar, Contacts

For supported third-party apps, Apple provides a separate account authorization ([support.apple.com/en-us/121539](https://support.apple.com/en-us/121539)) that covers exactly three iCloud services:

- **iCloud Mail** — IMAP and SMTP access
- **iCloud Calendar** — CalDAV access
- **iCloud Contacts** — CardDAV access

The user flow is straightforward: the app prompts the user to enter their Apple Account email, Apple displays an Allow dialog, and the user confirms. The user can revoke access at any time at **account.apple.com › Sign-In and Security › Account Data Sharing**.

Apps that only need Mail, Calendar, or Contacts access can use this authorization directly — no hosted Mac required. For apps without native support for Apple's account authorization, Apple also offers app-specific passwords ([support.apple.com/en-us/102654](https://support.apple.com/en-us/102654)). These are reusable per-app credentials — not one-time passwords — that let an app authenticate against an Apple Account. Up to 25 can be active at a time and are revoked automatically if you change your Apple ID password.

This authorization is not iCloud-wide. Photos, Notes, iCloud Drive, iMessage, Shortcuts, Safari tabs, Voice Memos, and every other Apple data surface are outside its documented scope.

## Identity versus data grant map

The table below maps each official mechanism against its documented scope, using Apple's publicly available information. The third column marks what neither system covers.

| Access dimension | Sign in with Apple | Apple iCloud native auth | Outside both |
|---|:---:|:---:|:---:|
| Stable user identifier | ✓ | — | — |
| Name (first authorization only) | ✓ | — | — |
| Email or Hide My Email relay | ✓ | — | — |
| Real User Indicator | ✓ | — | — |
| iCloud Mail (IMAP/SMTP) | — | ✓ | — |
| iCloud Calendar (CalDAV) | — | ✓ | — |
| iCloud Contacts (CardDAV) | — | ✓ | — |
| iMessage history and search | — | — | ✓ |
| iCloud Photos | — | — | ✓ |
| iCloud Notes | — | — | ✓ |
| iCloud Drive | — | — | ✓ |
| Safari tabs, Shortcuts, and more | — | — | ✓ |

The right-hand column is not a list of obscure edge cases. It includes iMessage — one of the most-requested Apple data surfaces for developer integrations — alongside Photos, Notes, and Drive.

## The gap: what neither system covers

Apple has no publicly documented general-purpose iMessage API for third-party apps. Neither Sign in with Apple nor the native iCloud data authorization grants access to message history, chat lists, or the ability to send messages.

The same is true for Photos, Notes, iCloud Drive, Find My locations, Home devices, Safari tabs, and Voice Memos. These services sync through iCloud, but reading or acting on them from a third-party app requires either native Mac entitlements or an intermediary that operates on a Mac the user has explicitly authorized.

This is a structural gap. The three-service iCloud authorization is the extent of what Apple has publicly documented for third-party app access. The rest of the iCloud ecosystem operates outside that boundary.

## How Figment Apple Connect bridges this

Figment is built to cover the gap. Its consent layer — described as "OAuth for iCloud" — lets a developer's app request scoped access to Apple data beyond the Mail/Calendar/Contacts trio. The developer app never receives the Apple password. Revoking one app's grant stops that grant without affecting other apps using the same connection.

For iMessage, Figment provides a [REST API](/imessage-api): read chat history, search messages, and send to existing authorized conversations. Live access requires account setup and approval; sandbox is free and uses synthetic data. Each service goes through its own connection status lifecycle — `needs_approval`, `syncing`, `ready`, `reconnect_required` — so your app knows the exact state before making a request. The API surfaces `historyComplete` and `hasMore` so your app handles partial results correctly rather than assuming complete coverage.

For Contacts, Calendar, and Reminders, a synthetic read-only sandbox is available; live customer access is not yet available.

For Photos, Notes, Drive, and other Apple data surfaces, Figment has no current public connector.

Developer access is **$29/month per active live connection**. Sandbox is free. Access starts after setup.

---

**Related reading:** [OAuth for iCloud: Connect Apple Data to Your App](/oauth-for-icloud) · [Figment iMessage API](/imessage-api) · [Figment vs BlueBubbles for iMessage Integration](/blog/figment-vs-bluebubbles) · [Figment vs AirMessage for App Integrations](/blog/figment-vs-airmessage) · [Figment vs Claw Messenger for iMessage Apps](/blog/figment-vs-claw-messenger)

[Connect Apple Account](/apple-connect/developers) to explore data-layer access beyond the identity tier.