For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /es/docs/web/apple-sign-in.md (or send Accept: text/markdown).
Añadir el inicio de sesión con Apple
Registra una App ID, una Services ID y una clave de Sign in with Apple en el portal de Apple Developer, y conecta después el par de cliente a la app.
Guía paso a paso para principiantes
Prerrequisitos: la app web corriendo en local (Lanza en 5 minutos), una base de datos migrada para cuentas reales (Configurar la base de datos) y una membresía del Apple Developer Program — la misma cuenta de 99 $ al año que crea la guía de cuentas móviles, así que completa ese paso antes de seguir si aún no lo has hecho. Todo lo del portal de desarrollador de abajo no cuesta nada extra.
Por qué importa: la revisión de la App Store exige Sign in with Apple siempre que una app iOS ofrezca inicio de sesión social de terceros como Google o GitHub, y también en la web es un botón sólido de baja fricción: los usuarios de Apple inician sesión con la cuenta que ya tienen en sus dispositivos.
Términos rápidos: una App ID es el identificador registrado de tu app (com.yourcompany.yourapp). Una Services ID es un segundo identificador que Apple emite para el inicio de sesión web y de servidor — esa se convierte en tu client ID. Una return URL es la dirección exacta a la que Apple puede devolver a un usuario que ya inició sesión — el callback de Better Auth del kit. Una secret key es el archivo .p8 que Apple te da una sola vez; tú mismo lo conviertes en el client secret.
1. Registra una App ID con la capacidad Sign in with Apple. 2. Registra una Services ID que apunte a ella y que contenga tu dominio más la return URL. 3. Crea una clave de Sign in with Apple y descarga el archivo .p8. 4. Convierte la clave en un JWT de client secret y configura los tres valores env.
Una limitación honesta: las return URL de Apple deben ser direcciones https:// absolutas en un dominio registrado — localhost y el http plano se rechazan, así que el botón no se puede probar del todo en un servidor local pelado. Verifica en tu URL desplegada, o expón el servidor local a través de un túnel https (por ejemplo cloudflared tunnel o ngrok) y registra el dominio del túnel más su callback mientras pruebas.
Registrar la App ID
1. Abre developer.apple.com/account e inicia sesión con la cuenta que tiene la membresía del Developer Program.
2. Abre Certificates, Identifiers & Profiles → Identifiers y haz clic en el botón azul +.
3. Selecciona App IDs → Continue, deja el tipo en App → Continue.
4. Description: el nombre de tu producto. Bundle ID: elige Explicit e introduce la forma de dominio inverso com.yourcompany.yourapp — si lanzas la app iOS, usa exactamente el ios.bundleIdentifier de apps/mobile/app.json para que ambas plataformas compartan una App ID.
5. En la lista de capacidades marca Sign in with Apple → Continue → Register.
Esperado: el identificador aparece en la lista de Identifiers con la capacidad Sign in with Apple activada. Reutiliza esta única App ID — la Services ID y la clave se le asocian a ambas como app primaria.
Registrar la Services ID y la return URL
1. De vuelta en Identifiers haz clic de nuevo en +, elige Services IDs → Continue.
2. Description: algo como yourapp web sign-in. Identifier: otro nombre de dominio inverso — la convención es com.yourcompany.yourapp.web — deliberadamente distinto de la App ID. Esta Services ID es el client ID que el servidor usa para el inicio de sesión web; cópiala exactamente y luego Continue → Register.
3. Selecciona la nueva Services ID en la lista, marca Sign in with Apple y haz clic en Configure.
4. En el diálogo pon Primary App ID en la App ID de la sección anterior. En Website URLs añade tu dominio (por ejemplo yourdomain.com), y en Return URLs añade https://yourdomain.com/api/auth/callback/apple — esa ruta es el callback de Better Auth del kit, {APP_URL}/api/auth/callback/apple. Save → Continue → Save.
Cada return URL debe ser una dirección https:// absoluta en un dominio registrado: localhost, las direcciones IP peladas y http se rechazan. Para desarrollo local ejecuta la app detrás de un túnel https, añade el dominio del túnel a la Services ID, registra https://<tunnel-domain>/api/auth/callback/apple y pon APP_URL en la URL del túnel mientras pruebas.
Esperado: la Services ID muestra Sign in with Apple → Enabled. Si el portal rechaza tu dominio, termina primero la verificación de titularidad del dominio en la página de la cuenta.
Crear la clave de Sign in with Apple
1. Abre Keys en la barra lateral izquierda → +. Ponle nombre a la clave (por ejemplo yourapp sign-in key), marca Sign in with Apple, haz clic en Configure, elige la App ID como Primary App ID → Save → Continue → Register.
2. En la pantalla de confirmación anota el Key ID y haz clic en Download — el archivo .p8 se ofrece una sola vez. Si lo pierdes, revoca la clave y crea otra; Apple no guarda copia.
3. Anota también tu Team ID — aparece en la esquina superior derecha de las páginas de la cuenta de desarrollador, junto al nombre de tu cuenta.
Esperado: ahora tienes tres valores — el archivo .p8, un Key ID y tu Team ID. Mantén el archivo .p8 fuera de Git: firma como tu cuenta de desarrollador.
Añadir los valores a la app
El kit espera exactamente las tres líneas de abajo — el mismo par clientId/clientSecret que usa cada proveedor social. APPLE_CLIENT_ID es la Services ID (com.yourcompany.yourapp.web), no la App ID.
Apple no emite un client secret estático, así que APPLE_CLIENT_SECRET es un JWT que firmas tú mismo a partir del Team ID, el Key ID y la clave privada .p8 — la documentación de Better Auth incluye el pequeño script generador para ello. Un secret firmado sigue siendo válido como máximo seis meses: pon un recordatorio para regenerarlo y actualizar el valor env, porque el inicio de sesión falla en el momento en que caduca. No pegues nunca el contenido del archivo .p8 ni el Key ID en crudo en el env — solo el JWT generado pertenece ahí.
El client secret y el archivo .p8 son solo de servidor: nunca en variables NEXT_PUBLIC_/EXPO_PUBLIC_ y nunca commiteados — en producción se configuran en el almacén de secretos de tu hosting. Reinicia el servidor de desarrollo después de editar; los cambios de env solo se leen al arrancar.
# apps/web/.env.local
AUTH_APPLE_ENABLED=true
APPLE_CLIENT_ID=com.yourcompany.yourapp.web # the Services ID, not the App ID
APPLE_CLIENT_SECRET=<JWT signed with Team ID + Key ID + .p8>Verificar y solucionar problemas
Abre tu APP_URL — una URL desplegada o el túnel https — en /auth, haz clic en el botón de Apple, inicia sesión con cualquier Apple ID (no hace falta que sea la cuenta de desarrollador) y confirma que vuelves con la sesión iniciada.
La mayoría de los fallos son una de tres confusiones: Services ID vs App ID — el client ID debe ser la Services ID para el inicio de sesión web; una return URL que no coincide — el callback debe ser exactamente igual a una Return URL registrada, incluidos protocolo, dominio y ruta; o un client secret caducado/inválido — regenera el JWT, que es solo un token firmado, no el contenido del .p8.
Hasta que AUTH_APPLE_ENABLED=true esté configurado, la opción de Apple en /auth permanece desactivada — revisa los nombres de env y reinicia. Activar el flag sin APPLE_CLIENT_ID y APPLE_CLIENT_SECRET hace fallar el arranque y nombra la variable que falta.
La app iOS llega a este mismo backend — incluye Sign in with Apple en ella para que la revisión de la App Store acepte los otros botones sociales. La guía de cuentas móviles explica qué busca la revisión.
Si quieres continuar la configuración, lee Añadir los pagos con Stripe.