qué es eso de oauth y como se implementa en symfony2 (y otros)
DESCRIPTION
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.TRANSCRIPT
Qué es eso de OAuth2 y
cómo se implementa en
Symfony2 (y otros!)
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 ([email protected])
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.
Autorización o autenticación?
Autorización o autenticación?
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.
Elementos que intervienen en una
transacción OAuth
• Scopes / ámbitos / alcances
• Roles / Actores
• Grant Types (Tipos de autorización)
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.
Actores
En todo escenario de autenticación contamos
con 3 actores o roles que interactúan entre
ellos:
● Aplicaciones (Clients)
● API (Servers)
● Usuario (Owners)
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.
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.
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.
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.
Authorization Code
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.
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
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
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
Authorization Code 5/6
Y el cliente finalmente recibe su token:
{
“access_token”: “RsT5OjbzRn430zqMLgV3Ia”
}
Authorization Code 5/6
Y el cliente finalmente recibe su token:
… o un error:
{
“access_token”: “RsT5OjbzRn430zqMLgV3Ia”
}
{
“error”: “invalid auth_code”
}
Authorization Code 6/6
Con el token en su poder, el cliente ya está
preparado para acceder a recursos.
Implicit
Implicit 1/4
Se usa con aplicaciones basadas en
navegador (aplicaciones Javascript
mayormente).
Es MUY similar al Authorization Code, solo que
más simple.
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
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
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
Implicit 4/4
Con el token en su poder, el cliente ya está
preparado para acceder a recursos.
Password
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.
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
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
Client Credentials
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”.
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
Realizar llamadas autenticadas
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?
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
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
Implementar OAuth en Symfony2
• FOSOAuthServerBundle
Implementar OAuth en Symfony2
• FOSOAuthServerBundle
bshaffer/oauth-server-php
Dispone de un bundle para Symfony.
Fácilmente integrable en:
• Silex
• Slim
• Drupal
• Laravel
Zend lo ha utilizado para Apigility
Preguntas…?
O cervezas???
Preguntas…?
O cervezas???
Gracias por venir!!!