API Authentification » History » Version 1
Kurt Gerber, 18 Dec 2019 10:03
| 1 | 1 | Kurt Gerber | h1. API Authentification |
|---|---|---|---|
| 2 | |||
| 3 | Proposed Solution |
||
| 4 | The following is a proposed authentication mechanism for handling mobile app requests. This is to facilitate other API endpoints allowing users to create cases, upload images and edit cases. |
||
| 5 | |||
| 6 | *Caveat: This is very non-standard and maybe insecure* |
||
| 7 | • Use the existing API Token for Primary authentication in all cases |
||
| 8 | • Create a Secondary authentication table, as follows: |
||
| 9 | o One to one relationship to the Registered UserID |
||
| 10 | o 3 fields --> 'UserID', 'APPToken' & 'time_stamp' |
||
| 11 | • When an API request to create a case, upload images or edit cases is received |
||
| 12 | o Authenticate with the API Token to ensure user has access to API |
||
| 13 | o Check if the Authenticated User has an 'unexpired' APP Token |
||
| 14 | ▪ A time limit is used to designate stale/fresh APP Tokens |
||
| 15 | o User has no APP Token: |
||
| 16 | ▪ APP Token is Generated |
||
| 17 | ▪ Response is sent and the APP Token is included |
||
| 18 | ▪ This is the initial handshake |
||
| 19 | ▪ Time stamp is updated |
||
| 20 | o User has an Unexpired APP Token: |
||
| 21 | ▪ Request is accepted |
||
| 22 | ▪ Time stamp is extended |
||
| 23 | ▪ Response is served |
||
| 24 | o User has an Expired APP Token: |
||
| 25 | ▪ User is re-authenticated with the API Token |
||
| 26 | ▪ APP Token is refreshed |
||
| 27 | ▪ Response is sent and the new APP Token is included |
||
| 28 | ▪ Time stamp is updated |
||
| 29 | o User has Incorrect APP Token: |
||
| 30 | ▪ Invalid Response is sent |