OAuth tokens
The POST /auth/token and POST /oauth2/token endpoints are equivalent: they accept the same application/x-www-form-urlencoded form and return the same response. They support two grants:
| Grant | grant_type | When to use |
|---|---|---|
| Password grant | password | The integration knows the user and password. |
| Token exchange | urn:ietf:params:oauth:grant-type:token-exchange | The integration already has a JWT issued by a provider that the environment accepts. |
Note
Token exchange follows OAuth 2.0 and OAuth 2.1. The password grant is part of OAuth 2.0, but not of OAuth 2.1, and may be disabled in the environment. To follow OAuth 2.1, ask the service administrator to disable the password grant in the API authentication methods and use token exchange or Single Sign-On. See OAuth 2.1 compatibility.
Password grant
read -r -p 'User: ' API_USER
read -r -s -p 'Password: ' API_PASSWORD; printf '\n'
curl -i \
--data-urlencode 'grant_type=password' \
--data-urlencode "username=$API_USER" \
--data-urlencode "password=$API_PASSWORD" \
"$API_BASE/oauth2/token"In addition to validating the password, the password grant applies the environment access rules to the user.
Token exchange
Token exchange trades a source JWT for an API access token. The only accepted subject_token_type is urn:ietf:params:oauth:token-type:jwt.
You must also specify which provider configured in the environment validates the JWT. There are two ways:
read -r -s -p 'Source JWT: ' SUBJECT_TOKEN; printf '\n'
curl -i \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'subject_token_type=urn:ietf:params:oauth:token-type:jwt' \
--data-urlencode "subject_token=$SUBJECT_TOKEN" \
--data-urlencode 'provider=jwt-provider' \
"$API_BASE/auth/token"Provider rules:
- the value is the identifier of the provider registered by the administrator, and it does not need to match the JWT
issclaim; - if you send both the
providerfield and the header, theproviderfield takes precedence; - the
X-STCPDIRECTLINK-JWT-ISSUERheader is used only in token exchange and does not authenticate protected routes.
Impersonation token
Technical integrations that need a long-lived credential can use an impersonation token instead of obtaining a token on every run.
- The token is generated by the environment administrator in the Riversoft® STCP DirectLink supervision interface, for a technical user.
- It carries a session identifier registered for the user. On every call, the API checks this identifier; when the token is replaced, the previous one is no longer accepted.
- Use it as a Bearer token on protected routes:
Authorization: Bearer <token>.
Warning
Treat the impersonation token as a privileged credential: keep it in a secrets vault, record its owner, validity and scope, define its rotation and do not reuse it across environments. It does not replace interactive sign-in.
Response
Both grants return the same format, with Cache-Control: no-store:
{
"access_token": "<token>",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "https://api.example.com/directlink/v2"
}| Field | Description |
|---|---|
access_token | Token to send in the Authorization: Bearer header of protected routes. |
issued_token_type | Type of the issued token: OAuth access token. |
token_type | How the token is presented: Bearer. |
expires_in | Token validity, in seconds. It depends on the environment configuration; 3600 is only an example. |
scope | URI of the API configured in the environment. It does not represent a list of permissions. |
Use the token as shown in Session and logout.
Errors
When the grant or the source token is not accepted, the API responds 400 with a body in OAuth format:
{
"error": 400,
"error_description": "<reason>",
"error_uri": "<api-uri>"
}The error field is numeric and identifies the condition reported by the validation. See Codes and events.