Skip to main content
The Open Licensing Protocol (OLP) is the token acquisition layer of the RSL standard. It defines how a crawler authenticates with a license server, requests a license token for a specific piece of content, and receives a credential it can present when accessing that content. OLP extends OAuth 2.0 with licensing-specific semantics — the grant type is client_credentials, and the resulting token type is License rather than Bearer. Where CAP answers “does this crawler have a valid license?”, OLP answers the earlier question: “how does a crawler get a license in the first place?”

​
How OLP works

The protocol involves four parties:
  • Publisher — defines licensing terms in an RSL document
  • Client — a crawler, bot, or AI agent that wants licensed access
  • License Server — authenticates clients and issues license tokens
  • Resource Server — serves the content and enforces access controls
The flow follows a standard pattern:
  1. The client discovers the publisher’s license.xml (via robots.txt, a Link header, or an HTML <link> tag)
  2. The client reads the license, finds the content rule that matches the resource it wants to access, and identifies the license server from the server attribute
  3. The client authenticates with the license server and requests a license token for that content
  4. The license server validates the client’s credentials, checks that an agreement exists, and returns a short-lived license token signed with the server’s private key
  5. The client attaches the token to content requests using Authorization: License <token>
  6. The resource server (or CDN edge) validates the token signature against the license server’s public keys and serves or rejects the request

​
OLP endpoints

The RSL specification defines three endpoints for a conformant license server: token acquisition, token introspection, and a key endpoint for encryption. Supertab Connect implements the token and introspection endpoints. The key endpoint is not yet supported. In addition, Supertab Connect exposes a JWKS (JSON Web Key Set) endpoint that publishes the public keys used to sign license tokens. This allows the CDN edge to verify tokens locally without calling the introspection endpoint on every request — which is how the Supertab Connect SDK performs verification by default.

​
Token acquisition (/token)

This is the primary endpoint. A client sends its credentials along with the license terms and the resource it wants to access. The server authenticates the client, verifies that a license agreement exists, and returns a signed JWT license token. The token endpoint URL comes from the server attribute on the matched <content> element in the publisher’s license.xml. The SDK posts to {server}/token. 
POST /token HTTP/1.1
Host: api-connect.supertab.co
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64(client_id:client_secret)>

grant_type=client_credentials
&resource=/articles/*
&license=<url-encoded matched license block>
The resource is the URL pattern from the content rule. The license is the matched <license> block from the publisher’s license.xml. Client credentials are sent as HTTP Basic Authentication. A successful response: 
HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGciOiJFUzI1NiIs..."
}
The access_token is a signed JWT that the client sends in the Authorization header on subsequent content requests using the License scheme — not Bearer. Supertab Connect signs the token with its private key using ES256. The token’s exp claim determines its lifetime; the SDK caches and reuses it until close to expiry.

​
Token introspection (/introspect)

This endpoint lets a resource server verify whether a token is still valid and whether it grants access to a specific resource. It follows RFC 7662 (Token Introspection) with RSL-specific extensions. 
POST /introspect HTTP/1.1
Host: api-connect.supertab.co
Content-Type: application/x-www-form-urlencoded

token=eyJhbGciOiJFUzI1NiIs...
&resource=/articles/*
The response includes whether the token is active and whether it permits the requested access: 
{
  "active": true,
  "token_type": "License",
  "license": "<?xml version=\"1.0\"?>...",
  "resource": "/articles/*",
  "permitted": true,
  "reason": null
}
When the token is invalid or inactive: 
{
  "active": false,
  "token_type": null,
  "license": null,
  "resource": "/articles/*",
  "permitted": false,
  "reason": "Invalid token claims"
}
In practice, Supertab Connect’s primary verification path does not use the introspection endpoint. Because license tokens are signed JWTs, the CDN edge can verify them locally by checking the signature against Supertab Connect’s JWKS (JSON Web Key Set) endpoint — no per-request call to the license server needed. This is significantly faster and is how the Supertab Connect SDK performs verification. The introspection endpoint exists for cases where a resource server needs server-side validation or does not have access to a JWT verification library.

​
Client authentication

OLP requires client authentication on every token request. Clients register with Supertab Connect and receive a client_id and client_secret. When calling obtainLicenseToken() in the SDK, the client passes both credentials. The SDK sends them to the token endpoint as HTTP Basic Authentication (Authorization: Basic base64(client_id:client_secret)).

​
How Supertab Connect implements OLP

Supertab Connect operates as the license server. When a crawler calls obtainLicenseToken() in the SDK, the following happens under the hood:
  1. The SDK fetches the publisher’s license.xml and finds the content rule matching the requested resource
  2. The SDK sends the matched license block and resource pattern to the token endpoint (derived from the server attribute in the content rule), authenticating with the client’s credentials via HTTP Basic Auth
  3. Supertab Connect authenticates the client, verifies that a license agreement exists between the crawler operator and the publisher, and issues a license token
  4. The token is a JWT signed with Supertab Connect’s private key (ES256), containing the client identity, the merchant system it is licensed against, and an expiry
  5. The SDK caches the token and reuses it until close to expiry
On the publisher side, token verification happens at the CDN edge. The Supertab Connect SDK fetches and caches the public keys from Supertab Connect’s JWKS endpoint, then verifies the JWT signature and claims (expiry, audience, issuer) locally on every request. No round-trip to the license server is needed for verification, which keeps latency low at edge scale.

​
What OLP does not do

OLP does not enforce access. It issues tokens. Enforcement is handled by CAP at the resource server or CDN edge. A token acquired through OLP is useless without a resource server that checks it. OLP does not negotiate terms. The licensing terms are defined in the publisher’s license.xml. OLP is the mechanism for requesting a token under those terms, not for changing them. OLP does not handle payments directly. Commercial terms (pricing, billing) are expressed in the RSL license and managed through the Supertab Connect platform. OLP’s job is authentication and token issuance — the commercial relationship is established before the first token request.

​
How OLP and CAP work together

OLP and CAP are two halves of the same flow. OLP handles the “get a license” side, CAP handles the “prove you have a license” side. A crawler that has never interacted with a publisher will first receive a 401 from CAP with a Link header pointing to license.xml. The crawler reads the license, discovers the license server URL in the server attribute, authenticates via OLP, obtains a token, and retries the content request with the token attached. CAP then verifies the token’s JWT signature against Supertab Connect’s JWKS and allows the request through. Once the crawler has a cached token, subsequent requests skip the OLP flow entirely and go straight to the content request with CAP validation.

Crawler Authentication Protocol

How CAP validates license tokens at the CDN edge.

Acquire Licenses

Practical guide to obtaining tokens and accessing licensed content.