- 1 minute to read
- Print
- DarkLight
- PDF
Default request usage
- 1 minute to read
- Print
- DarkLight
- PDF
Each request in the A2A WebService must have the OAuth Consumer Key and the OAuth Token of the client. In this way, each request URI is similar to the example below:
https://senhasegura/iso/*MODULE*/*FUNCTION*
- MODULE: senhasegura WebService A2A function module
- FUNCTION: Module function
From this point ahead, you must choose which authentication method you will use.
OAuth v1.0 Authentication
Using OAuth v1.0, ensure that oauth_signature_method
the user is HMAC-SHA1
and oauth_version
is settled to 1.0.
oauth_timestamp, oauth_nonce and oauth_signature are mandatory.
You can find the full spec about OAuth v1.0 at RFC 5849.
OAuth v2.0 Authentication
When using OAuth v2.0 authentication, renew the authorization token when it expires. By default, senhasegura creates a token valid for 24 hours.
1. Request a new token for the A2A WebService using the following URI:
POST https://senhasegura/iso/oauth2/token
2. Enter the grant_type, client_id and client_secret values in the requisition body.
- grant_type: the entered value must always be "client_credentials".
- client_id: value informed by senhasegura.
- client_secret: value informed by senhasegura.
You obtain the values to inform in the client_id and client_secret through the menu A2A → Authorizations for the application when clicking on the key icon to visualize the authorization.Client ID viewscreen

3. Your request should look similar to the template below:
{
grant_type: "client_credentials"
client_id: "765299ec425cf0255badc739c2dce1b10634973e1"
client_secret: "f13aeddeb57f262835871dab5d839b70"
}
4. After adding the values, your application will receive a JSON dictionary similar to the following example:
{
"token_type": "Bearer",
"expires_in": 3600,
"access_token": "
eyJ0eXAiOiJKV1QiL0IjoxNTgwNDM2NTk4LCJuYmYiOjE1ODA0MzY1OTgsImV4cCI
6MTU4MDQ0MDE5OCwic3ViIjoiTVRNeE1qQWtTRGRPUVRWV1ozcEVSI6Ijg0OWYw
ZmVhNDI0ZDc5NWUwYTg2MjVlMTdiZWE2YTAyNTQyMzAxNjQzYmRmYTc5ZjYzZDN
hM2U3ZmI5ZjQzbGCJhjg0OWYwZmVhNDI0ZDc5NWUwYTg2MjVlMTdiZWE2YTAyNT
QyMzAxNjQzYmRmYTc5ZjYzZDNhM2U3ZmI5ZjQzYmM2MjRhYzg5YmVhMzFhOGQwI
iwiaWFciOiJSUzI1NiIsImp0ahYzg5YmVhMzFhOGQwIn0.eyJhdWQiOiIzY2E4Y
Tk4ZDkwNzU0MzgxMjMzNGY3ZjVkYmFmY2E2NTA1ZTMzMTlmYiIsImp0aSI6IYmM
2MjRTRzB6ZFZONlZXVXhhVWN2Y1RKdFRXNTVhM05sZGtOd1JHeHllbXR5VEV3eE
5EMD0iLCJzY29wZXMiOltdfQ.efqHZdlij6sQcj_l9RbNNKxDbf81CbIoTFwdIk
ooT5bK14N5iUazrT8jpB_JsgQdQ8RyD5xF_ReKSj4Al7hp1uRXIiuErlKv1FpxY
9oNC44kldlumjyevu87GJ0qzem0RYNc3930UbT-XEYqnQijg0se8_GdzdLkxyMn
0kxApkAkv-to9EUdbbrvvno_pmqiZGyamw6J2BL1aCqwne3S8CCG34TXRyJyqkG
rPrDO-NPi2fj25PRbX8Ci1iIqXdYvEkefg-g-i0A_Hp9E3s585c5wqxreSBAIwi
aGtnTkxw0D14JPzqWf48hbvVRPGMj_-KXJTnu-zXkkEPNYs8oWpA"
}
5. Reserve the access_token. It must be used on every next method call.
GET https://senhasegura/iso/oauth2/token
6. Fill the Authorization request header with the token_type and value of the access_token.
Authorization: Bearer {{token}}
7. After including a valid token in the header, the new API call is duly answered by senhasegura.
The available PAM methods are listed here. It is possible to link an SSL certificate fingerprint to a customer's authorization WebService A2A. If linked, the senhasegura will validate the CA of the client's SSL certificate with each request as an additional authentication step. The certificate does not invalidate or replace validation using OAuth methods.
See section 2.3 "Client Authentication" in RFC 6749 for a better understanding of the OAuth 2.0 protocol. You can also refer to section 7.1 "Access Token Types" for more details.