# Authenticating With OAuth2 And Request Actions
It becomes challenging for REST testing tools to authenticate the user when the OAuth2 authorization scheme is applied to an API. OAuth 2 is a multi-step process that requires user input, a valid session on the authorization server, and transferring response data from a response to another request. Advanced REST Client has request actions and cookie sessions that allow automating this process so you will spend less time managing sessions and tokens, and do more with APIs.
In short summary, OAuth2 requires you to have a valid session on the authentication server, then you have to obtain an authorization token using one of predefined or custom authorization methods (token grant type). The token must be used in an HTTP request that requires authenticated user, usually by putting it into the *Authorization* header (*access\_token* query parameter is also used instead of the header). This article focuses on obtaining an implicit grant type token (I am calling it browser flow because it doesn’t require a server component and is designed to work in browsers only) and then using the token in another request without copying/pasting the token all the time.
The first thing we need is to set up a session on the authorization server. Without it, the token request end up being redirected to a login page and therefore the ARC would render this page in response instead of getting token value. Let’s say I want to make a query to Anypoint Exchange to list my API assets. Normally I would go to and log in. Then I would browse the asset in Exchange’s UI. But now I would like to query for my REST APIs assets using the API. To do so we have to set up a session inside the ARC application. Open the application and from the application's menu select Request > Web session >Login to a web service. This brings a prompt to enter the URL of the service.
Now we enter Exchange’s URL () and after clicking the “Open” button it will bring a new window, which is Chromium browser, with loaded Exchange UI. Now we navigate to “Log in” page.
After the login process, the window shows the Anypoint platform page but now we are authenticated.
To confirm we can go to cookie manager in ARC (Request > Web session > Cookie manager) and query cookies by domain mulesoft.com.
To obtain the token we have to call the authorization endpoint. In my case it is `https://anypoint.mulesoft.com/accounts/oauth2/authorize?client_id=AZ8ewU90hIgZMJec&redirect_uri=https%3A%2F%2Fauth.advancedrestclient.com%2Foauth-popup.html&response_type=token`\
The `https://anypoint.mulesoft.com/accounts/oauth2/authorize` is the authorization endpoint. This is where you redirect the user to authenticate with OAuth2. The `client_id` parameter is generated by OAuth2 provider ID when registering an application (here it is not a real client ID, however, this is public information). The `redirect_uri` tells where to redirect the user after login or failure. ARC uses `https://auth.advancedrestclient.com/oauth-popup.html` by default (you can change it in application settings). Finally `response_type` tells the authorization server that this is implicit authentication flow and in response the app expects the token to be set in the redirect URL. Usually, the `scope` parameter is used with OAuth2 request but I will skip it this time.
After providing this URL to ARC’s URL field and executing the request instead of receiving the login page you will see the `redirect_uri` page (the OAuth popup). What is more interesting, the redirect URL contains the `access_token` value in the URL hash part (you may need to toggle “Details” on response view).
Now we have to extract the access token value and put it into an application variable so it can be later used by other requests. We will use the request actions panel to do that. In the Actions tab create a new action in the After response section. We will tell ARC to get the access\_token value from the response URL and then store it as the AnypointToken variable.
The `hash.access_token` value in the “Path to data” field tells to search for the `access_token` parameter in the `hash` part of the response URL. Finally, the configuration tells the application to store the value as the `AnypointToken` variable. Try running the request again. After the response is ready you will see a new variable in the variables preview (right top corner of the app).
At this point, we had authenticated the user in the OAuth service and then we had stored the access token value as an application variable. Now we can use the variable to put the token into the `Authorization` header and make an authenticated call to the API endpoint. Let’s try `https://anypoint.mulesoft.com/exchange/api/v1/profile` which returns profile data for the user. The endpoint requires the bearer token obtained before from the authentication server. In the headers panel put `Bearer ${AnypointToken}` as the value for `Authorization` header.
After calling the endpoint a 200 response is reported back with profile information.
You can use this example for any other OAuth 2 provider. You may need to change authorization parameters like authorization URI, client id, and so on.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.advancedrestclient.com/guides/authenticating-with-oauth2-and-request-actions.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.