With the release of IBM OpenPages 9.1, a useful enhancement has been introduced to the platform’s security and integration capabilities: support for OAuth 2.0 authentication for the OpenPages GRC REST API. This new feature updates OpenPages posture for enabling secure, scalable, and manageable API integrations for enterprise risk and compliance solutions.
Why OAuth 2.0?
Traditionally, OpenPages supported Basic Authentication and Client Certificate Authentication for API access. While these methods are functional, they come with limitations:
- Basic Authentication requires sending a username and password with each request, which can pose security risks if not handled properly.
- Client Certificate Authentication is more secure but can be complex to manage, especially when dealing with multiple external systems or rotating certificates.
OAuth 2.0, specifically the Client Credentials Flow, is an industry standard protocol which offers a modern alternative that is both more secure and easier to manage. It allows external systems to authenticate using a client ID and secret, without exposing user credentials or requiring certificate management.
How It Works
The new OAuth 2.0 capability in OpenPages 9.1 allows administrators to register and manage multiple OAuth clients. Each client represents an external system or integration point, enabling fine-grained control over API access. In this client credential flow the OpenPages Liberty application server itself acts as the OAuth 2.0 Provider and the the OpenPages GRC REST APIs act as the Resource Server. There is no need for an external OAuth 2.0 Provider, however if you wish to use an external OAuth 2.0 compatible provider instead of the native capability that is supported.
Step 1: Set Up OAuth 2.0 in OpenPages
Before using OAuth, you must configure the OpenPages environment to support native OAuth 2.0. Follow the setup instructions provided in the IBM documentation.
Step 2: Create and Configure OAuth Clients
Using the new administration feature, you can create OAuth clients for each external system or integration. This allows you to:
- Restrict API access to only authorized systems.
- Identify and audit API usage by client.
- Avoid exposing UI user credentials in automated integrations.
Each client is persisted in the OpenPages database and associates each client with a single OpenPages user account.
Once a client is created, a client ID and client secret are generated. These credentials should be stored securely, such as in a secrets manager or encrypted configuration store.
Step 3: Obtain an Access Token
In order for a client to authenticate with the OpenPages REST API, the client sends a POST
request to the token endpoint:
POST https://<HOST_NAME>:<PORT>/oauth2/endpoint/OPOauthProvider/token
Content-Type: application/x-www-form-urlencoded
The Content-Type of the request must be Content-Type: application/x-www-form-urlencoded and the body must provide the required parameters client_id, client_secret and grant_type=client_credentials
The response will include a JSON object with an access_token
:
{
"access_token": "****",
"token_type": "Bearer",
"expires_in": 120,
"scope": "profile"
}
This token is valid for a limited time (default: 120 minutes, configurable via the accessTokenLifetime
parameter in the Liberty OAuth provider settings).
Step 4: Use the Access Token for API Requests
Once you have the token, include it in the Authorization
header of your API requests:
GET https://<HOST_NAME>:<PORT>/opgrc/api/v2/types
Authorization: Bearer <ACCESS_TOKEN>
This approach ensures that only authorized clients can access the API, and tokens can be rotated or revoked without impacting user credentials.
Sample Python Application
To demonstrate how easy it is to integrate with OpenPages using OAuth 2.0, here’s a simple Python script that retrieves an access token and makes an API call:
import requests
# Replace these with actual values from your OpenPages OAuth client setup
HOST_NAME = "your_openpages_host"
PORT = "your_openpages_port"
CLIENT_ID = "your_client_id"
CLIENT_SECRET = "your_client_secret"
# OAuth 2.0 token endpoint
token_url = f"https://{HOST_NAME}:{PORT}/oauth2/endpoint/OPOauthProvider/token"
# Prepare the payload for token request
payload = {
"client_id": CLIENT_ID,
"client_secret": CLIENT_SECRET,
"grant_type": "client_credentials"
}
# Set headers for the token request
headers = {
"Content-Type": "application/x-www-form-urlencoded"
}
# Request the access token
response = requests.post(token_url, data=payload, headers=headers, verify=False)
if response.status_code == 200:
token_data = response.json()
access_token = token_data.get("access_token")
print("Access token retrieved successfully.")
# Use the access token to make a request to the OpenPages REST API
api_url = f"https://{HOST_NAME}:{PORT}/opgrc/api/v2/types/SOXDocument"
api_headers = {
"Authorization": f"Bearer {access_token}"
}
api_response = requests.get(api_url, headers=api_headers, verify=False)
if api_response.status_code == 200:
print("API request successful. Response:")
print(api_response.json())
else:
print(f"API request failed with status code {api_response.status_code}")
print(api_response.text)
else:
print(f"Failed to retrieve access token. Status code: {response.status_code}")
print(response.text)
To run this python file you must install the requests
library with your python package manager and modify the script with the values for openpages host, openpages port, client id and client secret. This example is intended purely for demonstration purposes.
Platform Support and Considerations
It's important to note that OAuth 2.0 authentication in IBM OpenPages 9.1 is supported for:
- IBM OpenPages REST API V1 and V2
- IBM OpenPages on-premises deployments
- IBM OpenPages on Cloud (hosted by IBM)
However, for IBM OpenPages Native SaaS deployments—whether hosted on AWS or IBM Cloud—the authentication mechanism is different. In these environments, REST API access requires generating an IAM token using an IBM Cloud API key.
To authenticate in Native SaaS environments, follow the instructions provided in the IBM Cloud documentation:
Generating IAM tokens using an IBM Cloud API key
This distinction ensures that authentication methods align with the security models of each deployment type, providing flexibility while maintaining robust access control.