API: Authentication

[NeilMBenetech]

Several Github tasks are related to create and expose a "pull" API to authorized third parties as described in "Service Net Vision - Integration" section 1.a.

This task is to establish a secure authentication and authorization method to this API. While we are still in the pilot stage it will be sufficient for us to manually issue a unique "bearer token" to each trusted third party and distribute to them securely. The token should be a Universally Unique Identifier (UUID). In the future we can look at more automated ways to issue these tokens.

Each bearer token should be associated with exactly one pilot partner, such as UWBA or Eden I&R. All authorization to data emitted in the API responses should respect the notion that the request was made on behalf of that pilot partner. For example, when a request is made (should we define it this way) that asks "Show me the matching records to record 1234" the API should ensure that record 1234 is indeed owned by the requesting entity - if it is the request proceeds, if it is not, the request is declined.

For every API request made, the bearer token should be present in the request body, which is encrypted via SSL/TLS and not in the URL, which is not encrypted and subject to being hijacked. The server should validate that the bearer token is currently valid and establish the identity of the requesting entity.

Ensure only TLS 1.2 or higher is allowed. All other ciphers should result in a 403 error.

[jkondrat]

@johnhbenetech @NeilMBenetech Since we are using OAuth2, I suggest that we use client credentials grant to authorize: https://tools.ietf.org/html/rfc6749#section-4.4 Each third party would have a client_id and a confidential client_secret, which would allow them to request access tokens. These tokens could be then used to access our APIs.

[NeilMBenetech]

@jkondrat Could this be done in such a way that a human does not need to login to refresh the client_secret?

[johnhbenetech]

@NeilMBenetech @jkondrat I'm assuming the flow is a one time key provision. Please correct if I'm wrong

[jkondrat]

@johnhbenetech @NeilMBenetech : that's right, we would provision the secrets once for each third party. A client would have to authenticate using id and secret to get the access token and we can configure its validity period

[johnhbenetech]

@NeilMBenetech That's seems fine by me/standard for most API systems. Let us know if you disagree

[NeilMBenetech]

Thanks @johnhbenetech for confirming, that's exactly how I see it happening. I've seen a few OAuth2 implementations that require a human login periodically = lame. Zoho.com, the CRM, is a recent example.

[abaranowska1]

After sending POST request with proper settings I can get an access_token Also I checked if I can send a request with received access_token and XSRF_TOKEN from staging ui set as cookie and also I get 200 OK status

@jkondrat one minor issue: Please fix the UI on View External Client page

[abaranowska1]

Tested with success Now it looks fine