Authorizing a request
A walk-through the authorization options in Advanced REST Client.
Last updated
A walk-through the authorization options in Advanced REST Client.
Last updated
Most APIs require some form of authentication. The most popular and successful authorization schemes are based on adding the authorization header with the authorization value. The 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.
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 providing a user name and optional password.
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.
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.
The authorization header is constructed when the request is being made. The request engine serializes the generated value into the authorization header.
The bearer authentication was developed as part of the OAuth 2 authorization scheme. This editor allows you to enter a received from an authentication service the bearer token. The application adds the corresponding value to the authorization header.
The value is masked by default for added security. You can preview the value with the toggle button in the input field.
The NTLM authentication is used in Microsoft NT domains. It requires making 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.
We dropped support for OAuth 1 authentication scheme in ARC version 16.
OAuth 2 is arguably the most successful authentication scheme out there. It allows requesting 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.
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.
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 or in the request editor by clicking on the pencil icon next to the redirect URI label.
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.
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.
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 the token. To do this, two additional parameters are required: client secret and access token URI.
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.
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.
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.
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.
This grant type is not yet supported.
This grant type is not yet supported.
OIDC is a standard that was built on top of OpenID. Because of that, the UI looks and behaves very similar to the OAuth 2.
You start with providing the issues URI in the first field. When the value changes the application download the configuration and pre-populates the UI for you. After proving the client ID and/or client secret you can request the token(s). Depending on the selected Response Type you can have one or more tokens after the authentication result is ready.
`
You can select which token you want to use with the request.
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.
Press the import certificate button or use the Request > Web session > Client certificates menu. The client certificates manager screen opens.
Click on the import a certificate button. We support the P12 and PEM certificates at the moment. Depending on the type of certificate you have, select the right option for you.
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.
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.
Go back to the authorization options. Now you can see there are certificates we imported in the previous steps.
Now, select the certificate and enable the authentication scheme. The application handles the certificates just before passing the request into the HTTP request processor.
