Transparencias de la charla "Qué es eso de OAuth y como se implementa en Symfony2 (y otros)". En esta charla dimos un repaso a los conceptos más importantes de OAuth y vimos cómo implementar nuestro propio servidor de autenticación/autorización usando Symfony2.

1. Qué es eso de OAuth2 y
cómo se implementa en
Symfony2 (y otros!)

2. Sobre el tio que te habla
Miguel Ángel Sánchez (@slaimer)
● 4 años picando PHP
● Varios años con Symfony2
● Backend Developer en Origo.by
● Ciencia ficción clásica y moderna
● Mail (mangel.snc@gmail.com)

3. Un poco de teoría
OAuth (Open Authorization) es un protocolo abierto que permite autorización
segura de una API de modo estándar y simple para aplicaciones de escritorio,
móviles y web.
Para desarrolladores de consumidores, OAuth es un método de interactuar con
datos protegidos y publicarlos.
Para desarrolladores de proveedores de servicio, OAuth proporciona a los
usuarios un acceso a sus datos al mismo tiempo que protege las credenciales
de su cuenta.
En otras palabras, OAuth permite a un usuario del sitio A compartir su
información en el sitio A (proveedor de servicio) con el sitio B (llamado
consumidor) sin compartir toda su identidad.

4. Autorización o autenticación?

5. Autorización o autenticación?

6. Autorización o autenticación?
Autorización: Permitir acceso a un tercero por
parte del propietario a su información.
Autenticación: Demostrar ser quien dices ser.
OAuth debería utilizarse con propósitos de
autorización + autenticación, pero no siempre es
el caso.

7. Elementos que intervienen en una
transacción OAuth
• Scopes / ámbitos / alcances
• Roles / Actores
• Grant Types (Tipos de autorización)

8. Scopes
La información del usuario suele ir clasificada
bajo determinados scopes (ámbitos,
alcances… etc).
Esto es muy útil para permitir acceder a sólo a
la parte imprescindible de la información del
propietario.

10. Actores
En todo escenario de autenticación contamos
con 3 actores o roles que interactúan entre
ellos:
● Aplicaciones (Clients)
● API (Servers)
● Usuario (Owners)

11. Actores: Aplicaciones
Las aplicaciones son el cliente de nuestra API.
Las aplicaciones pueden ser propias o de
terceras partes.
La aplicación se conecta al API para obtener
información, previa autorización del owner.

12. Actores: API
El API es el servidor de recursos.
Sirve los recursos en distintos formatos conocidos
por el cliente.
Gestiona el acceso a los recursos para evitar
accesos ilegales.

13. Actores: Usuario
Es el propietario de los recursos.
Puede ceder permisos (autorizar) a las
aplicaciones para que accedan a sus recursos.
Él mismo puede “consumir” sus recursos.

14. Tipos de Autorización
Según el tipo de aplicación podemos (y se recomienda) usar un tipo
distinto de autenticación.
Toda autenticación requiere de al menos 2 parámetros:
● Client ID
● Client Secret
● Redirect URL (opcional, solo en algunos tipos de autorización).
Para poder autenticarse en el API, necesitamos que el app que accede
a los datos esté registrada (tenga un Client ID) y tenga una contraseña
de acceso (Client Secret).
Dependiendo del tipo de autorización, se requiere una URL de
redirección donde el API devuelve el token de acceso.

15. Authorization Code

16. Authorization Code 1/6
Se usa para aplicaciones basadas en Web
Server (es el código servidor quien accede al
API).
Por ejemplo, cuando permitimos a una
aplicación acceder a nuestros datos de
Facebook.

17. Authorization Code 2/6
Normalmente la autenticación se inicia con un
enlace que apunta a nuestra API:
Esto nos lleva a una pantalla de autorización
como la siguiente:
GET
https://oauth2server.com/auth?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=https://oauth2client.com/get-auth

19. Authorization Code 3/6
Después de procesar la petición, devuelve el
código de autenticación al cliente:
GET https://oauth2client.com/get-auth?code=AUTH_CODE

20. Authorization Code 4/6
Con el código recibido, el cliente hace una
petición para obtener un token:
POST
https://oauth2server.com/token
grant_type=authorization_code&
code=AUTH_CODE&
redirect_uri=https://oauth2client.com/handle-token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

