Basics of Integration platform

The Service provider's application must use the API Key as an authentication credential in each request it sends to the authentication and authorization service to obtain an access token for any of the resources protected by the platform. To do this, as per the OAuth 2.0 specification, the Service provider's application must put the API Key in the Authorization header of these requests as follows:

Authorization: Basic <API-Key>

API Access Key basics

Before Service provider access Integration platform API, LVRTC shall register Service provider as customer of Integration platform. After signing a contract with LVRTC (Test of Production environment) LVRTC generates Service Provider’s application identifier – (client_id) and shared secret (client_secret), intended for the customer usage.
API Access Key (API Key) is generated from the Service provider’s application identifier (client_id), a secret shared with the platform (client_secret) on the following basis:

Service provider's application identifier client_id is converted using the UTF-8 character encoding and URL encoding conditions.

🚧

For example, value "Portāls" conversion result is "port%C4%81ls".

Service provider's application password client_secret is converted by using the UTF-8 character encoding and URL encoding conditions.

🚧

For example, value "drošība" conversion result is "dro%C5%A1%C4%ABba".

Both values of the previous two steps must be combined with separator colon “:” between them.

🚧

For example, by using previous examples, the result will be "port%C4%81ls:dro%C5%A1%C4%ABba".

Obtained value must be converted using base 64 encoding without line breaks.

🚧

For example, values "port%C4%81ls:dro%C5%A1%C4%ABba" conversion result is "CG94ydCVDNCUMWxzOmRybyVDNSVBMSVDNCVBQmJh".

"MIME Tools" tool in "Notepad++" can be used for this purpose.

API-Key = base64[url_encode(utf8(<client_id>)) ':' url_encode(utf8(<client_secret>))]

API Authorization Calls

To make API calls from authorization server it is necessary to get API access token which is according to the OAuth 2.0 request flow and consists of two steps:
• API authorization code request.
• API access token request.
If it is necessary to get the end-user approval for obtaining the authorization code then authorization server redirects end-user browser to identity provider to perform end-user authentication. If at this point the end-user has not been authenticated, browser displays a login page for the end-user with possible logon methods (smart cards or eParaksts Mobile) or, if service provider make redirect for specific logon method (smart cards or eParaksts Mobile), end-user are redirected to specific logon process. If the end-user is already authenticated and identity provider supports single login (single sign-on), the login page is not displayed again and the operation is approved automatically.
The authorization server issue the Bearer type OAuth 2.0 access tokens and its access rights is provided by authorization code request with specified scope.
To make API calls with this authorization method in accordance to OAuth 2.0 specification, access token API calls must be added as HTTP request header Authorization attribute.

Authorization: Bearer <token>

To control the Service provider’s application access to requested service, access tokens are validated in each API call. Each validation includes token expiration time, identity of the domain and associated scope. In order to avoid a situation when an expiration time of token has expired it is recommended before each API call require a new token.