Using a REST STS Bearer Token with the Document Service REST API

Overview

This topic provides a high level overview of using the REST STS Bearer Token when making Document Service REST API calls.

These Integration APIs are versioned to provide integrators with the flexibility to leverage future updated APIs based on their integration workflows and development processes. All APIs use OAuth 2.0 as the authorization framework to enable the application to obtain limited access to a user account on an HTTP service. Once the application is registered, the service will issue client credentials in the form of a client identifier and a client secret. The Client ID is a publicly exposed string that is used by the service API to identify the application and is also used to build authorization URLs that are presented to users. The Client Secret is used to authenticate the identity of the application to the service API when the application requests to access a user's account and must be kept private between the application and the API. To use the OAuth 2.0 client credential flow authentication, a Client ID and Client Secret Certificate must be registered per account in Security Administration. To call an API protected with OAuth 2.0 security, you need to present a valid access token. To receive an access token, the client POSTs an API call to the Security Administration Application using the Account’s Client ID and Client Secret Certification (Base64 encoded format) registered values, along with the parameters grant_type=client_credientials and scope=<specific scope(s)>.

Note:

Refer to the OAuth Client Credential Flow Setup documentation for additional instructions.

REST Header

The REST Header contains pre-populated information that is included in the REST call; users must enter values for the Content-Type and WKFS-ClientCertificate parameters. See API Request Parameters for more information on using these parameters.

The sample below is typical header within a REST API request.

Content-Type: application/x-www-form-urlencoded
WKFS-ClientCertificate: <base64_encoded_certificate_goes_here>
User-Agent: PostmanRuntime/7.26.8
Accept: */*
Postman-Token: 3d390609-049e-462d-85d6-3ece32c43871
Host: ct-expere.wolterskluwerfs.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 172

Request Body

The body of the request should contain the grant_type, user's client (i.e. account) ID and appropriate scope(s). See API Request Parameters for more information on using these parameters.

The sample below is a typical request body within a REST API request.

grant_type: "client_credentials"
client_id: "<client_id_goes_here>"
scope: "<scopes_go_here_space_delimited>"

Using Scopes: Users must enter the appropriate scopes in the "scope" parameter in the request body. For more information on scopes, click here.

Sample Response

The response returns the access token (as the bearer token), the amount of seconds that the token will expire (i.e. 3600), the token type, and specific scopes that were entered in the request body. See API Request Parameters for more information on using these parameters.

The sample below is a typical response within a REST API request.

{
    "access_token": "<bearer_token_returned_here>",
    "expires_in": 3600,
    "token_type": "Bearer",
    "scope": "wk-dgs-core-read wk-dgs-core-write wk-ezcfg-def-data-read wk-ezcfg-pkg-pkt-read"
}