21. Authorization Code 5/6
Y el cliente finalmente recibe su token:
{
“access_token”: “RsT5OjbzRn430zqMLgV3Ia”
}

22. Authorization Code 5/6
Y el cliente finalmente recibe su token:
… o un error:
{
“access_token”: “RsT5OjbzRn430zqMLgV3Ia”
}
{
“error”: “invalid auth_code”
}

23. Authorization Code 6/6
Con el token en su poder, el cliente ya está
preparado para acceder a recursos.

24. Implicit

25. Implicit 1/4
Se usa con aplicaciones basadas en
navegador (aplicaciones Javascript
mayormente).
Es MUY similar al Authorization Code, solo que
más simple.

26. Implicit 2/4
Normalmente la autenticación se inicia con un
enlace que apunta a nuestra API:
GET
https://oauth2server.com/auth?
response_type=implicit&
client_id=CLIENT_ID&
redirect_uri=https://oauth2client.com/handle-token

27. Implicit 3/4
Después de procesar la petición, devuelve el
token directamente en la URL:
GET https://oauth2client.com/handle-token#token=ACCESS_TOKEN

28. Implicit 3/4
Después de procesar la petición, devuelve el
token directamente en la URL:
… o un error:
GET https://oauth2client.com/handle-token#token=ACCESS_TOKEN
GET https://oauth2client.com/handle-token#error=access_denied

29. Implicit 4/4
Con el token en su poder, el cliente ya está
preparado para acceder a recursos.

30. Password

31. Password 1/3
Se usa normalmente cuando el desarrollador de la
aplicación y del API es el mismo.
Se usa un esquema user/password para obtener un token
directamente
No requiere el uso del client_secret, ya que la naturaleza
de las apps que emplean este tipo no permiten una
protección del mismo.

32. Password 2/3
Simple como el mecanismo de un botijo:
Enviamos cliente_id, user y password y recibimos un
token.
POST
https://oauth2server.com/token
grant_type=password&
client_id=CLIENT_ID&
username=USERNAME&
password=PASSWORD

33. La sencillez de este método lo hace ideal para aplicaciones
basadas en un API existente (p.ej clientes móviles).
OJO!
FOSOAuthServerBundle no implementa correctamente este tipo
de autenticación, ya que obliga a enviar el client_secret.
https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/issues/115
Password 3/3

34. Client Credentials

35. Client Credentials 1/2
Este es el tipo quizá menos habitual. Se usa
para acceder a datos del API fuera del contexto
de cualquier usuario.
Es como un acceso de “mantenimiento”.

36. Client Credentials 2/2
Es el más simple de todos, únicamente enviamos el
client_id y el client_secret y nos devuelve un token
POST
https://oauth2server.com/token
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

37. Realizar llamadas autenticadas

38. Llamadas autenticadas
Todo esto que hemos visto antes tiene como
única finalidad poder acceder a recursos
protegidos por el API.
¿Cómo hacemos para acceder a estos
recursos?

39. Llamadas autenticadas
De nuevo se trata de un procedimiento muy sencillo:
Únicamente debemos de hacer todas las llamadas al API
incluyendo una cabecera Authorization como esta:
Authorization: Bearer MzZlZDk0YmZiMzYyYjU0M...NmYWZhMzUxMDIxN2VjMg

40. Alternativas
● HAWK
o https://github.com/hueniverse/hawk
o Diseñado por Eran Hammer, editor de la especificación OAuth2
o Solo para autenticación
● Symfony2 SimplePreAuthenticatorInterface
o http://symfony.com/doc/current/cookbook/security/api_key_authenticat
ion.html
o Disponible desde v2.4
o Solo autenticación
● OpenID
o http://openid.net/
o Solo autenticación

41. Implementar OAuth en Symfony2
• FOSOAuthServerBundle

42. Implementar OAuth en Symfony2
• FOSOAuthServerBundle

43. bshaffer/oauth-server-php
Dispone de un bundle para Symfony.
Fácilmente integrable en:
• Silex
• Slim
• Drupal
• Laravel
Zend lo ha utilizado para Apigility

44. Preguntas…?
O cervezas???

45. Preguntas…?
O cervezas???
Gracias por venir!!!