Este documento describe OAuth, un protocolo de autorización abierto que permite a aplicaciones y servicios acceder de forma segura a recursos protegidos de otro servicio sin compartir las credenciales del usuario. OAuth permite a los usuarios iniciar sesión en aplicaciones de terceros utilizando cuentas existentes de proveedores como Google o Facebook. Funciona mediante el intercambio de tokens de acceso de corta duración por tokens de actualización de larga duración entre la aplicación, el servidor de autorización y el servidor de recursos.

1. OAUTH
(Open Authorization; Autorización abierta)

2. Integrantes
 Karina Barrios
 Kevin Medina
 Degly García
 Gabriela Zimeri
 Cristóbal Carrera
 Aury González
 Andrés Herrera
 Pablo Hernandez

3. ¿Qué es
OAUTH?
 OAuth es un framework o protocolo de autorización estándar
abierto que describe cómo los servidores y servicios no
relacionados pueden permitir acceso autenticado a sus activos de
forma segura sin compartir realmente la credencial de inicio de
sesión.

4. ¿Cuando fue
creado?
 Propuesto por BlaineCook y Cris Messina, 3 de octubre de 2007.
 Creado y fuertemente apoyado desde el principio por Twitter,
Google y otras compañías, OAuth fue lanzado (Oauth 1.0) como
un estándar abierto en 2010 como RFC 5849, y rápidamente se
hizo ampliamente adoptado. Durante los dos años siguientes, se
sometió a revisión sustancial, y la versión 2.0 de OAuth, fue
lanzado en 2012 como RFC 6749.

5. ¿Para que
Sirve?
 Permite autorización segura de una API de modo estándar y
simple para aplicaciones de escritorio, móviles y web.

6. Como
Funciona
 Diseñado para trabajar con el Protocolo de transferencia de
hipertexto (HTTP).
 OAUTH utiliza tokens de acceso que se emitirán a clientes de
tercero por medio de un servidor de autenticación, con aprobación
del propietario del recurso o el usuario final. El cliente utiliza el
token de acceso para acceder a los recursos protegidos alojados
en el servidor de recursos.
 Es comúnmente usado por usuarios de internet para iniciar sesión
en sitios web de terceros usando cuentas de Google, Facebook o
Twitter, sin preocuparse que sus credenciales de acceso sean
comprometidos.

7. Como
Funciona

8. Como
Funciona
Ejemplo con una tienda online usando PayPal.
1. El usuario accede a la tienda online y esta le pide que se loguee con
PayPal y el usuario le dice que si.
2. La tienda online le pide a PayPal los datos los datos del usuario .
3. PayPal, no la tienda online, pide al usuario su nombre de usuario y
contraseña.
4. El usuario los pone y configura a que datos y que permisos tendrá la
tienda online.
Posteriormente PayPal y tienda online se intercambian los datos
acordados.
Si hackean la tienda online no tienen acceso a nada, la tienda online solo
tiene un token que solo sirve para acceder a PayPal desde los servidores
de la tienda online y solo a una información limitada, ni al usuario, ni a la
password, ni la tarjeta de crédito cosa que solo tiene PayPal.

9. Versiones de
OAUTH
 Oauth 1.0 RFC 5849 en abril de 2010.
 Oauth 2.0 RFC 6749 y RFC 6750 en octubre de 2012, todavía hoy se
siguen desarrollando nuevas funcionalidades.

10. Quien usa
OUATH

11. Ventajas y
Desventajas
VENTAJAS
 Si a aplicación es hackeada, los usuarios y contraseñas del usuario
quedan a salvo en otro servidor de autenticación, ejemploTwitter.
 Cada par de tokens es único. Cada sitio web o aplicación tiene un
par distinto para cada usuario, así que si alguien consiguiese todos
lo pares, no le servirán de nada porque solo sirven para acceder al
sitio(Facebook/Twitter) desde un único sitio
DESVENTAJAS
 Algunas aplicaciones a las que accedes usando Facebook oTwitter
postean en tu perfil.

12. Tiempos de
Caducidad de
un Token
El tiempo de caducidad de un token lo determina el proveedor de
servicios ya que ellos determinan cuanto tiempo la información
estará disponible para su consulta.
Por ejemplo un access_token de la API de Google viene con un
valor de expires_in que indica la vida útil restante del token de
acceso, en este caso el token tiene un tiempo de vida de 1 hora a
partir de que la respuesta fue generada.
expires_in: la cantidad de segundos que faltan para que el token
deje de ser válido.

13. ¿Por queToken
deAcceso a
corto plazo?
La idea general es permitir que los proveedores emitan tokens de
acceso a corto plazo con tokens de actualización a largo plazo. ¿Por
qué?
 Muchos proveedores admiten tokens de portador que son muy
débiles en cuanto a seguridad. Al hacer que sean efímeros y que
requieran actualización, limitan el tiempo que un atacante puede
abusar de un token robado.
 La implementación a gran escala no quiere realizar una búsqueda de
base de datos en cada llamada API, por lo que en su lugar, emiten
token de acceso autocodificado que se pueden verificar mediante
descifrado. Sin embargo, esto también significa que no hay forma de
revocar estos tokens, por lo que se emiten durante un breve período
de tiempo y deben actualizarse.
 El token de actualización requiere autenticación del cliente que lo
hace más fuerte. A diferencia de los tokens de acceso anteriores, por
lo general se implementa con una búsqueda en la base de datos.
Es esencialmente una medida de seguridad. Si su aplicación está
comprometida, el atacante solo tendrá acceso al token de acceso de
corta duración y no podrá generar uno nuevo.
Los tokens de actualización también caducan pero se supone que deben
vivir mucho más tiempo que el token de acceso.

14. Ejemplo
Practico