CME Group uses OAuth 2.0, a protocol that supports secure decoupled Authentication (Identity verification) and Authorization (Access Level), to access various CME Group Web Service APIs.

OAuth 2.0 Service Adoption Steps

A registered OAuth 2.0 API ID and password is required to access CME Group Web Service APIs.

...

Client systems must use a HTTP POST method to the following URLs to obtain an authorization token to the relevant environment.

...

In the HTTP POST method, the following Header parameters are required:

• Content-Type should be set to "application/x-www-form-urlencoded"

• Authorization should be set to "Basic Base64encoded(APIID:Password)"

The Body of the HTTP POST must have grant_type=client_credentials.

Example

The following is an example authorization token request.

...

The response with an access token will contain the following properties:

• access_token - The access token string to use on requests to the CME Group Web Service API(s).

• token_type - Defines the type of token, typically just the string “bearer”.

• expires_in - Defines the duration of time, in seconds, until the access token expires and a new token must be obtained.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
  "access_token":"tokenValue",
  "token_type":"bearer",
  "expires_in":1799,
}

...

HTTP 40x response - Client side error. Example error descriptions include:

• Incorrect grant_type value or grant_type is missing.

• Incorrect Content-Type header value or Content-Type is missing.

• Invalid credentials in the Authorization or incorrect encoding.

HTTP 400 Example

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
    "error_description": "grant_type is required",
    "error": "invalid_request"
}

...

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
  "error_description": "Invalid client or client credentials.",
  "error": "invalid_client"
}

Authorization with CME OAuth 2.0 Service

CME Group supports multiple business APIs that use the OAuth 2.0 Authentication service. The business APIs could be either stateless web services or stateful web socket implementations.

The following section describes how a client system can use the OAuth token obtained in the Authentication section to request business data from Web APIs.

Stateless Web Services

CME Group supports multiple business APIs which deliver data over HTTPS using GET method as well as provide the capability to update server side data with POST method.

GET method request

In issuing a request, client systems should include “Authorization” HTTP header parameter. The value of this parameter should be “Bearer <value of the Authentication token>”.

The request is issued against a specific endpoint of the host server which is servicing the business API.

GET <Endpoint> HTTP/1.1
Host: <HostName>
Authorization: Bearer <value of the Authentication token>

Stateful Web Socket

CME Group support business APIs that use a stateful Web Socket connection to send and receive data.

Web Socket Initiation

During the initiation of the Web Socket connection clients systems should include the “Authorization” HTTP header parameter. The value of this parameter should be “Bearer <value of the Authentication token>”.

Request URL: <Web Socket service URL>
Request Method: GET
Status Code: 101 Switching Protocols
Request Headers
Connection: Upgrade
Upgrade: websocket
Authorization: Bearer <value of the Authentication token>
Host: <HostName>