Information Security Asked by Brad Stevanus on November 30, 2021
I am creating a public API that will require API key authentication. When a user wants to register a new API key, they send a request to one of our endpoints with a list of permissions they want. We generate a unique key (uuid4) and send it back to them encrypted by TLS.
I am planning to hash the key that was created and store it as the primary key of a database. On each user request we can rehash the key they send in the headers and index the database to check if it is indeed one of the keys we’ve created. We’ll also have their list of permissions stored in a column which we can use to authorize them for certain routes.
Question: My concern is how we’re going to associate an API key to a user. Say a user wants to see a list of API keys they’ve generated. Is it now impossible for us to produce this list? Also say that a user loses their API key. How would we identify which API key has been lost, so we can at least delete that record in the database? I’m wondering how this stuff is usually handled.
The other answers are very helpful and are probably the best solutions for scalability and larger companies. I neglected to mention some extra information about our situation (we are a small company and we already have some users on our main site).
Looks like I've overlooked the fact that I can simply associate an API key hash with a user by adding a column for an API key hash to our already-existing users table. I wanted to make sure that users only had to pass their API key in each request to secured endpoints. I realized that this is still possible because each API key is unique, so we can do the hash and search only the column of API key hashes to find the correct user; no need for usernames.
These users have a username/password to our main site. While we won't be able to show them their API key again, we will be able to let them delete their key and generate a new one.
Answered by Brad Stevanus on November 30, 2021
Divide and conquer.
The problem in your approach is, that you want to use one key for two different things: for authentication and for authorization.
As we see, these requirements conflict to each other. If you use a single key for both, it will be impossible to satisfy all these requirements.
I'd suggest you to separate authentication and authorization from each other. Divide and conquer.
Answered by mentallurg on November 30, 2021
If you hash the keys, it would not be possible to show the keys to the user ever again. Hashing can not be reversed. You can only check if a given key is linked to the user.
What is oftenly done for APIs is to create a key consisting of a public and private/secret part. The public part can then be stored in your DB, whilst the secret part follows your current flow of storing/hashing. You can then list the public keys for the user (which he can then delete if lost).
Upon authentication the user would need to provide both parts which you can check in your DB. Another option would be to request a temporary token with the public/private keypair, this token can then be used for further API calls. Note that the token should have a limited lifetime and of course must be unique among all users.
Answered by roy.stultiens on November 30, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP