There are three methods for using the REST API: Basic Authentication, Personal Access Tokens, and OAuth2. Security increases in this order. Basic Authentication is not recommended. An exception is when access is permitted strictly from Workflow Apps within the same workflow infrastructure. Personal Access Tokens have expiration dates and are safer than Basic Authentication, making them an option to consider when you want to use the REST API easily or for production integrations that run infrequently. Use OAuth2 for integrations that operate regularly. In OAuth2, if a token is not refreshed even once within 35 days, the Refresh Token expires and re-authorization by the User is required, making it unsuitable for integrations with long intervals between executions.
The method for disabling access differs for each approach. In this article, from the perspective of a System Administrator, we explain where to disable and where to check each of the three methods in order. Next, we cover calls from browsers, restrictions on connection sources, and reviewing logs.
Under [System Settings] > [API Clients], there are two tabs: [API Access via Basic Authentication] and [OAuth2 Client List]. [User Management Authority] is required to modify per-User Basic Authentication permissions under [User List]. [System Administrator Authority] is required to open [API Clients] and [CORS]. [CORS] is available in the Professional Edition and higher.
Basic Authentication
Basic Authentication can be disabled via a system-wide setting. This setting takes precedence over per-User settings. Under [API Clients] > [API Access via Basic Authentication], choose from the following three options:
| Option | Meaning |
|---|---|
| [No system-level restriction; follow per-user settings] | Operates according to per-User permission settings |
| [Allow only access from workflow apps in this environment (deny external)] | Can be used only from automated Steps within the same workflow infrastructure. Cannot be used from external systems |
| [Deny entirely (regardless of per-user settings)] | No one can use the REST API via Basic Authentication |
If Basic Authentication is not used anywhere, select [Deny entirely (regardless of per-user settings)]. If it is used only by Workflow Apps within the same workflow infrastructure, select [Allow only access from workflow apps in this environment (deny external)] to stop access from external systems.
Check which Users can access the REST API via Basic Authentication in [User List]. Displaying [Basic Authentication] in the [Column] settings shows whether permission is granted for each User in the list. For Users not involved in REST API integrations, revoke permission on their details screen opened from [User List]. Note that Basic Authentication uses the User Name and password found under the User’s own [Account Settings] > [Password] > [API Password (Basic Authentication)], which is distinct from the web login password.
Personal Access Tokens
A Personal Access Token is a token for accessing the REST API with assigned scopes and an expiration date, which each User can issue personally. Issuance and revocation are performed under the User’s own [Account Settings] > [Password] > [API Password (Personal Access Token)].
Because Personal Access Tokens are a different method from Basic Authentication, they cannot be stopped by Basic Authentication settings (neither system-wide nor per-User). To disable them across the entire system, deactivate “Personal Access Token (System Managed)” located in [OAuth2 Client List]. Deactivating it stops not only new issuances but also access via already issued tokens. If re-enabled later, tokens within their expiration dates can be used again. To stop already issued tokens while still allowing new issuances, execute [Revoke All Authorizations] on the details screen for “Personal Access Token (System Managed)”. How to interpret [Authorization Status] on the details screen is explained in the next section, “OAuth2”.
OAuth2
There are two types of OAuth2 clients: pre-registered clients and CIMD (Client ID Metadata Document) clients that do not require advance registration. Pre-registered clients are registered by administrators in [OAuth2 Client List] before use. CIMD clients connect simply through User authorization without requiring prior registration by an administrator.
Check pre-registered clients in [OAuth2 Client List]. The [Name], [Client ID], [Status], and [Creation Date/Time] of registered clients are displayed. For unused clients, deactivate or delete them. Deactivating a client immediately invalidates issued Access Tokens, but it can be re-enabled later. Deleting a client permanently clears the client’s information and tokens. Pre-installed clients provided by default in the workflow infrastructure cannot be deleted; they can only be deactivated. For unrecognized registered clients, deactivate them without deleting, and take action following “When a Breach Is Suspected” in “Checking Questetra BPM Suite Settings and Logs Against Unauthorized Access (Coming Soon)”.
Check [Authorization Status] on each client’s details screen. [Authorized Users], [Scope], and [Last Token Issued] are displayed. Confirm whether the number of authorized Users matches the number of people actually using that client, and check when the last token was issued. Authorizations granted to that client can be revoked all at once using [Revoke All Authorizations].
Check CIMD clients under [CIMD Clients]. [CIMD Clients] is a section at the bottom of the same screen as [OAuth2 Client List], where clients connected via CIMD are displayed along with their [Name], [Client ID], [Authorized Users], and [Last Token Issued]. Because they connect without prior registration by an administrator, check for unfamiliar connections and revoke authorizations from their details screens if necessary.
Have individual Users check their own [Connected Apps] as well. Under [Account Settings] > [Connected Apps], Apps to which the User has granted data access are displayed. Have them click [Deactivate] for unused Apps.
Calls from Browsers
Only origins permitted in [CORS] can call the REST API from a browser opening an external site. By default, [Enable CORS] is disabled, and such calls are blocked. Because [CORS] is not available in editions below the Professional Edition, this state remains in effect. When you check [Enable CORS] under [System Settings] > [CORS], browsers visiting sites registered under [Allowed Origin to send cross-origin requests] will be able to call the REST API. Review [Allowed HTTP headers], [Allowed methods], and [Allow sending credentials] as well, and remove origins not used for business operations. For an example of using CORS, refer to “Displaying [My Tasks] on Websites Other than Questetra BPM Suite (CORS Usage Example)“.
Restricting Connection Sources
[IP Address Filtering] is also applied to REST API access. Only networks registered under [Allowed Hosts/Networks] are permitted access to web screens and the REST API. For configuration instructions, refer to “Configuring IP Address Restrictions“.
Reviewing Logs
Under any method, REST API access itself is not recorded in [System Log]. What is recorded are modifications to Users, Organizations, Roles, authorities, and similar entities, as well as [Login Failure] events resulting from authentication failures. For instructions on how to identify in [System Log] whether these occurred via the REST API, refer to “Detecting Suspicious Access from Login Records“.
Related Documentation
- System Settings – API Clients
- System Settings – CORS
- Displaying [My Tasks] on Websites Other than Questetra BPM Suite (CORS Usage Example)
- System Settings – IP Address Filtering
- Configuring IP Address Restrictions
- Detecting Suspicious Access from Login Records
- Checking Questetra BPM Suite Settings and Logs Against Unauthorized Access (Coming Soon)
