mardi 21 avril 2015

Architecturing API keys and access tokens

I have a question regarding how I should architecture a REST API using access token and API keys.

I have an API that needs authentication. I want to enable two use cases:

  1. The user logs into the interface using OAuth2 (password grant), and is granted a temporary access token. This token is used to authenticate the user. Therefore, the UI, that itself using the API, can fetch data and display it.

  2. I also want the user to have an API key to do the same calls, but in its application. Obviously, contrary to the access token, I want the API key to be long lived. Also, contrary to the access token that is tied to a given user (if we introduce a team mechanism, each user will have different access token, although they access the same resources), the API key should be unique to the project.

While similar, I'm not sure about how should I architecture that. I think that, internally, both API keys and access tokens should be stored in the same table, but API keys having no expiration time. Am I right?

One thing I'm not sure also is the concept of client. It seems that in the spec, the client is more like an external application. However may I actually use this concept here?

For instance, each "project" is actually a different client (although the client here is the same application, not an application created by a third-party developer).

Therefore, if user A creates an account on the system, a client A will be automatically created, with an access token tied to the client A, with a long-lived access token (aka API key). This can be used to perform API calls directly on his code, for instance.

Then, if user A logs into the dashboard, a temporary access token will be created, but this time with no application, but tied to the user, with a short life.

Does this sound sane? Have anyone already implemented such a thing?


Aucun commentaire:

Enregistrer un commentaire