Pasar al contenido principal

OAuth2 Data encryption


El api de autorización OAuth 2.0 permite que una aplicación de terceros obtenga acceso limitado a un servicio HTTP, ya sea en nombre del propietario del recurso al orquestar una interacción de aprobación entre el propietario del recurso y el servicio HTTP, o permitiendo que la aplicación de terceros acceda a él en su propio nombre.

  1. Esto significa que puedes permitir que ciertos usuarios/aplicaciones accedan a tus recursos de manera limitada. Cuatro de los componentes que interactúan en esta implementación son:
  2. El Propietario del Recurso: Este es el dueño de las claves del recurso, y aquí es donde la mayoría de los clientes vienen a obtener las credenciales para acceder al recurso.
  3. El Autorizador: Después de obtener las credenciales del propietario del recurso, el cliente debe obtener un token de portador que permite un acceso limitado al recurso.
  4. El Recurso: Esto es lo que el cliente necesita para encriptar y desencriptar mensajes.
  5. El Cliente: Un cliente no siempre se refiere a una persona en este contexto. La mayoría de las veces se refiere a una aplicación que intenta acceder a recursos y tampoco es específico para un tipo de aplicación. Puede variar desde un script de shell hasta una aplicación web. Aquí cualquiera puede acceder al recurso con las credenciales adecuadas.

  1. El cliente solicita autorización al propietario del recurso, si se cumplen los criterios de aceptación, el propietario del recurso concede la autorización.
  2. El cliente entonces necesita solicitar el token de portador necesario para acceder al recurso utilizando la autorización obtenida en el paso anterior.
  3. El cliente ahora puede acceder al recurso protegido utilizando este token de portador por un tiempo limitado.

Solicitud de acceso

Todos los clientes (aplicaciones) deben registrarse en el servidor de autorización OAuth 2.0 del cual pretenden solicitar tokens de acceso. Al registrar una aplicación, recibes un conjunto de claves. Una es una clave pública llamada ID de cliente, y la otra es una clave secreta llamada secreto de cliente. Sin estas claves, una aplicación no puede emitir solicitudes de código de autorización ni tokens de acceso al servidor de autorización.