--- title: "How to authenticate an A2A application" slug: "how-to-authenticate-an-application-in-a2a" updated: 2026-11-03T14:57:58Z published: 2026-11-03T14:57:58Z canonical: "docs.senhasegura.io/how-to-authenticate-an-application-in-a2a" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt > Use this file to discover all available pages before exploring further. # How to authenticate an A2A application This document provides a step-by-step guide on how to authenticate an application created in the **A2A** module using a REST or HTTP client of your choice. Although **OAuth 2.0** is the recommended authentication method, the module also supports secure integrations with other protocols such as **OAuth 1.0** and **AWS**. ## OAuth v1.0 authentication **OAuth v1.0** is an authentication method that uses a set of `consumer_key`, `consumer_secret`, `token_key`, and `token_secret` to identify and authorize application access. ## Prerequisites - A previously added application that uses **OAuth v1.0** as the authentication method and a previously added authorization for this application. Learn more at [How to manage applications in A2A](/v4-2/docs/how-to-manage-applications-in-a2a) and [How to manage authorizations in A2A](/v4-2/docs/how-to-manage-authorizations-in-a2a). --- ### Obtain request parameters for OAuth v1.0 To make requests using **OAuth v1.0**, the following parameter values are required: - `consumer_key` - `consumer_secret` - `token_key` - `token_secret` To find these values, follow the steps below: 1. On Segura™, in the navigation bar, hover over the **Products menu** and select **A2A**. 2. In the side menu, select **Applications**. 3. In the application list, find the desired application or use the filter **Authentication method > OAuth 1.0**. 4. In the **Actions button**, click **Authorizations**. 5. On the **Application Authorization** screen, find the desired authorization or use the search filters. 6. In the **Actions button**, click **View**. 7. Click **Show** in the fields **Consumer Key**, **Consumer Secret**, **Token**, and **Token Secret** to view the information. 8. Copy the information and store it in a safe location. ### Make a request using OAuth v1.0 There are several ways to make an authentication request using **OAuth v1.0**. In the example below, Python is used for demonstration. Use the following script: ``` import requests import urllib3 from requests_oauthlib import OAuth1 def make_oauth1_request(): url = "https:///" consumer_key = "CONSUMER_KEY" consumer_secret = "CONSUMER_SECRET" token_key = "TOKEN_KEY" token_secret = "TOKEN_SECRET" oauth = OAuth1(consumer_key, consumer_secret, token_key, token_secret) try: response = requests.get(url, auth=oauth, verify=False) if response.status_code == 200: print("Request was successful!") print("Response:") print(response.text) else: print("Request failed with status code:", response.status_code) except requests.exceptions.RequestException as e: print("An error occurred:", e) if __name__ == "__main__": urllib3.disable_warnings() make_oauth1_request() ``` Info When making a request, replace the **ENDPOINT** field with the desired Segura™ endpoint, such as ``` /api/pam/credential ``` or ``` /api/pam/device ``` The parameters - `consumer_key`, `consumer_secret`, `token_key`, and `token_secret` - previously obtained must be included in the request header, not in the body. **Parameters** The table below provides a list of required and optional authentication parameters. | Field | Required | Description | | --- | --- | --- | | **oauth_signature*** | Yes | A unique character string that acts as a signature for a request. For more information, see [create a signature](https://datatracker.ietf.org/doc/html/rfc5849#section-3.4). | | **oauth_version*** | Yes | Ensure the version value is set to 1.0. | | **oauth_signature_method*** | Yes | The name of the signature method used by the client to sign the request. Set the method to **HMAC-SHA1**. | | **oauth_consumer_key*** | Yes | The value of the previously obtained `consumer_key`. | | **oauth_token*** | Yes | The value of the previously obtained `token_key`. | | **oauth_consumer_secret*** | Yes | The value of the previously obtained `consumer_secret`. | | **oauth_token_secret*** | Yes | The value of the previously obtained `token_secret`. | | **oauth_nonce** | No | A unique, random value generated by the client application for each request. | | **oauth_timestamp** | No | The number of seconds since January 1, 1970, at 00:00:00 GMT, used to generate a timestamp signature. | Info More information about the parameters above in [The OAuth v1.0 Protocol RFC](https://datatracker.ietf.org/doc/html/rfc5849#section-3.4). ## OAuth v2.0 authentication **OAuth v2.0** is an authentication method that uses a `client_id` and a `client_secret` to request a time-limited `access_token` and access Segura's® resources. ## Prerequisites - An application added that uses **OAuth v2.0** as an authentication method and an authorization previously added for this application. Learn more in [How to manage applications in A2A](/v4-2/docs/how-to-manage-applications-in-a2a) and [How to manage authorizations in A2A](/v4-2/docs/how-to-manage-authorizations-in-a2a). --- ### Retrieve `client_id` and `client_secret` for OAuth v2.0 To make requests using **OAuth v2.0**, you need to provide the following parameters: - `client_id` - `client_secret` - `access_token` To find these values, follow the steps below: 1. On Segura™, in the navigation bar, hover over the **Products menu** and select **A2A**. 2. In the side menu, select **Applications**. 3. In the applications list, find the desired application or use the **Authentication Method > OAuth 2.0** filter. 4. In the **Actions button**, click **Authorizations**. 5. On the **Application Authorization** screen, find the desired authorization or use the search filters. 6. In the **Actions button**, click **View**. 7. Click **Show** in the **Client ID** and **Client Secret** fields to view the information. 8. Copy the information and store it in a secure location. ### Obtain an access_token for OAuth v2.0 With the `client_id` and `client_secret` keys, you can request the `access_token` and authenticate your application. Follow the steps below: 1. In your HTTP or REST client of choice, such as **Postman**, create a collection. 2. In the **Authorization > Type** tab, select **OAuth 2.0**. 3. In **Configure New Token > Configuration Options > Grant Type**, select **Client Credentials**. 4. In **Access Token URL**, make a request to the appliance endpoint. For example, ``` https://applianceURI/api/oauth2/token ``` 1. In **Client ID**, enter the value obtained in step 7 of the section [Retrieve client_id and client_secret for OAuth v2.0](/v4-2/docs/how-to-authenticate-an-application-in-a2a#retrieve-clientid-and-clientsecret-for-oauth-v20). 2. In **Client Secret**, enter the value obtained in step 7 of the section [Retrieve client_id and client_secret for OAuth v2.0](/v4-2/docs/how-to-authenticate-an-application-in-a2a#retrieve-clientid-and-clientsecret-for-oauth-v20). 3. Click **Get New Access Token** at the bottom of the page. 4. Click **Proceed** to open the **MANAGE ACCESS TOKENS** page and view the **Access Token**. 5. Use this **Access Token** to make requests to the APIs of the **A2A** module in Segura™. Attention By default, Segura™ creates a token valid for 1 hour. ### Request a new access token If necessary, request a new access token for **A2A** using the following URI: ``` POST /api/oauth2/token ``` and the following required parameters: **Parameters** | Field | Description | | --- | --- | | **grant_type** | The value must always be **client_credentials**. | | **client_id** | Value provided by Segura™ and obtained by following the steps in the section [Retrieve client_id and client_secret for OAuth v2.0](/v4-2/docs/how-to-authenticate-an-application-in-a2a#retrieve-clientid-and-clientsecret-for-oauth-v20). | | **client_secret** | Value provided by Segura™ and obtained by following the steps in the section [Retrieve client_id and client_secret for OAuth v2.0](/v4-2/docs/how-to-authenticate-an-application-in-a2a#retrieve-clientid-and-clientsecret-for-oauth-v20). | Send the parameters form-encoded in the request body, with the header `Content-Type: application/x-www-form-urlencoded`. The endpoint does not accept a JSON body. A JSON body returns `401` with the error `unsupported_grant_type`. **Request example** ``` POST /api/oauth2/token Content-Type: application/x-www-form-urlencoded grant_type=client_credentials&client_id=765299ec425cf0255badc739c2dce1b10634973e1&client_secret=f13aeddeb57f262835871dab5d839b70 ``` **Expected response** ``` { "token_type": "Bearer", "expires_in": 3600, "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiIzY2E4YTk4ZDkwNzU0MzgxMjMzNGY3ZjVkYmFmY2E2NTA1ZTMzMTlmYiJ9.efqHZdlij6sQcj_l9RbNNKxDbf81CbIoTFwdIk", "refresh_token": "def50200b4f8e1c3a9d27e6f05b8c4a1d93e7f2b6c08a5d1e4f7b9c2a6d3e8f1b5c7a0d4e9f2" } ``` Store the `access_token` securely and use it in the subsequent calls for each method. ## AWS Authentication **AWS** is an authentication method that allows applications to access data stored using **AWS Access Keys** and **AWS Secret Access Keys**, along with a unique key generated by Segura™ **DSM**. This method is mainly used for integration with **DevOps** applications. For more information on **AWS** authentication, refer to the [AWS Authenticator](/v4-2/docs/en/dsm-how-to-configure-authenticators) documentation. ## Requests and responses Requests are made using HTTP methods such as ` GET`, ` POST`, ` PUT` and ` DELETE`. Parameters include `id`, `identifier`, `hostname`, `username`, among others, and depending on the API call, can be sent in the **path** of the URL or in the request **body**. Responses are returned in JSON format, making it easy to analyze and manage data provided by the API. **Example**: When making a request to the endpoint `GET` `/api/pam/device/14`, the API returns the data of the device whose `id` is `14`. ``` { "code": 200, "response": { "status": 200, "message": "Device 14", "error": false, "error_code": 0, "detail": "", "mensagem": "Device 14", "erro": false, "cod_erro": 0 }, "tenant": "test", "device": { "id": "14", "hostname": "API device", "ip": "10.66.33.17", "model": "Gmail", "type": "Desktop", "vendor": "Linux", "site": "AWS", "device_domain": "my_device_domain", "connectivities": "HTTP:80,SSH:22,MySQL:65535", "session_remote_config": "HTTP::", "device_tags": "test" } } ``` Each document contains the description of the response body fields. Access the document [GET | List a device by [id]](/v4-2/docs/api-get-list-a-device) to see the description of the fields listed in the response above. ## Errors The API returns standard HTTP status codes and includes error messages in the response body to facilitate understanding and troubleshooting. | Code | Response | | --- | --- | | **2xx** | Successful responses that do not require any action from the user. | | **4xx** | Error responses caused by the absence of a required parameter, for example, and that require corrective action from the user. | | **5xx** | Errors from the Segura™ server that suggest corrective action from the server. | **Example**: The following message returns an error for the case of a device not found. ``` { "code": 400, "response": { "status": 400, "message": "1011: Device not found", "error": true, "error_code": 1, "detail": "", "mensagem": "1011: Device not found", "erro": true, "cod_erro": 1 }, "exception": { "code": 1011, "message": "1011: Device not found", "detail": null } } ``` Refer to the documentation for each method for detailed error descriptions, their possible causes and solutions.