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.

1 OAuth 2.0 Service Adoption Steps
- 1.1 Authentication with CME OAuth 2.0 Service
  - 1.1.1 Authentication and Token retrieval
    - 1.1.1.1 POST Method Header and Body parameters
      - 1.1.1.1.1 Example
  - 1.1.2 Authentication Responses
    - 1.1.2.1 Successful Response
    - 1.1.2.2 Unsuccessful Response
- 1.2 Authorization with CME OAuth 2.0 Service
  - 1.2.1 Stateless Web Services
    - 1.2.1.1 GET method request
  - 1.2.2 Stateful Web Socket
    - 1.2.2.1 Web Socket Initiation

OAuth 2.0 Service Adoption Steps

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

New Clients of CME Group	Existing Clients with CME Group login

New Clients of CME Group	Existing Clients with CME Group login
Create a CME Group Login. After creating and activating a CME Group Login ID, login to CME Customer Center under My Profile and create an OAuth API ID.	Login to CME Customer Center and under My Profile create an OAuth API ID.

Clients can convert their existing Basic Auth ID to an OAuth ID. This action is irreversible and clients have to re-entitle the converted API ID to use with the desired CME Group Web Service API(s).

Authentication with CME OAuth 2.0 Service

Client systems use the OAuth API ID and Password to obtain an authorization token from the CME OAuth 2.0 service.

Authentication and Token retrieval

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

Detail	New Release	Production

Detail	New Release	Production
OAuth Token Endpoint	https://authnr.cmegroup.com/as/token.oauth2	https://auth.cmegroup.com/as/token.oauth2

Note that the OAuth API ID and Password is specific to the environment and cannot be used across environments.

POST Method Header and Body parameters

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.

POST /as/token.oauth2 HTTP/1.1
Host: auth.cmegroup.com
Content-Type: application/x-www-form-urlencoded
Authorization:Basic base64EncodedValue
grant_type=client_credentials

Authentication Responses

Successful Response

If the request for an access token is valid, the authorization server will generate an access token and send back to the client.

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,
}

Unsuccessful Response

Error responses are returned with an HTTP 40x status code, with error and error description parameters.

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 400 Example

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
    "error": "unsupported_grant_type"
}

HTTP 401 Example

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.

Support for specific GET and POST methods and their corresponding request/response message payloads are fully documented in the appropriate business API.

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>

CME Group Client Systems Wiki

Client API Service Adoption using OAuth 2.0 Protocol