Authorizing a request

Search…
A walk-through the authorization options in Advanced REST Client.
Most APIs requires some form of authentication. The most popular and successful authorization schemes are based on adding the authorization header with the authorization value. Most commonly used scheme is OAuth2 which uses a Bearer token containing user credentials. This section describes authorization options available in the Advanced REST Client.
Authorization editor
The authorization editor allows you to enable multiple authorization strategies. Each strategy can be configured with the values required in the authorization scheme. For example, the basic authorization requires to provide a user name and optional password.
Authorization editor in Advanced REST Client
In the authorization scheme drop-down list you can select the authorization scheme you want to edit. In the list, you can also enable and disable the authorization.
Always enable the authorization scheme you edit to make sure it is used during the request.
Basic authentication
The basic authorization scheme requires the user to provide at least the username. Password is optional. This scheme is rarely used in production systems, but sometimes it can be found in internal systems and the development environment.
Basic authentication options
The authorization header is constructed when the request is being made. The request engine serializes the generated value into the authorization header.
Bearer authentication
The bearer authentication was developed as part of the OAuth 2 authorization scheme. This editor allows you do enter a received from an authentication service the bearer token. The application adds the corresponding value to the authorization header.
Bearer token authentication options
The value is masked by default for added security. You can preview the value with the toggle button in the input field.
NTLM authentication
The NTLM authentication is used in Microsoft NT domains. It requires to make a series of requests with a challenge and responses. After the authorization succeeds then a proper authorization header is added to the request. Because all of this happens on the same connection, the support for it is built into the transport mechanism of the ARC's request engine. 
NTLM authentication options
OAuth 1
We dropped support for OAuth 1 authentication scheme in ARC version 16.
OAuth 2
OAuth 2 is arguably the most successful authentication scheme out there. It allows requesting for the authentication token from the authentication server (bearer token). ARC supports all default grant types specified in the OAuth 2 specification. Usually, you have to provide at least the client id parameter you receive from the client registration process. Then depending on the selected grant type, you may need to add other values.
Implicit grant type (access token)
The implicit grant type allows you to request a token without a server component. It also does not require providing the client secret parameter, making it a great fit for web applications without a server component (like ARC itself).
The implicit grant type is not considered safe anymore. Clients should use different grant types like code with PKCE extension.
Implicit authentication scheme
In this grant type, you have to provide the client id and the authorization URI parameters. You can optionally include the scope parameter.
The client id is received from the client registration page of the authentication server. You can find the authorization URI in the authentication provider's documentation.
To add a scope to the request, enter the scope value into the scopes' input filed and press Enter or the add button inside the field.
The redirect URI must be registered in the authentication server. ARC gives you a default redirect URI you can use. You can also change the redirect URI in the application settings. Currently, a per-request redirect URI is not supported.
When ready press the Request Access Token button to initialize the authentication flow. This will open a popup set in the Authorization URI filed with OAuth 2 parameters computed from the parameters. ARC generates the state parameter automatically. Once the token is received, it is visible in the editor.
Received authentication token
You don't need to request the token in the editor. This is to test the configuration. When the token is not set, the authentication process starts automatically when you send the request.
Authorization Code grant type
It works the same way as the implicit flow, but the popup does not return the token but a code that has to be exchanged for token. To do this, two additional parameters are required: client secret and access token URI.
Authorization code authentication scheme
The client secret, similarly to the client id, can be read from the client registration page. It is usually a random string of characters.
The access token URI, similarly to the authorization URI, can be found in the provider's documentation.
The use PKCE extension option instructs the authentication library to enable PKCE extension when requesting the token in the code exchange process. It adds additional security, but it has to be supported by the authentication server.
Client credentials grant type.
With this scheme, you don't have to provide the authorization URI as this type can be performed without user interaction. The client id and secret are optional.
Client credentials authentication scheme
The credentials location drop-down allows you to configure where the client id and the secret should be placed. It can be the body with the rest of the parameters or in the authorization header. This should be noted in the authorization provider's documentation.
 Password grant type
The password grant type is not considered safe anymore. Clients should use different grant types like code with PKCE extension.
 The password grant type is similar to the client credentials, but it requires you to provide the username and password.
Password authentication scheme
Device Code grant type
This grant type is not yet supported.
Refresh Token
This grant type is not yet supported.
Client certificates
The client certificates authentication allows you to select one of the installed inside the application certificates to authenticate the user. The certificates are stored in the application's internal storage, so no one other than ARC can access them.
In the first step, you have to import a certificate into the application. 
Import a certificate button
Press the import certificate button or use the Request > Web session > Client certificates menu. The client certificates manager screen opens.
Client certificates manager
Click on the import a certificate button. We support the P12 and PEM certificates at the moment. Depending on the type of the certificate you have, select the right option for you.
Selecting client certificate type
PKCS #12 (P12) certificate import
Importing a P12 certificate
Add a name to the certificate. This name is rendered in the certificates manager and the authorization configuration. If your certificate has a password then toggle the Certificate has password option and enter the password in the password field. To finish, click the import button.
PEM certificate import
PEM certificate import
To import a PEM certificate, you need the certificate file (public certificate) and the private key. If the private key has a password then toggle the Private key has password button and enter the password in the input field. To finish, click the import button.
Using client certificates
Go back to the authorization options. Now you can see there are certificates we imported in the previous steps.
Selected client certificate
Now, select the certificate and enable the authentication scheme. The application handles the certificates just before passing the request into the HTTP request processor.
Body editor
Next - Using ARC
Environments and variables
Last modified 7mo ago
Copy link
Contents
Authorization editor
Basic authentication
Bearer authentication