Ahora he pasado un tiempo investigando las opciones y me gustaría resumir los hallazgos. Primero, un poco más de contexto: desarrollo y control tanto el servicio como el consumidor API. El consumidor es una aplicación basada en Flash que se sirve desde el mismo host que la API ahora y se supone que debe usarse en el navegador. No hay clientes de terceros a la vista todavía.
Así que la pregunta se puede dividir en dos partes,
- cómo hago la autenticación OpenID través de la API
- ¿Cómo se mantiene el estado "autenticado" en las solicitudes posteriores
Para la primera parte, la autenticación OpenID casi siempre incluye pasos interactivos. Durante el proceso de autenticación, probablemente habrá un paso en el que el usuario se encuentre en la página web del proveedor de OpenID, iniciando sesión y presionando el botón "Acepto". Así que la API no puede y no debe manejar esto de forma transparente (no "dígame su proveedor de OpenID y contraseña y yo me ocuparé del resto"). Lo mejor que puede hacer es pasar y retroceder los enlaces HTTP que el cliente debe abrir y seguir las instrucciones.
El mantenimiento "autenticados"
API REST estatales deben ser sin estado, cada solicitud debe incluir toda la información necesaria para manejar la situación, ¿verdad? No tendría sentido autenticarse contra el proveedor de OpenID para cada solicitud, por lo que tipo de sesión es necesario. Algunas de las opciones para comunicar clave de sesión (o "token de acceso" o nombre de usuario/contraseña) son:
- HTTPS + autenticación básica ("Autorización: básicos ..." de cabecera en cada solicitud)
- peticiones de firma Amazon-style ("Autorización: AWS ..." encabezado en cada solicitud)
- OAuth: adquirir acceso de emergencia, que incluya y un montón de otros parámetros en cada solicitud
- cookie que almacena la clave de sesión ("cookie: ... "encabezado en cada solicitud)
- Cookie firmada que almacena información de la sesión en la misma cookie
En este momento hay solo un consumidor de API, por lo que opté por lo más simple que podría funcionar: cookies.Son súper fáciles de usar en Pilones, con la ayuda de Beaker. También "simplemente funcionan" en la aplicación Flash: dado que se ejecuta dentro del navegador, el navegador incluirá cookies relevantes en las solicitudes que realiza la aplicación Flash, la aplicación no necesita cambiarse en absoluto con respecto a eso. Aquí hay una pregunta de StackOverflow que también recomienda el uso de cookies: RESTful authentication for web applications
Beaker también tiene una bonita función de cookie-only sessions donde todos los datos de la sesión están contenidos en la cookie. Supongo que esto es tan apátrida como se pone. Hay no sesión almacenar en el servidor. Las cookies están firmadas y opcionalmente encriptadas para evitar manipularlas en el lado del cliente. El inconveniente es que la cookie se vuelve un poco más grande, ya que ahora necesita almacenar más que solo la clave de sesión. Al eliminar algunas cosas que realmente no necesitaba en la sesión (restos de la autenticación OpenID), reduje el tamaño de la cookie a unos 200 bytes.
Actualmente, la API está dirigida al escenario cliente-servidor. El cliente es una aplicación Flash y el servidor es la aplicación web Pylons. Actualmente no hay nada de servidor a servidor, por lo que no es necesario que tenga 3 patas. Mi problema actual es cómo introducir "usuarios autenticados" en el sistema sin tener que lidiar con el almacenamiento de contraseñas, el envío de recordatorios de contraseña, el restablecimiento de contraseñas, etc. No está claro de inmediato cómo OAuth me ayuda aquí, ya que en la versión de 2 patas solo especifica cómo firmar las solicitudes. –
En ese caso, tal vez una de las pastas en http://pylonshq.com/pasties/by_tag/openid ayudará. –