Scope OAuth 2.0 Es un protocolo de autorización que permite controlar el acceso por parte de las aplicaciones a los datos de los usuarios sin tener que proporcionar las credenciales. Como ventajas del uso de este framework se pueden citar: Es un protocolo muy flexible que se basa en SSL (Secure Sockets Layer) que cifra las conexiones y permite manejar el access token de forma segura. El acceso es limitado, tanto en tiempo porque los tokens caducan, como en funcionalidad gracias a los scopes. Permite compartir datos sin tener que revelar información personal. OpenId Connect OpenID Connect es una extensión de OAuth por lo que tiene todas las ventajas citadas anteriormente. Las ventajas principales de su uso son: Permitir a las aplicaciones autenticar usuarios sin tener que almacenar y administrar contraseñas. Permitir administrar su propia instancia OAuth que permita el acceso a los recursos ¿Qué no hay que utilizar para securizar nuestras APIs? OAuth 1.0: la versión 2.0 introdujo como mejoras la inclusión de múltiples dispositivos (browsers, nativos, servidores, etc) y sobre todo se sustituyó la firma de las peticiones por TLS. Certificados SSL: solo gestionan la autenticación y son complejos de usar por los clientes. Autenticación básica: solo autentica, no gestiona la autorización y las credenciales incluida la contraseña son fácilmente obtenibles. SAML: no es posible delegar la autorización a un tercero, no hay registro dinámico ni dispone de estructura estándar de identificación. Métodos customizados: no es necesario reinventar la rueda, AOauth es un estándar suficientemente testado y confiable como para usarse, además los desarrolladores ya están habituados a su uso. ¿Cuáles son los flujos de OAuth y cuándo los uso? Conceptos: scopes, tokens y actores El primer paso para comprender los flujos de OAuth y los escenarios de aplicación de cada uno de ellos es comprender algunos conceptos previos como son: los actores que intervienen en los flujos, qué son los tokens y los scopes de acceso. Los actores que intervienen en todos los flujos OAuth son: Los scopes son una lista de identificadores separados por espacios que se utilizan en el proceso de autorización y consentimiento de las APIs en los tokens OAuth, que permiten determinar a qué se solicita acceso por parte de la aplicación y a qué se autoriza acceder por parte del usuario. Por ejemplo: a las fotos, mensajes de usuarios. etc, Los tokens e identificadores que se manejan dentro de OAuth son: El client id es un identificador único que representa la aplicación en el servidor de autenticación. El client secret es una clave secreta que pertenece a la aplicación que es utilizada por el servidor de autorización para comprobar si dicha aplicación está autorizada. Los access token: son claves proporcionadas por el servidor de autorización a la aplicación que permite el acceso a las APIs durante un tiempo limitado tras el cual el token deja de ser válido. Los refresh token: es una clave también proporcionada por el servidor de autorización a la aplicación que permite solicitar nuevos access token después de que estos hayan caducado. Flujos o grant types Los flujos de OAuth también denominados grant types hacen referencia al modo en que una aplicación obtiene un access token que le permite acceder a los datos expuestos a través de una API. La existencia de estos flujos por parte del estándar surge para dar respuesta a todos los escenarios de negocio que se pueden presentar en el consumo de las APIs atendiendo a tres variables: El tipo de aplicación consumidora. Su grado de confianza. Cómo es la interactuación por parte del usuario en el proceso. Client credentials grant type Este flujo representa el caso en el que la aplicación pertenece al usuario, por lo que no hay necesidad de que éste se autentique ni ayude de forma alguna al servidor de autenticación a decidir si el acceso para esa aplicación está garantizado, es decir, el access token que envía el servidor se obtiene autenticando sólo a la aplicación, no al usuario. La principal diferencia con el resto del flujos es que el usuario no interactúa en el proceso, por lo que la aplicación no puede actuar en nombre del usuario, solo en nombre propio.
