Authorization and Technical Requirements

Authorization

OAuth 2.0 standard is used for authenticating customer communications with Basket App. In the case of service to service communications – without the logged user context, client_credentials flow a OAuth is used (https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/).

The Merchant receives their client_Id and clien_tSecret
They collect an access token
They sign each request. The access token should be provided in the header Authorization: Bearer W-TYM-MIEJSCU-NALEZY-UMIESCIC-TOKEN
The resource server verifies the token, and identifies the customer

All the requests sent to the server require entering the right and valid access token, which belongs to the particular User.

The token endpoint is fixed, and can be a configuration parameter on the customer's side:
https://login.inpost.pl/auth/realms/external/protocol/openid-connect/token

Production Environment

https://login.inpost.pl/auth/realms/external/protocol/openid-connect/token

Sandbox Environment

https://sandbox-login.inpost.pl/auth/realms/external/protocol/openid-connect/token

Token Collection:

Request

POST /auth/realms/external/protocol/openid-connect/token HTTP/1.1
Host: login.inpost.pl
Content-Type: application/x-www-form-urlencoded

client_id=merchant-1&client_secret=****&grant_type=client_credentials

Response

{
    "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiw...",
    "expires_in": 300,
    "refresh_expires_in": 0,
    "token_type": "Bearer",
    "not-before-policy": 0,
    "scope": "api:inpostpay"
}

Errors that may occur when generating a token:

Invalid client credentials- In the case of providing wrong client_id
Invalid client secret- In the case of providing wrong client_secret
Missing form parameter: grant_type- In the case of missing grant_type: client_credentials

On this page

1 Authorization
2 Merchant's Account in Basket App
3 The scope of the implementation works on the part of the Merchant

Merchant's Account in Basket App

At the merchant's account level, the system stores the configurations:
1. Merchant's Name
2. The logo of the store (image)
3. Store's web address
4. Email and phone number for contacting the user
5. Link to the merchant's contact form.

The scope of the implementation works on the part of the Merchant

Authorization – the implementation of account authentication, authorization, and configuration.
Frontend widget - InPost Pay widget implementation Widget - frontend.file:///C:/wiki/spaces/PL/pages/131072001/Widget+-+frontend
Backend widget – issuing endpoints described in the Widget_backend_API, intended to handle the feature according to the InPost Pay Widget sequence diagrams.file:///C:/wiki/spaces/PL/pages/130023427/InPost+Pay+Widget
Integration with Basket App API – integrating with the API methods described in Basket App. file:///C:/wiki/spaces/PL/pages/129794052