¿Qué es OAuth 2.0?

Es excelente hasta ahora este curso. La explicacion es muy clara de todos los conceptos, y ademas con ejemplos adicionales de la vida real para bajar aun mas a tierra los conceptos aprendidos. 👏👏

Si alguien me puede corregir se lo agradecería.

• Le pido el favor a mi hija que vaya a mi apartamento y recoja mi portátil, le doy mi cédula para que ella se la presente al celador del edificio y el le entregue las laves del apartamento
• Ella llega a la portería y presenta mi cédula indicando que viene en nombre mio a recoger las llaves del apartamento
• EL celador verifica que la cédula es correcta y le entrega las llaves a mi hija
• Es correcta mi analogía? o me falta algo

Por si le sirve a alguien 😃

https://www.ibm.com/support/knowledgecenter/zh/SSELE6_8.0.1.3/com.ibm.isam.doc/config/concept/con_oauth_20_concepts.html

OAuth2 es un protocolo de autorización, que surgió a partir del nacimiento de la Web Social. Permite que los usuarios autoricen a terceros a acceder a su información sin que estos tengan que conocer las credenciales del usuario.

Hay múltiples entidades involucradas en el flujo de OAuth2:

Propietario de recursos: Parte que puede autorizar el acceso a los recursos protegidos. Puede ser una autorización de ciertos recursos y de otros no. Generalmente es una persona.
Cliente: Es el sitio web o aplicación que accederá a los recursos protegidos de un usuario con la autorización del mismo
Proveedor:
Servidor de autorización: Valida usuario y credenciales; y genera tokens de acceso.
Servidor de recursos: Recibe peticiones de acceso a los recursos protegidos autorizando acceso si el token que viene (en el cuerpo o en las cabeceras, generalmente en las cabeceras) en la petición es válido.

esto me suena similar al curso de API REST, autenticacion con Acces Token en donde interfieren siempre 3 actores el cliente, el servidor de autenticacion, y el servidor donde se solicitan los recursos esto es cierto?

hasta ahora el curso a estado de maravilla, también puedes leer esta documentación de OAuth que habla de lo mismo que el profesor explica https://auth0.com/docs/authenticate/protocols/oauth y una vez leíste esa puedes leer esta otra parte https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use y así entiendes lo de esta clase y la anterior(14)

Comprendo, aunque veo que la validación del token lo hace el servidor de API, pensaba que el servidor de API tenía que hacer una solicitud hacia el authentication server para verificar si el token existía en la base de datos

Por lo que veo ahora, con este flujo de autenticación ni siquiera es necesario guardar un token en la base de datos porque tanto el authorization como el API server conocen la llave secreta y puede decodificar dicho token

Básicamente el authorization firma el token con la llave secreta y el API usa la misma llave para verificar que la firma es verdadera!

Muy clara la explicación 😄

Qué es OAuth 2.0

Viene Open Authentication es el estandar para el manejo de autorización.

El Resource Owner es la entidad que concede el acceso a los recursos protegidos.

El Resource Server almacena esos recursos protegidos.

El cliente es la aplicación que solicita los recursos protegidos

El authorization Server verífica que el cliente es el Resource Owner. Al veríficar, le entrega permisos de autorización el Acess Towken tendrá los recursos necesarios para consumir los recursos protegidos.

Mi Resumen:
Open Authentication. Es el protocolo estándar de la industria para el manejo de autenticación. Permite que los usuarios autoricen a terceros a acceder a su información sin que estos tengan que conocer las credenciales del usuario.
Roles:
User (Resource owner): es la entidad que concede los permisos a los recursos protegidos. Generalmente representado por el usuario final.
Service API (Authorization Server): es quien almacena los recursos protegidos. Generalmente es la API a la que se quiere acceder.
Application (Client): es la aplicación que pide esos recursos protegidos en nombre del resource owner.
Service API (Resource server): es quien autentica que el resource owner es efectivamente quien dice ser y genera los Access Token para entregárselos a los clientes.
Flujo de Autorización:

1. La application requiere autorización (Authorization Request) en nombre del Resource owner (usuario).
2. Resource owner verifica que la application es quien dice ser y le entrega unos permisos de autorización (Authorization Grant).
3. La application se dirige al Authorization Server con los permisos obtenidos.
4. El Authorization Server verifica que los permisos son legítimos y envía un Access Token a la application. Este Access Token tiene todos los permisos necesarios para consumir los recursos del Resource Server.
5. La application envía el Access Token en cada petición al Resource Server.
6. El Resource Server verifica que el Access Token es válido y fue emitido por el Authorization Server y entrega los Recursos protegidos (Protected Resource).

Creo que falta hablar cuando nuestra aplicación genera el toquen o autorización. Seria como si el de las llaves fuera la hermana y el hermano pequeño le pide el recurso y la hermana le da las llaves. No he visto aun el manejo adecuado que se le hace si no usamos OAuth 2.0, cual es la forma adecuada de guardar el JWT, tal vez más adelantan del curso lo muestre,

De que forma el resource owner puede verificar que la aplicación es quien dice ser?

Buena explicacion, muy clara y precisa.

una explicacion my clara de OAuth 2.0

excelente la explicación de la vida real

Quedo muy claro con el ejemplo.

jajajaj que excelente ejemplo.

No había entendido del todo el funcionamiento, pero con el ejemplo de la pelota y de la aplicación pidiendo permisos para acceder a nuestros recursos, lo entendí del todo.

Este video se muestra mal en mobile. Me aparece el de la API de Spotify!

El ejemplo de la familia es GENIAL!! me ha quedado más claro.

OAuth: sirve pra la autorización

1. El cliente pregunta a dueño del recurso autorización
2. El cliente con la autorización solicita al servidor de autorización las llaves
3. El cliente con la llaves accede al servidor de recursos

El servidor de autorización crea llaves temporales.
Las llaves temporales sirven para acceder a los recursos.

1. Client ask to Resource Owner Authorization
2. Client With Authorization request to Authorization Server the keys
3. Client With keys access to Resource Server Assets

Excelente ejemplo, la vida real es algo muy chevere para darle sentido a las cosas!