So I've had this idea for an API for a while but the problem I keep coming back to is authentication. I'm using rocket to actually code it. I looked through the rocket docs and it looks like the closest thing to API key authentication it has are cookies.

I then went and looked at some other APIs to see if I can copy their layouts and it looks like a lot of them use an API key and then a secret API key for authentication. Did some more googling and stackoverflow said that it's more secure to use a pair like that.

So that leaves me with the actual question: how do you actually implement this feature? Do you just generate API keys and throw them a database to be looked up later? Should they be written/read to a file to be used later(probably not a good option I'd guess).

Just for reference I'm using rocket, sqlx and postgres.

top 9 comments

sorted by: hot top controversial new old

[–] SorteKanin@feddit.dk 8 points 1 week ago (1 children)

I'd recommend switching away from Rocket if you can. It is not very actively maintained and Axum has become the better choice.

[–] ExperimentalGuy@programming.dev 2 points 1 week ago

Thanks for the update, I wrote using rocket a few years ago so I figured everyone was still using that!

[–] mrbn@lemmy.ca 6 points 1 week ago (1 children)

If you are looking to do something like Github's Personal Access Tokens (PAT) then it is easiest to just think about it like a password:

Create a high entropy (secure) string
Store the hash of the string in a database table
Store the permissions and other metadata with the PAT's hash
Validate the PAT (permissions, revoke status, etc) on each request to the server

Storing the hash of the token, like you do with passwords, is a good practice in case your db is ever compromised as it wont leave the tokens accessible and reusable without a lot of effort.

[–] 69420@lemmy.world 3 points 6 days ago (2 children)

Don't forget to add some salt to that hash.

[–] brian@programming.dev 2 points 5 days ago

why would you need to salt long random strings?

also if you salt them you have to have an id too so you can look up who's api key it is. otherwise you can just look up the key hash to get everything

[–] brian@programming.dev 1 points 5 days ago

why would you need to salt long random strings?

also if you salt them you have to have an id too so you can look up who's api key it is. otherwise you can just look up the key hash to get everything

[–] sugar_in_your_tea@sh.itjust.works 2 points 1 week ago (1 children)

That depends on scale. For our IOT device, we just had a private key on the device and gave the customer an encrypted packet that had their privileges spelled out, and set a field on their user account appropriately. That wouldn't be secure at scale, but it worked really well for our B2B app.

If I were doing something at scale, I'd follow suggestions from others here.

[–] brian@programming.dev 1 points 5 days ago (1 children)

I mean, that sounds sorta like JWTs which are used commonly enough for this type of thing

[–] sugar_in_your_tea@sh.itjust.works 1 points 5 days ago

I guess. Our use case was a bit different in that it carried which features they had access to, not just that they had some access. You could probably do that with a JWT as well, but we just issued them an encrypted upgrade file that matched the serial of their device and granted all usersln that device access to the feature.

That was simple enough for us.