Goal

This document describes how OAuth 2.0 can be implemented in Denodo Platform for single sign-on into web applications, authentication for published web services, and connecting to data sources.

Content

OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account. OAuth 2.0 provides authorization flows for web and desktop applications and mobile devices.

The main benefit of using OAuth 2.0 is that the user does not need to share their username and password with any application.

OAuth 2.0 Roles

• Client: An application that wants to access the user's account. Before it may do so, it must be authorized by the user and the authorization must be validated by the authorization server.
• Resource Owner: The user that authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted.
• Authorization Server: The authorization server hosts the protected user accounts, verifies the identity of the user, and then issues access tokens to the client application.
• Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

OAuth 2.0 authentication in Virtual DataPort Web Applications (Northbound)

1. The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner or indirectly via the authorization server as an intermediary.
2. The client receives an authorization grant, which is a credential representing the resource owner's authorization.
3. The client requests an access token and a refresh token by authenticating with the authorization server and presenting the authorization grant.

1. The refresh token will be used to request a new access token when the current one expires. It will be presented to the authorization server in order to obtain a new access token.

4. The authorization server authenticates the client and validates the authorization grant. If valid, it issues an access token and a refresh token.
5. The client requests the protected resource from the resource server and authenticates by presenting the access token.
6. The resource server validates the access token. If valid, it serves the request.

OAuth 2.0 Single Sign-On - Denodo Security Token

The Denodo Security Token server is a centralized system that delegates authentication to an external identity provider. It takes the authorization object and generates a valid credential so the other applications can use it to gain access across Denodo.

Starting from Denodo 8.0, OAuth 2.0 can be used to delegate the authentication for multiple web applications (e.g. Solution Manager Administration Tool and Design Studio) and to avoid having to have a separate identity and password for each.

This scenario works as follows:

1. Authentication is delegated to an external identity provider.
2. The role is extracted from the delegated authentication object.
3. Temporary credentials are issued, representing the user who has just been authenticated through the external identity provider. These credentials are verified and validated by the Denodo environment and grants the access to it.

Token Validation in Virtual DataPort

The OAuth 2.0 standard does not define a protocol for the resource server to validate access tokens and obtain meta-information from them. Two different approaches to validate access tokens are available in Virtual DataPort.

Both approaches have the same goal:

1. Validate that the access token is valid and did not expire.
2. Obtain the names of the scopes contained in the token. The scopes of a token are, according to the standard:

• A list of space-delimited, case-sensitive strings. The strings are defined by the authorization server.

In the case of Denodo, the scopes are names of roles so Denodo ignores the scopes for which there is no role with the same name.

JSON Web Token (JWT)

JSON Web Token (JWT)  is a JSON-based security token encoding that enables identity and security information to be shared across security domains. In this approach, the JWT sent by clients/applications contains a signature that must be validated in order to grant access to execute the request. After validating the token, it obtains the scopes defined in the token.

A JWT is cryptographically signed so there is a guarantee we can trust it when we receive it, as no middleman can intercept and modify it or the data it holds without invalidating it.

OAuth 2.0 Token Introspection

The resource server sends the access token sent by the client application to an introspection endpoint.

This endpoint returns a JSON document indicating if the access token is valid and meta-information about it, including the token’s scopes. The Denodo server sends a request to this data source every time a client sends a request to a Denodo web service that is configured to use OAuth 2.0 authentication.

OAuth 2.0 Authentication to Data Sources (Southbound)

When creating a data source of type XML, JSON, or delimited file, you have to specify a path to the data files. OAuth 2.0 is available when selecting the HTTP path, which retrieves the information through an HTTP request.

The authentication process is the same as the northbound authentication. However, in this scenario, the Virtual DataPort server acts as a client that wants to access a protected resource. On the other hand, the resource server is the data source that contains the information our client wants to retrieve. Therefore, the resource server needs to validate the provided token.

References

The OAuth 2.0 Authorization Framework

OAuth 2.0 Token Introspection

JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants