Oauth
¿Qué es OAuth?
Un protocolo abierto para permitir una autorización segura en un método simple y estándar de aplicaciones web, móvil y de escritorio, desde documentos
- La razón principal por la que OAuth se configuró inicialmente fue permitir que la aplicación acceda a los datos del usuario sin tener que darle la contraseña del usuario. Caso en cuestión: ¿recuerda cuándo todas esas aplicaciones de terceros le pedirían su correo electrónico + contraseña para acceder a su contacto de Gmail, etc.? La violación de seguridad obvia a medida que las aplicaciones podrían aferrarse y poder cambiar su contraseña. Algunas aplicaciones almacenarían la contraseña de los usuarios en texto de demanda (riesgo de seguridad obvio). La única forma en que los usuarios podían revocar el acceso era cambiar las contraseñas
- La principal característica distintiva de OAuth es que, en lugar de permitir que los usuarios ingresen contraseñas en la aplicación de terceros, los usuarios se redirigen al servidor OAuth (la aplicación principal, supongo) para ingresar su contraseña y luego redirigido a la aplicación de terceros que busca acceso.
- Otros casos de uso de OAuth después de su caso de uso inicial fueron alrededor de organizaciones que estaban construyendo aplicaciones de primera parte en sus propias API. Caso en cuestión: al iniciar sesión en cualquier servicio de Google (YouTube, Gmail, etc.), no inicia sesión en el servicio directamente. Está redirigido al servidor OAuth de Google (cuentas.google.com) donde inicia sesión y luego redirigido al servicio de Google después de la autenticación.
- El beneficio es centralizar la administración de contraseñas por razones de seguridad.
- Otro beneficio de la centralización es que facilita la actualización de la autenticación para todos los usuarios/servicios
OAUTH 2
- Hubo algunos casos de uso, como en aplicaciones móviles, donde la implementación inicial de OAuth no se pudo usar de forma segura.
- El objetivo de OAuth 2 era construir sobre OAuth 1 para aplicaciones móviles y simplificar aspectos que eran confusos para los consumidores de API.
- El problema con OAuth 2 fue que había conflictos entre la web y los contribuyentes empresariales del protocolo. Muchas de las áreas de contención se colocaron en diferentes documentos, dejando muchas brechas en el protocolo (ahora se llamaba un marco en el documento central como resultado).
- El resultado es que la implementación web para OAuth 2 puede ser compleja y confusa, ya que necesitará sintetizar información de diferentes borradores
- Problemas de implementación:
- El estándar no requiere un tipo de token
- no requiere tipos de subvención específicos
- no da orientación sobre el tamaño de la cadena de token
Creación de una aplicación OAuth 2
- Cree una cuenta de desarrollador en el sitio web del servicio e ingrese información básica sobre la aplicación (nombre, sitio web, logotipo, etc.)
- Se le dará un
client_id y client_secret (a veces) que su aplicación usará para interactuar con el servicio. - Crítico para registrar una o más URL de redirección (donde el servicio OAuth 2 devolverá al usuario después de que haya autorizado la aplicación) para evitar crear aplicaciones maliciosas que puedan robar datos del usuario.
- La URL de redirección debe ser un punto final HTTPS para proporcionar a un atacante de interceptar el código de autorización y secuestrar una sesión
- En lugar de registrar múltiples URL de redirección para diferentes estados de aplicación, OAuth 2 proporciona un parámetro " estado " que puede usarse para codificar un estado de aplicación.
- El parámetro es una cadena que se devolverá después de que el usuario esté autorizado para llevarlo a la ubicación correcta en la aplicación. La cadena de estado debe estar encriptada con un método como JWT.
- Estado generado inicialmente se almacena en la sesión, después de que el usuario autoriza y se redirige a la aplicación del cliente, el servidor OAuth compara la cadena de estado con lo que se almacenó inicialmente en la sesión antes de intercambiar el código de autorización para un token de acceso
Otros conceptos que he aprendido
rizo
- Suponga la URL del cliente es una herramienta de línea de comandos que los desarrolladores usan para transferir datos hacia y desde un servidor. Permitirle comunicar con un servidor especificando URL (ubicación) y datos que desea enviar.
- Admite diferentes protocolos (HTTP, HTTPS) y se ejecuta en casi todas las plataformas, lo que lo hace ideal para probar la comunicación en casi cualquier dispositivo
- Beneficios:
- Altamente portátil y comparable con casi OS y dispositivo
- útil para probar puntos finales
- puede ser detallado, por lo tanto, útil para la depuración
- Buen error de registro
Ejecutar un script de Python en la web sin un marco como Flask o Django
- Primero necesitaría configurar el script de Python como un script CGI
- CGI significa Interfaz Common Gateway. Permite que las aplicaciones se comuniquen con otras aplicaciones en Internet
- Primero cree una carpeta cig-bin y mueva su script de Python allí
- Luego use
http.server incorporado de Python para ejecutar un servidor HTTP simple - Ejecute
python -m http.server --cgi desde el directorio que contiene CGI -bin para iniciar el servidor HTTP en modo CGI. - Navegue a
http://localhost:8000/cgi-bin/your-script.py para ejecutar el script CGI. - En
your-script.py debe incluir print("Content-type:text/htmlrnrn") para establecer el tipo de contenido de la respuesta a "text/html" para habilitar que el script se ejecute en el navegador como un archivo html
Shebang (Hashbang)
- ¡Un código especial en forma de un
#! al comienzo de archivos ejecutables en sistemas operativos similares a UNIX. - Especifica la ruta al ejecutable de intérprete que debe usarse para ejecutar el script.
- Por ejemplo, un shebang como
#!/usr/bin/env python al comienzo de un script de Python le dice al sistema que use el intérprete de Python ubicado en usr/bin/env python para ejecutar el script.
Recursos
- OAUTH Documentation
- ¿Qué es OAuth y por qué importa? - oktadev en youtube
- OAUTH 2 servidores
- IBM: ¿Qué es Curl?