Goal

This document describes how OAuth 2.0 works when using it in the Denodo Platform and how it has been implemented for Single sign-on, web services published through Virtual DataPort and for 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, desktop applications, and mobile devices.

The main benefit of using OAuth 2.0 is that the user doesn’t need to share 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: It is the user who authorizes an application to access her 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 and it 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. 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, and if valid, issues an Access Token and 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, and if valid, serves the request.

OAuth 2.0 Single Sign-on - Denodo Security Token

Denodo Security Token Server is a centralized system that delegates the 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.

From Denodo 8.0 OAuth 2.0 can be used to delegate the authentication into multiple web applications (such as the Design Studio or the Solution Manager Web Tool) while logging in once and without 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. Temporal 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 on it.

Token Validation in Virtual DataPort

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

In both approaches there is the same goal:

1. Validate if 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 client/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 “scopes” of the Token. 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 Text File (DF), you have to specify a path to the data files. OAuth 2.0 is available when selecting HTTP path type in order to retrieve the information through an HTTP request.

The authentication process is the same as the Northbound authentication, but in this case, the Virtual DataPort Server acts as a client who wants to access a protected resource. On the other hand, the Resource Server is the Data Source that contains the information that our client wants to retrieve.

In this case, the Resource Server is the one who 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