web-services - títulos - meta tags wordpress
OAuth de dos patas: en busca de información (3)
Recuerde distinguir entre autenticación y autorización. En algunos lugares, creo que el OP mezcla los dos.
Por ejemplo, una vez que un servidor autentica a alguien, por lo general explícita o implícitamente (usando cookies) proporciona un token de autenticación para que las solicitudes posteriores ya estén autorizadas.
Depende del servidor cuánto duran las credenciales. Es inteligente planificar que las credenciales caduquen en algún momento. Simplemente haga que el servidor cliente esté preparado para volver a autenticarse cada vez que reciba la respuesta de error "autorización expirada".
No desea intentar proporcionar una sesión "sin vencimiento" ya que:
Todo expira en algún momento. Por ejemplo, ¿cómo podrá el servidor del cliente volver a acceder a la aplicación si pierde potencia o se reinicia?
Estás creando un sistema inflexible. Tienden a romperse más a menudo.
- Como sabe que desea agregar tipos adicionales de inicios de sesión en el futuro, en lugar de dos tipos de inicios de sesión (clientes del servidor y clientes del navegador), solo cree un tipo de inicio de sesión ahora. El trabajo adicional para el servidor cliente será implementar una capacidad de "volver a iniciar sesión según sea necesario".
Quiero implementar una nueva API basada en REST en nuestra infraestructura, y OAuth parece ser el camino a seguir.
Para nuestra implementación, primero habrá acceso de servidor a servidor, que no tendrá restricciones. Creo que esto se llama autorización de dos piernas.
Más adelante, nos gustaría permitir que el API consuma la API, lo que convertirá nuestra autorización en tres patas.
¿Hay un buen punto de partida para implementar esto? ¿Cómo podemos autorizar completamente un servidor y luego agregar autorización restringida por usuario?
La especificación de OAuth no es realmente útil en estos escenarios, pero creo que esto implica que debemos crear una sesión que nunca expire para el acceso de servidor a servidor, y luego agregar sesiones normales con acceso limitado para API de solo usuario.
Espero encontrar puntos de partida para obtener más información, ¡házmelo saber!
¿Es OAuth para mí? Solo estoy buscando un sistema de solicitud autenticado, y solo el consumidor y el proveedor de servicios existen en este escenario. ¡El usuario final no entra para jugar!
Ya, OAuth es probablemente para ti.
En realidad, hay dos especificaciones OAuth, la versión de 3 patas y la versión de 2 patas. La versión de 3 patas es la que recibe la mayor atención, y no es la que desea usar.
La buena noticia es que la versión de 2 patas hace exactamente lo que usted desea, permite que una aplicación otorgue acceso a otra a través de una clave secreta compartida (muy similar al modelo de servicio web de Amazon, utilizará el método de firma HMAC-SHA1) o a través de un sistema de clave pública / privada (use el método de firma: RSA-SHA1). La mala noticia es que aún no es tan compatible como la versión de 3 patas, por lo que es posible que tenga que trabajar un poco más de lo que podría haber hecho hasta ahora.
Básicamente, OAuth de 2 patas solo especifica una forma de "firmar" (calcular un hash) varios campos que incluyen la fecha actual, un número aleatorio llamado "nonce" y los parámetros de su solicitud. Esto hace que sea muy difícil suplantar las solicitudes a su servicio web.
OAuth se está convirtiendo lenta pero seguramente en un estándar aceptado para este tipo de cosas: a la larga, será mejor si lo acepta porque la gente puede aprovechar las diversas bibliotecas disponibles para hacerlo.
Es más elaborado de lo que inicialmente quisieras, pero la buena noticia es que mucha gente ha dedicado mucho tiempo para que sepas que no has olvidado nada. Un buen ejemplo es que muy recientemente Twitter encontró un vacío en la seguridad de OAuth, que la comunidad está trabajando actualmente para cerrar. Si inventaras tu propio sistema, tendrás que resolver todo esto por tu cuenta.
¡Buena suerte!
OAuth terminará siendo demasiado difícil para nuestras necesidades. Decidí adoptar el esquema de autenticación de Amazon S3, simplemente porque se ajusta mejor a nuestro modelo.
Gracias por ayudarnos a encontrar una respuesta, aunque ...