michaeldera / image-recognition-function

A serverless function using Azure Cognitive Services to expose a REST endpoint to identify the what is in an image and return it as a JSON payload.
MIT License
4 stars 1 forks source link

[FEATURE] API Authorisation and Rate-limiting #2

Open michaeldera opened 4 years ago

michaeldera commented 4 years ago

Is your feature request related to a problem? Please describe. At the moment the API is public and can be compromised by bots. The API has a limit implemented through the resource it consumed. This can expose the endpoint to a DOS or the API be used for purposes other than what is intended.

Describe the solution you'd like Each node to connect to REST API must be rate-limited and users must have accounts so that access is controlled.

Describe alternatives you've considered Giving a secret token to each node meant to use the endpoint to avoid accounts log in.

Additional context At the moment the API is being consumed by an extension but ideally should be built with the possibility of being used for other purposes.

michaeldera commented 4 years ago

So @nadchif, we are doing signon for mock purposes right now right? Then we use external providers for user management right?

nadchif commented 4 years ago

I think that's the way forward. We use Chrome.identity for Chrome (not yet so sure about Edge)

  1. We use chrome.identity to get the identity on the client side. Chrome identity should give us a token
  2. If the user is not signed in, we post this token to our server's sign in endpoint
  3. Server verifies the above token with Google, and gets the identity of the user,
  4. Server sends back a token (this token will be required in the authorization headers each time the client wants to analyze an image) to the user
  5. Client saves the token and adds it to the headers with each request
  6. Server verifies the authorization headers and leverages them for rate limiting

What do think about this?

michaeldera commented 4 years ago

So at the moment I think we can leverage Chrome token and after validation we can use the same token as a header.... We can still use the same approach for Edge (I will do further reading to confrim). If not we can structure the JSON to sign in something like this

payload = { token: "TOKEN_GOES_HERE', provider: "PROVIDER_NAME_HERE", }

That way we can extend sign on with multiple providers if we like.