Flujos de autorización en OAuth 2.0
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Contenido del curso
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Clase 12 de 25
Clase 12 / 25
Cesar Payro
Nicolas Gonzalez
Marcel Garcia
Iram Moncada
Guillermo Rodas
Profesor
Antonio Obregón
Jorge Adoney Espinosa Gómez
David Steven Gonzalez Vargas
Axel Nava Palacios
Angel Javier Sanchez Tenjo
Angel Javier Sanchez Tenjo
Cesar Christopher Alviz Choque
Benjamin Rodriguez
Samuel Gómez Balderas
Julio Cesar Fuentes Alvarado
Andres Leon
curso de criptografia!!!
Un ejemplo practico seria cuando una empresa ofrece beneficios por ejemplo el ingreso a un gimnasio por convenio, entonces el resource owner podriamos ser nosotros, el client prodria ser el gimnasio, el authorization server podrian ser las personas que se encargan del ingreso de personas al gimnasio que estan en recepcion, y a estas personas se les muestra el carnet de la empresa que se podria ver como el token de acceso para que validen el convenio, y el resource server serian las maquinas que se encuentran en el gym
OAuth 2.0 es como un sistema de seguridad en un edificio de oficinas compartido. Aquí va la analogía para entender los roles y flujos:
Flujos de OAuth 2.0
Pregunta: Cuál Flow es más común para aplicaciones internas (intranet) en compañías? Mi intuición dice que seria Client Credentials flow pero me gustaría saber su opinion y porque?
Independientemente que sea un proyecto interno o no, va mas de la mano de la comunicación entre aplicaciones y su interacción con usuario.
Si es backend a backend es client credentials.
El flujo de autorización Implicit Flow en OAuth 2.0 envía el Access Token en el fragmento de la URL. Por ejemplo, una respuesta de token podría verse así:
https://tuaplicacion.com/callback#access_token=1234567890abcdef&token_type=bearer&expires_in=3600
En este caso, 1234567890abcdef es el Access Token. Este enfoque es menos seguro y no se recomienda, ya que puede ser susceptible a ataques de seguridad.
En la clase se comenta que en la sección recursos están las slides usadas en el curso, pero no las encuentro ¿Dónde puedo encontrarlas? :/
¡Están en la primera clase!
https://drive.google.com/file/d/1xKbOWF3-9mkl9MUFWCFrseSTxnceUkPz/view
Authorization code flow: Restaurante con reservación requerida, una persona no puede ir a menos que tenga la reservación, el restaurante es el client, el authorization server es la persona con la que hiciste la reservación, el resource server es la comida/chef, los meseros son la api.
Resource owner: solicitar un servicio en linea (pedir comida o pedir que se imprima algo en el ciber desde el celular), solo te piden que te identifiques para entregar tu servicio
Authorization code flow w/pcke: ir a un lugar donde te pidan un código para entrar, una zona vip?
Client credentials: Comunicación aerea, comunicación que se da por canales seguros entre un piloto y el área de control
Vengo del Futuro y crearon un curso de Criptografia: https://platzi.com/cursos/fundamentos-criptografia/
Imagina OAuth 2.0 como el servicio de valet parking en un hotel. Tú eres el usuario (Resource Owner) y llegas con tu carro (tus datos). El hotel es el Authorization Server, que te conoce y verifica tu identidad. En lugar de entregar las llaves de tu carro a cualquiera, el hotel le da al valet (Client / aplicación de terceros) un ticket temporal que solo permite estacionar y retirar el carro, pero no usarlo para otros fines. El parqueadero es el Resource Server, que acepta el ticket, valida que sea legítimo y permite el acceso solo a lo autorizado. Así, OAuth 2.0 permite que una aplicación acceda a recursos específicos del usuario sin conocer ni manejar sus credenciales, usando permisos limitados y revocables.
En el flujo "Authorization Code Flow with Proof-Key for Code Exchange", el Code Challenge y el Code Challenge Method se envían al Authorization Server en la primera solicitud de autorización, junto con otros parámetros como el Client ID y los Scopes. El Code Challenge es el resultado del Code Verifier aplicado a un algoritmo de hashing, y permite al servidor verificar la autenticidad del cliente en la segunda etapa del flujo.
curso de criptografia, se necesita
Nuevamente, curso de criptografía, venga!!
Hagan el curso de la criptografía por favor
Saludos a todos, alguien puede responderme estas preguntas:
1.- Cuando se usa PKCE, igual la aplicación cliente debería guardar el code_verifier, caso contrario tendría que solicitar el consentimiento del usuario cada que se accese a la aplicacion?
2.- Si es así, este enfoque no funcionaría muy bien en SPA, porque como se guarda de forma segura un secreto en una SPA (Sin hacer uso de un servidor backend).
