> ## Documentation Index > Fetch the complete documentation index at: https://connect-docs.supertab.co/llms.txt > Use this file to discover all available pages before exploring further. # Open Licensing Protocol (OLP) > How OLP works, what it provides, how Supertab Connect implements it, and how it connects to CAP enforcement. 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](/licensing/crawler-authentication-protocol) 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 `` 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 ` 6. The resource server (or CDN edge) validates the token signature against the license server's public keys and serves or rejects the request ```mermaid theme={null} sequenceDiagram participant Client as Crawler participant License as License Server participant Publisher as Publisher Client->>Publisher: Discover license.xml Publisher-->>Client: RSL license with server URL Client->>License: POST /token (credentials + license + resource) License->>License: Authenticate client, check agreement License-->>Client: Signed license token (JWT) Client->>Publisher: GET /content (Authorization: License ) Publisher->>Publisher: Verify JWT signature against JWKS Publisher-->>Client: 200 OK + Content ``` ## 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 `` element in the publisher's `license.xml`. The SDK posts to `{server}/token`. ```http theme={null} POST /token HTTP/1.1 Host: api-connect.supertab.co Content-Type: application/x-www-form-urlencoded Authorization: Basic grant_type=client_credentials &resource=/articles/* &license= ``` The `resource` is the URL pattern from the content rule. The `license` is the matched `` block from the publisher's `license.xml`. Client credentials are sent as HTTP Basic Authentication. A successful response: ```http theme={null} 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](https://datatracker.ietf.org/doc/html/rfc7662) (Token Introspection) with RSL-specific extensions. ```http theme={null} 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: ```json theme={null} { "active": true, "token_type": "License", "license": "...", "resource": "/articles/*", "permitted": true, "reason": null } ``` When the token is invalid or inactive: ```json theme={null} { "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. ## Related Docs How CAP validates license tokens at the CDN edge. Practical guide to obtaining tokens and accessing licensed content.