Límites del inicio de sesión social
Customer App puede mostrar Apple, Google o Facebook como opciones de cuenta externa cuando la compilación, plataforma y proyecto actuales admitan ese proveedor. La autorización del proveedor no crea una sesión de Customer App: Ordering.co debe verificar la prueba del proveedor, resolver la cuenta correcta de la aplicación, aplicar cualquier política explícita de vinculación o colisión, completar una fusión de invitado autorizada y solo entonces emitir la sesión de Ordering.co.
No uses una cuenta real del proveedor para verificar esta guía. Mantén bloqueados la vinculación de cuentas, fusión de invitado, emisión de sesión, revocación del proveedor y cierre de sesión hasta verificar el contrato de identidad actual en un entorno aislado de seguridad y ciclo de vida.
Separa las capas responsables
| Capa | Responsabilidad | Lo que no demuestra |
|---|---|---|
| Customer App | Mostrar una opción de proveedor apta, abrir su interfaz tras una acción explícita, enviar a Ordering.co un resultado de autorización opaco y mostrar el estado local pendiente/error. | Autenticidad del proveedor, propiedad de cuenta, vinculación segura, fusión de invitado ni creación duradera de sesión. |
| Sistema operativo | Mostrar autorización nativa o mediante navegador cuando la plataforma la admita y devolver el control a la App. | Que el callback pertenezca al proyecto, intento de cuenta o sesión de App actuales. |
| Proveedor de identidad | Autenticar su cuenta y devolver una prueba o resultado de autorización acotado. | La cuenta o función de Ordering.co que le corresponde. |
| Servicios de Ordering.co | Verificar la prueba, resolver una identidad del proveedor con espacio de nombres, aplicar política de colisión/vinculación, autorizar la fusión de invitado y emitir la sesión de Customer App. | Configuración de callback nativo ni disponibilidad del proveedor. |
| Responsable de sesión | Guardar la sesión devuelta de Ordering.co, aplicar controles de verificación/perfil y coordinar cierre de sesión, revocación y cambio de cuenta. | Cierre de sesión o revocación de cuenta del proveedor, salvo que se coordinen explícitamente. |
| Responsable del despliegue | Alinear la aplicación de proveedor aprobada, registro de callback nativo, variante de compilación, proyecto y política de verificación del servidor. | Éxito en ejecución por un botón visible o dependencia incluida. |
Opciones actuales de proveedor
| Opción | Presentación actual de Customer App | Límite de plataforma |
|---|---|---|
| Apple | Opción condicional de inicio de sesión en Login y Sign up. | Puede aparecer solo en iOS; no se ha establecido compatibilidad con Android. |
| Opción condicional de inicio de sesión en Login y Sign up. | iOS y Android usan configuraciones y comprobaciones de disponibilidad distintas. | |
| Opción condicional de inicio de sesión en Login y Sign up. | iOS y Android requieren configuración nativa/del proveedor coincidente. Que esté presente el SDK nativo no demuestra que la opción esté habilitada. |
Si falta una opción, puede que la versión, plataforma, proyecto, configuración del proveedor o pantalla actual no la admita. Esto no identifica una interrupción del proveedor ni un problema con la cuenta externa del cliente.
Sigue las fases de identidad
| Fase | Resultado requerido | Disposición ante fallos |
|---|---|---|
| 1. Mostrar opción | La compilación y el proyecto actuales exponen intencionalmente el proveedor en esta plataforma. | Mantén la opción no disponible; no deduzcas ni expongas valores de configuración. |
| 2. Autorización del proveedor | El cliente elige explícitamente el proveedor y este devuelve una sola prueba acotada para el intento. | La cancelación no cambia la cuenta ni sesión de Customer App. |
| 3. Verificación de Ordering.co | Ordering.co verifica la autenticidad del proveedor, audiencia de App prevista, vigencia y protección contra repetición. | Rechaza con un error genérico; no confíes en campos del perfil del proveedor como prueba. |
| 4. Resolución de identidad | Ordering.co encuentra una identidad de proveedor exacta con espacio de nombres o propone una acción explícita y autorizada de recuperación/vinculación. | No vincules cuentas solo porque coincidan sus direcciones de correo. |
| 5. Decisión de colisión/vinculación | Una cuenta ya vinculada, en conflicto, deshabilitada, privilegiada o ambigua sigue una política deliberada. | Detente antes de fusionar o emitir sesión y conserva ambas cuentas. |
| 6. Fusión de invitado | Una reclamación de invitado autorizada y de un solo uso se fusiona transaccionalmente con la cuenta resuelta. | Mantén recuperable el estado de invitado/cuenta; no transfieras parcialmente carritos, direcciones, pedidos ni instalaciones. |
| 7. Sesión de Ordering.co | Ordering.co emite una sesión actual y la App la guarda de forma duradera antes de navegar. | Mantén la sesión cerrada o de invitado; no navegues con una sesión sin resolver. |
| 8. Controles de App | Los controles de verificación, perfil, dirección, proyecto y destino se ejecutan para la sesión nueva. | El éxito del proveedor no omite requisitos previos de Customer App. |
| 9. Desmontaje | Cierre, desvinculación, revocación, retirada y cambio de cuenta/proyecto invalidan el estado correspondiente de App y proveedor. | Rechaza callbacks tardíos e identidad de proveedor obsoleta. |
Mantén explícita la vinculación
La cuenta del proveedor y la cuenta de Ordering.co pertenecen a espacios de identidad distintos. El contrato de servicio aprobado debe usar conjuntamente proveedor, emisor y sujeto del proveedor. No uses correo, nombre para mostrar, foto, teléfono ni un identificador sin espacio de nombres como única clave para vincular cuentas.
Si una prueba del proveedor puede corresponder a una cuenta existente, exige la política aprobada de recuperación o autenticación reciente. Nunca vincules implícitamente funciones privilegiadas u operativas basándote en la coincidencia de un perfil externo.
La documentación pública de Customer App no ofrece un procedimiento para vincular/desvincular hasta que se establezcan ese flujo de producto y sus estados de recuperación.
Protege la conversión de invitado
Iniciar sesión social desde una pantalla compatible con invitado puede cruzar dos límites distintos:
- autenticar y resolver la identidad externa/de Ordering.co; y
- transferir solo el estado de invitado que la cuenta actual tenga autorización para poseer.
Usa una reclamación de invitado de un solo uso y vinculada a la audiencia. Rota la credencial y sesión del invitado, vínculo de instalación y toda identidad de proveedor como una transacción recuperable. El resultado del proveedor no debe por sí solo mover carritos, direcciones, pedidos, contexto de pago, mensajes ni instalaciones de notificación.
Gestiona cancelación, errores y revocación
| Resultado observable | Interpretación segura | Responsable siguiente |
|---|---|---|
| No aparece la opción de proveedor | Disponibilidad no resuelta para esta compilación/plataforma/proyecto. | Responsables de versión y configuración. |
| Se cancela la interfaz del proveedor | No se aceptó una prueba externa para este intento. | La App vuelve al estado de Login o Sign up sin cambios. |
| La interfaz del proveedor no devuelve una prueba utilizable | La autorización está incompleta. | Responsable de integración del proveedor; no hay sesión de Ordering.co. |
| Ordering.co rechaza la prueba | Falló la validación de autenticidad, audiencia, repetición, cuenta o política. | Responsable de seguridad de identidad/API; mostrar un error genérico. |
| Se detecta una colisión de cuenta | La identidad del proveedor no se puede resolver automáticamente de forma segura. | Responsable explícito de recuperación/vinculación de cuentas. |
| Falla la fusión de invitado tras verificar identidad | La autenticación y migración de datos tienen resultados distintos. | Responsable de transacción de invitado/sesión; no emitas una sesión sin resolver por completo. |
| Falla la persistencia de sesión | Ordering.co podría haber devuelto un resultado, pero la sesión de App no es duradera. | Responsable de sesión; no navegues ni repitas automáticamente la autorización del proveedor. |
| Después se revoca la credencial del proveedor | La autorización del proveedor cambió tras emitir la sesión de App. | Responsable de política de revocación; no supongas que un cierre de sesión revoca el otro. |
| Cambia la cuenta o proyecto durante el callback | El callback pertenece a una generación obsoleta del ciclo de vida. | Recházalo y límpialo. |
Verifica con proveedores deshabilitados
Un fixture aislado sustituye cada SDK de proveedor y el intercambio de autenticación de Ordering.co antes de montar la pantalla. Debe cubrir:
- opción oculta y visible según plataforma/compilación/proyecto;
- opción mostrada antes de autorizar con el proveedor, cancelación, proveedor no disponible, prueba ausente y error genérico;
- una prueba opaca aceptada sin registrar su valor;
- audiencia, emisor o nonce/estado incorrectos, vencidos, repetidos o duplicados;
- identidad nueva/existente, colisión, cuenta deshabilitada y denegación de cuenta privilegiada;
- inicio sin sesión y como invitado, reversión de fusión y fallo de persistencia de sesión;
- controles de verificación/perfil/dirección después de emitir sesión;
- cierre de sesión, revocación de proveedor, cambio de cuenta/proyecto y denegación de callback tardío;
- comportamiento accesible de botón, carga, error y foco en iOS y Android; y
- cero efectos de proveedor, cuenta, sesión, invitado, notificación, almacenamiento o producto fuera del registrador local exacto.
La disponibilidad del proveedor y la autorización de cuentas reales dependen del entorno de integración y de la configuración de la cuenta.
Reglas de seguridad y privacidad
- Nunca registres ni publiques pruebas del proveedor, códigos de autorización, cargas de perfil, identificadores de cliente/aplicación, valores de callback, sesiones de Ordering.co, reclamaciones de invitado ni tokens de instalación de notificaciones.
- Envía solo los datos mínimos del proveedor necesarios para verificar en el servidor y ofrecer la experiencia de cuenta aprobada.
- Vincula cada callback con la compilación, proyecto, proveedor, intento, generación de cuenta/sesión y estado de redirección previstos.
- Haz transaccionales o recuperables la creación/vinculación de identidad, fusión de invitado, emisión de sesión, reasignación de instalaciones, trabajo de plugins e historial de auditoría.
- Usa errores públicos genéricos que no revelen si existe una cuenta, función privilegiada, sujeto de proveedor o correo electrónico.
- Trata el cierre del proveedor, cierre de Customer App, desvinculación, revocación y eliminación de cuenta como acciones separadas con una política explícita de coordinación.
Vuelve a validar cuando cambie el contrato
Vuelve a validar de forma aislada tras cambios en SDK de proveedor, esquemas o derechos nativos, controles públicos de disponibilidad, verificación del servidor, reglas de vinculación de identidad, fusión de invitado, almacenamiento de sesión, asignación de instalaciones de notificación, controles de verificación/perfil, cierre de sesión/revocación o políticas de privacidad/retención.
Referencias relacionadas: Iniciar sesión en Customer App · Registrarse o continuar como invitado · Verificar una cuenta · Completar un perfil · Opciones de consentimiento y privacidad · Límites de integraciones nativas · Límites de notificaciones push