CONNECT Payment and CONNECT ID integration
CONNECT Payment handles transactions on behalf of the end user. All transactions are linked to a specific user ID, which we get from CONNECT ID. This means that we need the end user to be registered with CONNECT ID before we are able to perform said transactions. The reason behind this is to separate concerns. CONNECT ID handles user credentials, and they are never stored with the details of the user's transactions or payment details. CONNECT Payment only stores the user's unique ID for reference to a verified user within CONNECT ID.
For every POST to /transactions we prepare a resource to be used for this transaction. This resource requires authentication to be used.
In order for CONNECT Payment to authenticate a user, we require the user to be authenticated via CONNECT ID. If CONNECT Payment discovers that he is not authenticated, we will simply redirect the user to the CONNECT ID login page. Here the user may log in if he is an existing user or sign up for a new user (see the "OAuth" section below). Upon a successful login, the user receives an access token, which is handled by their browser, and they are redirected back to the original destination on our payment sites. The access token serves as a unique identifier for that specific user. CONNECT Payment can now query CONNECT ID for the user's ID. If the access token is valid, CONNECT ID will return the necessary information about the user.
CONNECT Payment and CONNECT ID OAuth flow
In order to not store and manage user credentials on a client or with CONNECT Payment, CONNECT ID provides OAuth authentication and authorization as a service. The OAuth flow is used to give the end user access to create and manage their resources, without giving away their credentials to other parties except the party which is made to handle them. The OAuth protocol defines some concepts which are related to Payment in the following manner. First we need to define a key concept:
- Resource - A transaction made by the end user towards CONNECT Payment. A transaction defines the transfer of money from an end user towards CONNECT Payment. The transaction belongs to a specific end user and should be available to the user through intermediaries without the intermediaries knowing the credentials of the end user.
There are four participants in the OAuth authorization flow:
- Resource owner - The end user who wants to pay for something. The end user owns their transactions.
- Client - A webshop, which hosts the sites facilitating the purchase of something.
- Resource server - CONNECT Payment, which facilitates and hosts the transactions done by the end user.
- Authorization server - CONNECT ID, which handles login/signup flows for the end user. This is the only participant which at any point handles the user's credentials.
In order to facilitate the correct resources for an end user, CONNECT Payment needs to uniquely identify each user. This is achieved through an access token, generated by the authorization server after a successful login. The access token can be used by any party to verify the unique ID of the resource owner. It does not contain the credentials, and can not be tampered with without invalidating the token itself. For every request towards a resource on CONNECT Payment, the access token contained within the request is verified towards the authorization server.