Default request usage
  • 1 minute to read
  • Dark
    Light
  • PDF

Default request usage

  • Dark
    Light
  • PDF

Article Summary

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

Caution
This method is not recommended by senhasegura. Choose to use OAuth v2.0, if possible.

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 

 


Client secret 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.

Info

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.


Was this article helpful?