OAuth Authentication

Denodo supports the protocol OAuth 2.0 for authentication and authorization of users. OAuth is an open-standard protocol that allows client applications to access Denodo without sending the password of the user account. Denodo supports OAuth in:

  • The JDBC interface and the ODBC interface of Virtual DataPort. That is, the client applications that connect to Virtual DataPort with the Denodo JDBC driver or the Denodo ODBC driver can use OAuth authentication.

  • REST and SOAP web services published from Virtual DataPort. You can configure these web services so client application have to use OAuth authentication.

The Denodo JDBC driver supports the OAuth 2.0 protocol for authentication and authorization of users. OAuth is an open-standard protocol that allows client applications to access Denodo without sending the password of the user account.

An application that sends requests to an OAuth 2.0 service (in this case, Virtual DataPort) have to include an access token in the request. This access token has to be obtained by the application from the authorization server. The standard OAuth 2.0 does not define a protocol for the resource server (in this case, the Denodo server) to validate access tokens and to obtain meta-information from them. Several approaches have been developed by the community to bridge this gap. Denodo supports two of them:

  • JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. In this approach, the access tokens sent by applications contain 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.

  • OAuth 2.0 Token Introspection. With this method, the resource server (in this case, the Denodo 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.

In both approaches, the goal is the same:

  1. To 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. Once Denodo has the scopes of the token, it obtains the roles with the same names and executes the request with the privileges granted to these roles.

    Denodo ignores the scopes for which there is no role with the same name.

    If there is not any role with the same name as any of the scopes of the token, the request fails.

Connecting to REST and SOAP Web Service with OAuth Authentication

After enabling OAuth authentication in Virtual DataPort, you can configure REST and SOAP web services of Virtual DataPort to require OAuth authentication. In that case, the client applications that connect to these services need to:

  1. Obtain an access token from the Identity Provider.

  2. Provide this token in the HTTP header “Bearer” of the request:

GET /server/customer360/invoice
Host: https://denodo-server.acme.com
Authorization: Bearer ey1QiOiJsIiJZnl0aESUzI1NiIKVng1dCI6Ikci5HVEZ2ZELCJhJ0eXAiObGstV1Q...

Connecting with JDBC and ODBC with OAuth Authentication

After enabling OAuth authentication in Virtual DataPort, client applications can connect to Virtual DataPort using the Denodo JDBC driver or the Denodo ODBC driver, with OAuth authentication.

Denodo provides two paths to connect to Denodo using OAuth. Depending on the one you choose you have to configure the connection differently.

Path #1: The Client Application Provides an OAuth Token

The client application obtains an OAuth access token and passes it to the driver. Then, the driver uses this token to connect to Virtual DataPort, instead of using user/password.

This path is meant to be used by client applications that have the ability to obtain access tokens to connect to Virtual DataPort. This client application can obtain this access token for itself or on behalf of the end user of the application.

Path #2: The Driver Obtains an OAuth Token on Behalf of the User

If the client application does not have the ability of obtaining OAuth tokens, the driver can obtain one on behalf of the application, if the Identity Provider of your organization supports the Resource Owner Password Credentials OAuth flow.

In this case, you configure the connection with information about the Identity Provider. That is, the URL to request tokens to the Identity Provider, client id and client secret of the application you registered on the Identity Provider, etc.

If you are connecting with JDBC, you provide this information in the driver properties.

If you are connecting with ODBC, you provide this information in the DSN or if it is a DSN-less connection, in the connection properties.

In this case, when the client application wants to open a connection, the driver requests an OAuth token to the Identity Provider and uses the token to establish the connection.

Client applications that connect to Virtual DataPort using the ODBC driver of PostgreSQL will not be able to use OAuth authentication because this feature is part of the Denodo ODBC driver, not the PostgreSQL ODBC driver.

Additional Information

To connect with OAuth with the JDBC driver, read the page Connecting to Virtual DataPort Using OAuth Authentication (Developer Guide). It explains the parameters you have to define to use both paths.

To connect with the ODBC driver, read this:

Other Considerations

When you enable OAuth authentication, you do not disable the other authentication mechanisms. That is, if you also enable Kerberos authentication, some client applications may choose to connect using user and password, others with OAuth and others with Kerberos.

Creating the Roles of the Virtual DataPort Users

Before any user can connect to Virtual DataPort using OAuth authentication, you have to do this:

  1. Create roles in Virtual DataPort and grant them the appropriate privileges.

    Create a role for each type of user you want to have. For example: administrators of Denodo, administrators of project X, administrators of project Y, developers, etc. Then, grant the role “serveradmin” to the role for the administrators of Denodo, grant the privilege ADMIN over the database of the project X to the role for the administrators of this project, etc.

  2. In the Identity Provider of your organization, create groups with the same name as the roles you have created and add the users to the appropriate groups.

For example:

  1. In Virtual DataPort, create the role “denodo_administrator_production” and in the production servers, grant the role “serveradmin” to this role.

  2. In the Identity Provider, create the group “denodo_administrator_production” and add the appropriate users to this group.

To grant users the role “serveradmin”, “assignprivileges” or any of the default roles, you cannot create groups in the Identity Provider with these names and add users to these groups.

For example, if in the Identity Provider you create a group called “serveradmin” and add users to this group, when these users log in to Virtual DataPort, they will not have this role. That is because when a user logs in, Virtual DataPort ignores the groups assigned in the Identity Provider that have the same name as the “default roles”.

The goal of this behavior is to ensure that only the administrators of Denodo grant administrative privileges to users. Otherwise, the administrators of the Identity Provider could grant special privileges to users without going through the approval of the administrators of Denodo.


After doing this, go to the next section to learn how to configure the Denodo server.