Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Page Properties
hiddentrue

Status

Status
colourYellow
titlefor review

Approver

Pavel Shkadzko

...

  • trusted

    Your application communicates with Gini Pay API via a common backend that runs on a trusted device. Each request identifies includes the application’s user identifier to specify the request is made for via the application's user identifieruser associated with the request. No account management is required.

  • untrusted

    On the first API usage, your application(or Gini Bank SDK) creates an anonymous Gini user in the background and uses those the account credentials for subsequent requests. This works best for (mobile) applications where the app communicates directly with Gini Pay API on an from some untrusted device.

...

Communicating with Gini Pay API via backend/gateway

...

This authentication schema is based on Json Web Token’s. Your In order to authenticate itself with Gini Pay API, your application acts as an identity provider and , creates a JWT access token and send sends it in the X-JWT-Authorization http HTTP header with Bearer prefix along with an the actual request to authenticate itself with Gini Pay API. Gini Pay API will then validate this access token to ensure the request is being sent from the a trusted source. To enable the validation by Gini Pay API, you need to expose jwk-set endpoint which is accessible from the Gini system.

...

Claim Name

Description

iss

mandatory

The value holds the issuer of the identity provider.

<user_identifier_claim_name>

mandatory

The value holds a hash which identifies the user, same as X-User-Identifier in the basic authentication schema. Claim name is configurable at Gini backend.

<client_id_claim_name>

mandatory

The value holds the client id that communicates with Gini backend, same as client-id in the basic authentication schema. Claim name is configurable at Gini backend.

<client_secret_claim_name>

optional

The value holds the client secret that communicates with Gini backend, same as secret in the basic authentication schema. The existence of the claim and the claim name is configurable at Gini backend.

Sample Example of JWT claim content with the configuration:

...

Code Block
languagejson
{
  ...
  "exp": 2025803444,
  "iss": "http://issuer-url-of-your-identity-provider",
  "typ": "Bearer",
  "x-user-identifier": "user1",
  "x-client-secret": "clientId",
  "x-client-id": "<clientSecret>",
  ...
}

Finally sample Example of the actual get documents request:

...

The jwk-set endpoint is used to retrieve the JSON Web Key (JWK) Set set from the Authorization Server, which contains the cryptographic key(s) used to verify the JSON Web Signature (JWS) of the access token.

Sample Example request to the jwk-set endpoint:

Code Block
curl --location "http://<your-identity-provider-jwk-set-url>"

Sample Example response from jwk-set endpoint:

...

You should already have the client ID client-id and the client secret client-secret. They authorize your client (with HTTP Basic Authentication) to obtain the client access token, see the example on the right.

See Authenticate Client.

Code Block
languagejson
//obtain the client token

curl -v -H 'Accept: application/json'
    -u 'client-id:client-secret'
    'https://user.gini.net/oauth/token?grant_type=client_credentials'
the successful response will have HTTP status 200 and the client access token 1eb7ca49-d99f-40cb-b86d-8dd689ca2345 will be returned

{
  "access_token":"1eb7ca49-d99f-40cb-b86d-8dd689ca2345",
  "token_type":"bearer","expires_in":43199,"scope":"read"
}

...