Esto se basa en el borrador actual a partir de hoy, 17:
http://tools.ietf.org/html/draft…
OAuth 2.0 es un protocolo basado en HTTPS que permite al propietario de un recurso (el usuario final), utilizando un agente de usuario (generalmente un navegador), permite que un cliente (generalmente un consumidor de API) acceda a un recurso protegido en un servidor de recursos (generalmente un proveedor de API) usando credenciales almacenadas en un servidor de autorización. El acceso al recurso protegido está autorizado por un token de acceso.
A los clientes se les asignan secretos que se comparten con el servidor de autorización.
- ¿Cuáles son los tres lenguajes de programación más influyentes y por qué?
- ¿Qué marco debo usar para una plataforma colaborativa de equipo que usa Java?
- Cómo rotar una imagen en HTML
- ¿Debo ir a desarrollo web o desarrollo C ++?
- ¿Es posible escribir código laravel incorrecto?
1. Flujos de autorización
Hay 4 flujos disponibles.
1.1. Flujo de código de autorización
El flujo del Código de autorización se utiliza cuando el cliente es un servidor o aplicación web de terceros, que realiza el acceso al recurso protegido.
El cliente no tiene acceso a las credenciales del propietario del recurso.
El agente de usuario se conecta a una URL alojada por el cliente. El cliente redirige al agente de usuario al servidor de autorización, incluida la información que se identifica a sí mismo (una identificación del cliente), la solicitud (alcance – los permisos solicitados) y una URL que apunta hacia el cliente (URL de redireccionamiento – se conoce como un URI en la especificación, aunque siempre es una URL HTTP).
El servidor de autorización autoriza al propietario del recurso y puede realizar la autenticación, como la verificación del nombre de usuario / contraseña y la confirmación de la acción solicitada. En caso de éxito, dirige al usuario-agente de regreso al cliente a través de la URL de redireccionamiento proporcionada, agregando un código de autorización a la URL.
La URL de redireccionamiento generalmente apunta a un script del lado del servidor que solicita el token de acceso a través de una POST al servidor de autorización. La POST está autenticada por el secreto del cliente y proporciona el código de autorización recibido como prueba de que el propietario del recurso realmente ha autorizado la solicitud. El servidor responde con el token de acceso y un tiempo de vencimiento en la respuesta POST.
1.2. Flujo de concesión implícito
El flujo de concesión implícita se utiliza cuando el agente de usuario accederá directamente al recurso protegido, como en una aplicación web enriquecida o una aplicación móvil. El secreto del cliente no se usa.
El agente de usuario se conecta a una URL en el servidor de autorización. Esto podría ser una conexión directa o una redirección realizada desde el cliente. La solicitud contiene la identificación del cliente, el alcance de la solicitud y la URL de redireccionamiento. Si el servidor de autorización pasa la solicitud, realiza una redirección a la URL de redireccionamiento con el token de acceso y el tiempo de caducidad en el fragmento (después del hash #).
Si bien la URL de redireccionamiento apunta al cliente, el código dentro del cliente (es decir, la aplicación del lado del servidor) no lo ve. En cambio, la URL se puede usar para cargar JavaScript que toma el token de acceso de la URL y lo usa. O bien, una aplicación móvil puede capturar la redirección, extraer el token de acceso y usarlo en su código, en cuyo caso la URL solo puede apuntar a contenido estático.
1.3. Flujo de credenciales de contraseña del propietario del recurso
El flujo de credenciales de la contraseña del propietario del recurso se utiliza cuando el propietario del recurso confía en el cliente para obtener su nombre de usuario y contraseña. El cliente obtiene las credenciales a través de otros medios que están fuera del alcance, luego las pasa directamente al servidor de autorización para solicitar un token de acceso. Este flujo se puede usar para migrar esquemas tradicionales de autenticación de nombre de usuario / contraseña.
1.4. Flujo de credenciales del cliente
El flujo de credenciales del cliente obtiene el token de acceso basado únicamente en el secreto compartido del cliente.
2. Acceso al recurso protegido
Una vez que el cliente o agente de usuario (en el flujo de concesión implícito) tiene el token de acceso, puede usarlo para acceder al recurso protegido. Hay 2 formas estándar de enviar las credenciales, aunque se pueden definir más.
2.1. Token al portador
El token de acceso se debe colocar en el encabezado HTTP de autorización y solo se puede colocar en un cuerpo de solicitud POST o en los parámetros GET URL como una opción alternativa.
2.2. MAC
Un MAC criptográfico (Código de autenticación de mensaje) se calcula utilizando elementos de la solicitud y se envía en el encabezado de Autorización. El propietario del recurso calcula y compara el MAC al recibir la solicitud.
El token de acceso solo se puede colocar en el encabezado HTTP de autorización
3. Actualizar tokens
En los flujos de Código de autorización y Credenciales de propietario de recurso, la implementación del servidor de autorización puede optar por emitir un token de actualización. Este token de actualización se puede usar para obtener un nuevo token de acceso sin solicitar autorización nuevamente.
