OAUTH 2.0

En 10 minutos o menos.

OAUTH (Open Authorization) es un framework de autorización para acceder a recursos potegidos, en el cual se tienen diferentes tipos de subvenciones o flujos (grant types). Basicamente OAUTH se puede simplificar en dos partes, los cuales serian obtener la autorización y con esta autorización poder acceder al recurso protegido.

Contenido

    Autorización

    La autorización es la parte que mas confusión podria dar, esto debido a que dependiendo del Grant Type usado, el flujo puede variar, sin embargo el objetivo a groso modo consiste en solicitar una autorización. Esta autorización obtenida es una cadena de caracteres alfanúmericos, mejor conocido en ingles como un token (ficho).

    Acceso al Recurso Protegido

    Una vez obtenido el token, el cliente simplemente realiza una solicitud en la ubicación del recurso, y con este token se verifica que el cliente tiene acceso al recurso protegido.

    Ahora que ya tenemos una noción basica y general de como funciona el framework, en las siguientes secciones vamos a indagar en detalles como serían los roles y tipos de subvenciones (Grant Types).

    Roles

    Hay 4 roles, en los cuales un solo actor podria tener varios de ellos y en algunos otros casos ni siquiera existir.

    Usuario

    Es la persona propietaria de la información del recurso o la persona encargada de autorizar el acceso al recurso, en pocas palabras es quien digita el usuario, la contraseña y confirma los permisos que se van a dar. Tambien es conocido como el propietario del recurso.

    Cliente

    Cliente o aplicación cliente, es aquella aplicación que requiere acceder a un recurso, el cual necesita una autorización. Tambien es conocido como consumidor.

    Servidor de Autorización

    Es el servidor que tiene la facultad de poder verificar las credenciales de un cliente o de un usuario y otorga un token al cliente, para que este pueda consumir el recurso solicitado.

    Servidor del Recurso

    Es el lugar final al que una vez un cliente es autorizado, este puede consumir el recurso protegido. Tambien es conocido como el proveedor del servicio.

    Grant Types

    Tipos de subvenciones o mejor conocidos en ingles como grant types, son los flujos existentes que definen como poder obtener un token de autorización. A continuación se van a mencionar los mas comunes, pero cabe decir que existen algunos mas.

    Client Credential

    Este grant type se utiliza cuando se requiere conectar un cliente y un recurso sin un usuario en el medio. En el servidor de autorización se crea una referencia al cliente en el cual se otorgan un client id y client secret y estos se utilizan para obtener el token de acceso.

    Para utilizar este Grant Type es necesario tener en cuenta que el clientId se considera información publica, pero el client secret debe ser confidencial, por lo que esta implementación no debe realizarce en clientes inseguros como aplicaciones frontend o moviles.

    Para conocer en detalle este grant type, te invito a leer Client Credential Grant

    Resource Owner Password Credentials

    Este grant type se utiliza en aplicaciones en los cuales el cliente y el servidor pertenecen a la misma compañia (first-party apps), donde el usuario simplemente ingresa su usuario y contraseña y se retorna un token de acceso.

    Authorization Code

    Este grant type se utiliza en aplicaciones donde el cliente es una app no relacionada con la compañia (Third-party app), se requiere de un usuario para autorizar y por obvias rázones de seguridad el usuario no va a compartir sus credenciales con la aplicación cliente.

    Existe un grant type llamado “Implicit Grant” el cual es exactamente el mismo caso de uso que para este “Authorization Code”, pero en donde el cliente no tiene la posibilidad de preservar la confidencialidad del client secret; ahora la nuevas implementaciones estan utlizando “Authorization Code” y para el problema de confidencialidad se esta utilizando una llave aleatoria por cada petición que luego va a ser verficada por el propio cliente y que para garantizar posibles ataques, se utiliza PKCE el cual define una forma de evitar ataques durante el proceso de autorización.

    Curiosidades

    • OpenID Connect es simplemente una implementación de OAUTH 2.0 en el cual se profundiza en algunos detalles referente a la identidad del usuario.
    • El framework es bastante abierto y no habla detalles, como por ejemplo el token a utilizar o como realizar la validación del mismo, sin embargo es apliamente utilizado JWT.

    Conclusiones

    • OAUTH es un framework de seguridad que define flujos que se deben aplicar según cada caso particular.
    • Suele ser confuso debido a la multiples formas de obtener el token de acceso.
    • Existen muchos otros Grant types, aunque aqui se tocaron los mas comunes, sin embargo algunos otros que se podrian mencionar es el Device Grant o Kerberos grant.
    • El framework siempre esta cambiando, siempre hay nuevas ideas, nuevas necesidades o nuevas vulnerabilidades que se encuentran, por lo que se definen unas bases, pero en cualquier momento puede cambiar.

    Muchas gracias por leer.

    Commentarios

    Leave a Reply

    Your email address will not be published. Required fields are marked *