¿Qué es OAuth y como se implementa en PHP?

En esta charla para PHP Valencia, aprenderemos las bases de OAuth: actores, flujos y conceptos básicos.
Además veremos como implementar nuestro propio servidor y cliente OAuth con PHP y con Symfony.

Transcript

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_authentication.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!!!