Skip to content

add API key authentication #111

@VigneshVSV

Description

@VigneshVSV

As a further improvement over the basic security scheme, we should support API key based authentication.

Rough steps:

  • define a security scheme under hololinked.server.security called APIKeySecurityScheme
  • The scheme should have a method called generate. Define some attributes within the security scheme which will configure generation (like memory hard, CPU hard, expiry etc.). Use argon2-cffi to generate a random string and hash it. Prefix the random string with hololinked-pat., along with a six character ID to identify the API key. The rest is the secret. Use dots to separate the parts, there will be in total 3 parts. (The hash will of the whole thing though)
  • Within the BaseHandler.has_access_control (hololinked.server.http.handlers), integrate the validation.
  • Add an endpoint and a handler for generation (/tokens POST) , the return value is the API key. The API key itself should not be stored, its not safe. This endpoint will be at the top level and not tied to any thing instance per se (However the API key is tied to a thing instance). To generate the API key, one would supply user name and password (the basic security scheme).
  • Also add an endpoint to revoke an API key (DELETE). Its sufficient to remove it altogether and not maintain a list of revoked tokens.
  • Store the API key hash in a SQLite database for now (we will integrate with other databases later), load the API keys from the database when the server reboots. The table should have the columns - ID, hash, thing ID expiry date, generation_date. The validation is always carried out keeping in mind the thing ID and expiry date.
  • Add the API key security scheme within the TD metadata, definition is found here - https://www.w3.org/TR/wot-thing-description11/#apikeysecurityscheme
  • Add a CLI that will compose a HTTP client and retrieve an API key from the server given a username and password. We will think about adding a GUI later or integrating one with thing control panel
  • add tests and docs

Regarding the SQLite database, its not clear how to handle the database file. There is already an option to store property values in databases (per thing instance):

  • Should we merge this with that database?
  • Should we maintain a separate one?
  • Should we maintain only one global database irrespective of how many things run in the device?

This needs to be addressed. Preferably we agree to this upfront before working on this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueGood for newcomersintermediateintermediate level good first issues, might be little harder to complete

    Projects

    Status

    Ready

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions