OAuth 2.0

¿Qué es OAuth?

Open Authorization Framework

Permite a aplicaciones de terceros obtener acceso limitado a recursos HTTP, en nombre del dueño del recurso a través de su autorización o bien permitiendo a la aplicación el acceso directamente en su nombre.

¿Por qué OAuth?

¿Seguridad?

APIs: Seguridad

  • BASIC Auth: credenciales del usuario en el header de authentication.
     
  • Mutual Authentication: basada en certificados, implementaciones propias, etc.

¿Aplicaciones de terceros desean acceder a recursos en nuestro nombre?

BO: Before-OAuth

user credentials

user credentials

facebook user profile info

Problemas

  • Aplicaciones de terceros deben guardar las credenciales del dueño del recurso en texto plano para su uso en futuros accesos.
     
  • Si la seguridad de cualquiera de las aplicaciones de terceros se ve afectada, se compromete el password que el dueño del recurso ha entregado y toda la información que este protege.

Problemas

  • El dueño del recurso no puede restringir el tiempo de acceso ni especificar sobre que recurso/s se dará este.
     
  • El único método disponible para el dueño del recurso de revocar acceso es cambiando su contraseña: no es posible revocar granularmente por cliente ni recurso. 

OAuth

Roles

  • Resource Owner
     

  • Resource Server
     

  • Client
     

  • Authorization Server

OAuth define cuatro roles:

Resource Owner

  • Una entidad capaz de conceder acceso a un recurso protegido. 
     
  • Cuando el resource owner es una persona, se lo denomina end-user.

Resource server

  • El servidor donde se alojan los recursos protegidos. 
     
  • Es capaz de aceptar y responder pedidos sobre los recursos protegidos usando access tokens.

Client

  • Una aplicación que realiza pedidos sobre los recursos protegidos en nombre del resource owner y con su autorización.
     
  • El client debe registrarse en el authorization server: este recibe un identifier y un secret.
  • Existen dos tipos de clientes:
    • Confidential Clients: capaces de mantener la confidencialidad de sus credenciales (ej. web server based-application).
       
    • Public Clients: incapaces de mantener la confidencialidad de sus credenciales (ej. web browser-based application, native app).

Authorization Server

  • El servidor encargado de emitir access tokens al client, después de haber autenticado exitosamente al resource owner y haber obtenido su autorización. 
     
  • Un único authorization server puede emitir access tokens válidos para distintos resource servers.

OAuth

Resource
Owner

Authorization Server

Resource Server

Client

Authorization Request 

Authorization Grant

Access Token

Access Token 

Protected Resource

Authorization Grant

Authorization Flows

OAuth define cuatro flujos que determinan como el cliente obtendrá autorización:

Su elección depende del tipo de cliente.

  • Authorization Code
     
  • Implicit
     
  • Client Credentials
     
  • Resource Owner Password

Este flujo esta optimizado para clientes confidenciales.

 

Las credenciales del resource owner nunca se comparten con el client, porque este se autentica a través del user-agent directamente contra el authorization server.

 

El access token es recibido directamente por client sin pasar por el user-agent del resource owner.

Authorization Code

Authorization Code

Resource
Owner

Authorization Server

User-Agent

Client Identifier & Redirection URI

Access Token

Client

User authenticates

Authorization Code

Authorization Code & Client Credentials

-- (A) -- 

  -- >

  -- >

-- (B) -- 

-- (C) -- 

  <-- 

-- (D) -- 

  -- >

-- (E) -- 

  <-- 

|

(B)
|

|

(A)
|

|

(C)
|

 

v
^

Login & authorization page

 -- 

  <-- 

v

Authorization Code

  • response_type (requerido): debe ser "code".
     

  • client_id (requerido): el identificador del cliente.
     

  • redirect_uri (opcional): uri donde el user-agent será redirigido una vez autenticado el resource owner y autorizado el client.  
     

  • scope (opcional): especifica sobre que grupo de recursos se esta pidiendo autorización.
     

  • state (recomendado): un valor autogenerado utilizado por el cliente para mantener estado entre el request y el response. Su objetivo es evitar ataques del tipo CSRF.

Authorization Request Parameters

Authorization Code

Authorization Request Example

GET

Host: api.facebook.com

/v1/oauth/authorize?response_type=code&client_id=s6BhdRkqt3
&state=12fsd3&scope=email&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Authorization Response Example

