OAuth 2.0 (Spanish)

Matias Gomez Carabias, CSE, Google.


Agenda
●
●
●
●
●
●

Introduccion
Preparacion
Obtención del Token de Acceso
Demo
Detalle de los flujos de OAuth 2.0
Recursos Disponibles


Introduccion


Que es OAuth 2.0?
Has visto esta ventana? Una aplicacion esta solicitando
un acceso a tus datos. Se puede permitir o denegar. Se
puede revocar en cualquier momento.


Que pasa detras realmente?
La aplicacion obtiene un access token y un refresh token
luego de que el dueño lo permite, lo cual es requerido para
acceder a los servicios de Google
{
"access_token" : "yaxx.xxxxxxxxxxxx",
"token_type" : "Bearer",
"expires_in" : 3600,
"refresh_token" : "1/xxxxxxxxxxxxxxxxxxxg"
}

Accediendo mediante un access Token
La aplicacion puede ahora acceder a los datos mediante el
access token.
$ curl -H "Authorization: Bearer ya29.AHxxxxxxxxxxxxxxxxxxxx"
https://www.googleapis.com/plus/v1/people/me
{
...
"id": "108294709823331281952",
"displayName": "Ryuichi Hoshi",
"url": "https://plus.google.com/108294709823331281952",
...

Como funciona OAuth2.
El flujo de OAuth2 se divide en dos partes: Obtener el
access token y acceder el servicio con el token
Obtener un Access token para una
cuenta mediante la aprobación del
dueño de dicha cuenta.

Acceso a los servicios de Google con
el Access Token

Beneficios de usar OAuth 2.0
● Mayor seguridad
○ No se expone el username/password

● Control de Acceso mas especifico
○ Los tokens pueden tener alcance restringido sobre los datos
○ Token facilmente revocable
○ Impacto reducido ante un token comprometido

● Sin CAPTCHAs


Desventajas de ClientLogin
● Exposicion de username/passwords
○ Acceso completo a la cuenta incluyendo la posibilidad de
cambiar el password.

● Revocar un token no es muy sencillo
○ El token dura 2 semanas.
○ Es necesario cambiar la password para invalidar el token.

● El uso de CAPTCHA es a veces requerido
○ No es posible automatizar la autenticación cuando el
CAPTCHA es requerido.

Preparacion


Crear un Client ID y Client secret
Todas las aplicaciones que usan OAuth 2.0 deben estar
registradas
Si aún no fueron creados un Client ID y Client Secret, este
es el primer paso para utilizar OAuth 2.0 para los servicios
de Google


Crear un nuevo proyecto con Google API
Console


Crear un nuevo Client Id de OAuth 2.0


Ingresar el nombre de producto


Elegir el tipo de aplicacion


Ahora, ya hemos generado el Client ID and
Client secret!


Obtener el Access Token


Obtener un Access Token con ClientLibrary
El ClientLibrary de Java tiene una pequeña herramienta
que nos permite obtener un access token


Obtener el Access Token con ClientLibrary
1. Descargar y extraer el proyecto de ejemplo
adwords-axis-examples-1.20.0.tar.gz from downloads

2. Editar el archivo de propiedades
src/main/resources/ads.properties
para incluir la información de OAuth2 (client ID y client secret) e información
básica de la cuenta


3. Compilar y Ejecutar el program
$ mvn -X compile
$ mvn -X exec:java
-Dexec.mainClass="adwords.axis.auth.GetRefreshToken"
Muestra algo como esto:
Paste this url in your browser:
https://accounts.google.com/o/oauth2/auth?
access_type=offline&client_id=xxxxxxxx.apps.googleusercontent.
com&redirect_uri=urn:ietf:wg:oauth:2.0:
oob&response_type=code&scope=https://adwords.google.com/api/adwords

4. Pegar la URL en un browser.
Nota: Es necesario estar logueado con una cuenta de
MCC antes de hacerlo.


5. Aceptar el Request
Se obtendrá un código que puede ser usado par
intercambiar con el nuevo Access Token


6. Insertar el código en el programa que se esta ejecutando
Type the code you received here:
4/-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxwI
Your refresh token is: 1/xxxxxxxxxxxxxxxxxxxxTl1vg
In your ads.properties file, modify:
api.adwords.refreshToken=1/xxxxxxxxxxxxxxxxxxxxTl1vg

7. Agregar el archivo ads.properties con el refresh token


Felicitaciones!
Ahora, su aplicacion tiene un access token y refresh
token!
Client Library automáticamente obtiene un nuevo access
token con el refresh token cada vez que sea requerido.


Demo


Detalle de los flujos de OAuth 2.0


Flujos de OAuth 2.0 soportados
Google soporta los siguientes escenarios de OAuth 2.0
●
●
●
●

Web server applications
Installed applications
Applications on limited-input devices
Service Accounts requires your own Google Apps domain


Diferencias entre los flujos
Registration to API
Console

Registration to
API Console

Use
Client
Authentication Secret
Code

Refresh Token Redirection

Web server
applications

Required

Yes

Required

Available

URL

Installed
applications

Required

Yes

Required

Available

URL, Text

Client-side
applications

Required

-

-

-

URL

Applications on
limited-input device

Required

-

Required

Available

-


Web server or installed application?
Elegir Installed application salvo que se tengan muchas
cuentas que necesitan autorización.
Elegir Web server application cuando se necesita
autorización para muchas cuentas.


Flujo de Web Server Application
Casos:
Se quiere usar autenticación de OAuth 2.0 para cada
cliente en vez de invitarlos al MCC
Beneficios:
El cliente no debe darnos acceso a la UI.
No es necesario vincular las cuentas.
Es posible automatizar el proceso de intercambio mediante
este flujo.

Flujo Installed Application
Casos:
Todas las cuentas se encuentran vinculadas a un mismo
MCC y se quiere usar un solo set de credenciales.
Beneficios:
No es necesario administrar/refrescar los access tokens
para todos los clientes.
Obtener access token para el MCC es suficiente para
acceder a todas las cuentas vinculadas.

Recursos Disponibles


Resources
Docs Links:
Using OAuth 2.0 to Access Google APIs: http://goo.gl/8Gis5
Using OAuth 2.0 for Web Server Applications: http://goo.gl/IghDp
Using OAuth 2.0 for Installed Applications: http://goo.gl/R9xYB
Authentication: http://goo.gl/RUotMR
Google API Console: http://goo.gl/9R42O
OAuth Service Accounts: http://goo.gl/85Hhw9

Preguntas?


OAuth 2.0 (Spanish)

Más contenido relacionado

La actualidad más candente

Similar a OAuth 2.0 (Spanish)

Más de marcwan

OAuth 2.0 (Spanish)