Skip to content
Connected Services Framework
Part 2 — Implementation
Markdown

#2. OAuth 2.0 Implementation

Connected Services Framework (CSF) — Part 2: Implementation — Version 2.0

#2.1 Overview

The CSF uses OAuth 2.0 Client Credentials flow for machine-to-machine authentication between MAPs. This is the same approach used by TOTSCo for OTS, ensuring maximum compatibility across the industry.

Each MAP operates as both:

  • An OAuth 2.0 Authorisation Server — issuing tokens to other MAPs that want to access its endpoints
  • An OAuth 2.0 Client — requesting tokens from other MAPs to access their endpoints

During onboarding, MAPs exchange client_id and client_secret credentials with each other.

#2.2 Access Token Request

To obtain an access token, the requesting MAP sends an HTTP POST to the target MAP's token endpoint.

Request URL: https://{fqdn}/oauth2/token

The FQDN is obtained from the oauthTokenURL field in the target MAP's registry (see Directory API).

#Request Headers

HeaderValueNotes
AuthorizationBasic <Base64(client_id:client_secret)>Base64-encoded credentials provided during onboarding
Content-Typeapplication/x-www-form-urlencodedStandard OAuth 2.0 form encoding

#Request Body Parameters

FieldTypeRequiredDescription
grant_typeStringyesalways client_credentials
client_idStringYesClient identifier provided by the target MAP during onboarding
client_secretStringYesClient secret provided by the target MAP during onboarding

Note : A MAP should support client_id + client_secret in both headers and body as per OAuth 2.0 Standard

#2.3 Access Token Response

A successful request returns an HTTP 200 with the following JSON body:

{
  "access_token": "{OAuth2 Access Token}",
  "token_type": "bearer",
  "scope": "default",
  "expires_in": 3600
}
FieldTypeMandatoryDefaultDescription
access_tokenStringYThe bearer token to include in subsequent API requests
token_typeStringYbearerThe type of token issued
scopeStringNdefaultThe scope of access granted
expires_inIntegerY3600Token validity in seconds (typically 1 hour)

#2.4 Using the Access Token

Include the access token in the Authorization header of all API requests:

Authorization: Bearer {access_token}

The token MUST be validated by the receiving MAP on every request, checking:

  • Token signature validity
  • Token has not expired
  • Issuer matches the expected authorisation server
  • Audience/scope is appropriate for the requested resource

#2.5 Token Lifecycle

  • Tokens are short-lived (typically 1 hour)
  • MAPs SHOULD cache tokens and reuse them until close to expiry
  • Client secrets MUST be stored securely (e.g., in environment variables or secret vaults, never in source code)
  • Client secrets SHOULD be rotated periodically

#2.6 Error Responses

The following errors may be returned during token generation:

HTTP CodeErrorRoot Cause
400Bad RequestInvalid request parameters or missing required fields
401UnauthorisedIncorrect client credentials (client_id or client_secret)
404Not FoundIncorrect token generation URL
405Method Not AllowedIncorrect HTTP method (must be POST)
415Unsupported Media TypeMissing or incorrect Content-Type header

#2.7 Security Requirements

RequirementMandatory
All token exchanges over TLS 1.3Yes
Validate token signature, issuer, and audience on every requestYes
Limit token scope and lifetimeYes
Never expose client secrets in frontend code or logsYes
Store client secrets in secure vaults or environment variablesYes
Rotate client secrets periodicallyRecommended
Use Proof Key for Code Exchange (PKCE) for public clientsIf applicable