HTTP/1.1 302 Found
     
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=12fsd3

Authorization Code

  • grant_type (requerido): debe ser "authorization_code".
     

  • client_id (requerido): el identificador del cliente.
     

  • client_secret (requerido): la contraseña del cliente.
     

  • redirect_uri (requerido): si este parámetro fue utilizado en la obtención del authorization code.  

Access Token Request Parameters

Authorization Code

Access Token Request Example

POST

Host: api.facebook.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

/v1/oauth/access-token?grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&client_id=s6BhdRkqt3&client_secret=ñladfj3m1j&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Access Token Response Example

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"Bearer",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
     }

Este flujo esta optimizado para clientes públicos.

 

El cliente no se autentica en el authorization server.

 

El cliente obtiene el access token directamente como resultado del authorization request. 

 

 

Implicit

Implicit

Resource
Owner

Authorization Server

User-Agent

Client Identifier & Redirection URI

Client

User authenticates

Redirection URI with Access Token in Fragment

-- (A) -- 

  -- >

  -- >

-- (B) -- 

-- (C) -- 

  <-- 

|

(B)
|

Login & authorization page

 -- 

  <-- 

v

Implicit

  • response_type (requerido): debe ser "token".
     

  • client_id (requerido): el identificador del cliente.
     

  • redirect_uri (opcional): uri donde el user-agent será redirigido una vez autenticado el resource owner y autorizado el client.  
     

  • scope (opcional): especifica sobre que grupo de recursos se esta pidiendo autorización.
     

  • state (recomendado): un valor autogenerado utilizado por el cliente para mantener estado entre el request y el response. Su objetivo es evitar ataques del tipo CSRF.

Authorization Request Parameters

Implicit

Authorization Request Example

GET

Host: api.facebook.com

/v1/oauth/authorize?response_type=token&client_id=s6BhdRkqt3
&state=12fsd3&scope=email&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Access Token Response Example

HTTP/1.1 302 Found
     
Location: https://client.example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=12fsd3
&token_type=Bearer&expires_in=3600

Intercambia las credenciales del resource owner por un access token.
 

Debe ser utilizado solo por aplicaciones propias, o de terceros con los que se tenga un alto grado de confianza.

Resource Owner Password

Resource Owner Password

Resource
Owner

Authorization Server

Client

Access Token

-- (B) -- 

  -- >

-- (C) -- 

  <-- 

|

(A)
|

Resource Owner Password Credentials

Resource Owner Password Credentials

v

Resource Owner Password

  • response_type (requerido): debe ser "password".
     

  • username (requerido): el username del resource owner.
     

  • password (requerido): el password del resource owner.
     

  • scope (opcional): especifica sobre que grupo de recursos se esta pidiendo autorización.

Authorization Request Parameters

Resource Owner Password

Authorization Request Example

POST

Host: api.facebook.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

/v1/oauth/access-token?grant_type=password&username=user123&password=pass123&scope=email

Access Token Response Example

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"Bearer",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
     }

Client Credentials

El cliente es dueño de los recursos que esta solicitando.
 

El cliente debe ser confidencial.

Client Credentials

Authorization Server

Client

Access Token

-- (A) -- 

  -- >

-- (B) -- 

  <-- 

Client Authentication

Client Credentials

  • response_type (requerido): debe ser "client_credentials".
     

  • client_id (requerido): el identificador del client.
     

  • client_secret (requerido): la contraseña del cliente.
     

  • scope (opcional): especifica sobre que grupo de recursos se esta pidiendo autorización.

Authorization Request Parameters

Client Credentials

Authorization Request Example

POST

Host: api.facebook.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

/v1/oauth/access-token?grant_type=client_credentials&
client_id=client123&client_secret=secret123&scope=email

Access Token Response Example

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"Bearer",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
     }

Conclusiones

  • OAuth presenta un protocolo de autorización para un ambiente distribuido conectado por APIs.
     
  • Fue implementado y es ampliamente utilizado para los proveedores más importantes de servicios: facebook, google, twitter, live, etc.
     
  • Ofrece cuatro tipos diferentes de autorización que cubren los escenarios más comunes.
     
  • Debe implementarse de manera correcta, para que sea exitoso y no presente fallas de seguridad.

¿Preguntas?

Referencias

OAuth 2.0

By Leonardo Regnier

Made with Slides.com

OAuth 2.0

  • 1,336

More from Leonardo Regnier