Skip to end of banner
Go to start of banner

Overview of User Authentication Flows

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

As mentioned above, Gini Pay API supports different authentication flows, depending on the use case. The API differentiates between anonymous and derived users. Client credentials (that you received when you registered your application) support either derived or anonymous user flows.

  • Anonymous users are identified by username and password. You create them explicitly for your untrusted devices

  • Derived users are identified by their username only, specified by X-User-Identifier header. The value is up to you, usually a stable hash of your internal user identifier. A derived user is automatically created if it doesn't exist already. It is unique for the client.

There are currently 4 different authentication flows possible with our API.


Communication from a trusted device using a derived user

Communicate with Gini Pay API using client credentials (basic authentication) from a trusted device that is your trusted backend. A derived user is automatically created if it doesn't exist already.


Communication from an untrusted device using a derived user

To communicate with Gini Pay API from untrusted devices, acquire a token from Gini Pay API for the user and hand it over to the untrusted device. The user is derived/created from X-User-Identifier header. The value is up to you, usually a stable hash of your internal user identifier.


Communication from both trusted and untrusted devices using a derived user

When you communicate with our API from a trusted device using client credentials (option 1), a derived user is automatically created for a given X-User-Identifier when it's specified for the first time. From then on, the derived user stays fixed for this client ID and X-User-Identifier. You can also acquire an access token for this user so it can be used by an untrusted device. This scenario is valid when you have both trusted and untrusted devices communicating with our API and you don't want client credentials stored on an untrusted device.


Communication from an untrusted device using an anonymous user

This is the only flow that requires communication with two APIs: the Pay API and the User Center API. This flow is done in 4 steps:

  1. Obtain the client token using client credentials

  2. Create a new user using the client token

  3. Log in on behalf of the user and acquire an access token

  4. Make API requests with the access token

Access tokens expire. So last two steps should be repeated to refresh the token and hand it over to the untrusted device for use.

  • No labels