Authorisation


OAuth 2.0 is the industry-standard protocol for authorisation. The OAuth 2.0 Framework will be used to handle authorisation.

The authorisation flow and elements are as follows:

  1. Admins create Clients. Each client will have a secret key, for example: 54b0c58c7ce9f2a8b551351102ee0938
  2. The client can use the secret key to generate tokens via the API or admin interface. There are two kinds of tokens according to OAuth 2.0 Framework:
    • Access tokens are credentials used to access protected resources. Access tokens is short life, for example, one day.
    • Refresh tokens are credentials used to obtain or refresh access tokens when they are expired. Refresh tokens are long life, for example, one year.
  3. The access token represent specific scopes which link to the permissions of the access token to the specific resources. For example, scopes could be “upload-data”, “view indicator”, etc. (In MVP, we will give the access token full access as the default scope)
  4. It is suggested that clients prepare multiple access tokens and use them in different data access points. For example, a client manages 100 care homes. Each care home has the facility to send data to CareTec.AI. Then, each care home has its own token.

Protocol Flow

The client is also the resource owner. And the authorisation server sits together with the resource server. So, clients uses their secret key to get an access token for specific scopes (and the refresh token at the same time). That, in a nutshell, is the authorisation process.

Authentication

After the authorisation process, the access token has been issued to the client for data access.

Then, the follow up API operations should contain the access token for authentication. The resource server knows who is going to be carrying out operations.

A bearer token is used to pass the access token to the resource server. The bearer token is in the HTTP request header:

Accept: application/json
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6ImE3YTRkYTdhNmE2ZDY1MzE1MWI0NTlmMDM0OTBkMWY4ZWVmMTk0MDM4M  
zU1Y2IxZjA2Njk1OWNiZWU0MGFjYWVhOTI3NzUzMTAyMTM0YmZkIn0.eyJhdWQiOiIxIiwianRpIjoiYTdhNGRhN2E2YTZkNjUzMTUxYjQ1OWYwMzQ5MGQxZjhl  
ZWYxOTQwMzgzNTVjYjFmMDY2OTU5Y2JlZTQwYWNhZWE5Mjc3NTMxMDIxMzRiZmQiLCJpYXQiOjE1NTI0MTMwMDYsIm5iZiI6MTU1MjQxMzAwNiwiZXhwIjoxNTg  
0MDM1NDA2LCJzdWIiOiI2NSIsInNjb3BlcyI6W119.ATdeXKUG4KyR6zpDkphZvS6uMDoAKv5aET1fhGn1QcMU1o5BJrDawwIPgWitjE-UJGbAEeGB4ixxYzrGre  
X6qnJT5cJnczeGvh-9VrPPbIAjm9dbDQHmXjz5Tn7ebjQtq2URXOsN92PYkpoYqTS2Os7A5OB4dIcUwhBDCw8rbXAQ_R-IsbEOp8fRFXNxc_tBn6-0CQ6-oDYNu  
dR9yM2IPSAgNBBZKnePgX_yjzfbovSNl1NtL9NRNdv6NMgeT8SzKgGNofA8zcCTYCxf03G-68LlOUFWJsaHMum7Mg9AeNfgD-3ykz2pa1cvqqbxDq2xhRVRZRzx  
An5MtvSv_S5M57I1-02o1fFNbmIjmHYPxLyb8NswySDrhAXbAZExGmFuL-8p5BXAcqkgNFFz2ubxV3motIiUVQTVpBXQtAyGSUsFxNjeJiZpuuHonFTW2V9IOiY  
cu76PH-XoL03R66Rv_x0E8IlyfZQAEaFLrGOA3_8i9Ks1T4TwjAaejmqW9UsUgERGt0vGAxnYv0ogkRLXiIQrMN3eawO1EJUCvfnr9YEtvJuK708eapwxGrHwbrY  
rZvF_M0RCg4djJGUknScHQMvafxZphv3TOMQk9WJbz-Mv7yv372yKsWPtO2p9HT_zETeS-8jMb9buFfYPe50382i15jEUF1tcC7tgiNZdgNM
Content-Type: application/json

When the resource server accepts the access token we can check which client sent the request and the the specific scopes related to the access token. Then, either the operation carries on or is refuse due to permission issues.