thomas4019
Access via API Key
A solution that uses existing permissions model and updates token model to allow access via stored api keys.
Not my area of expertise but i could quite easilly see expressa being able to seemlessly offer this. @thomas4019 looking for some guidance
There could also be a listener that consumers implement as their own 'post signing' security layer
Can you explain more what your use case is? As long as the JWTs have no expiration, they're very similar to an API key. You can think of the password as a way to generate a JWT (API key).
The use case is exposing parts of the api to third party developers. Where we issue them an api key to use when making requests to us.. Seems to be a standard practise these days?
Hmm, what makes a request from these 3rd party developers different than from any other API request? If they're getting more access than a normal user, maybe this can be solved by giving them a custom role?
It is pretty common for websites to have a page where users who are also developers can create & label, view and revoke api keys. GitHub, Discord, DataDog etc provide this. Is this kind of what you're thinking?
That is exactly what i am thinking. But the api keys dont really look like a token generally? Also will need to persist they keys to a database if they are revocable i assume?
for my use case, you need to be able to grant view/edit access for specific documents.. So maybe like "users: view specific": [ids of docs] maybe. in which case, role could no longer be type: file as needs to be updated and shared amongst processes, unless cacheInMemory: false works?
I'd propose a new access_token collection with a schema like this:
| Column Name | Type |
|---|---|
| _id | string |
| creator_user_id | string |
| token | string |
| expires_at | string (timestamp) |
And then also an access_token_access collection
| Column Name | Type |
|---|---|
| token_id | string |
| collection_id | string |
| doc_id | string |
| view | boolean |
| edit | boolean |
| delete | boolean |
Some things I'm not sure about is if these token requests should have a user_id set on the req object.
Yep! The access_token_access table is inspired by Drupal. It attaches these permissions directly to users though.
Do you see this as something that could/should replace exisiting permissions model?
Rather than replacing, I see this as more of an optional, more advanced permissions model.
Yeah, I currently do have capacity to work on this, but I’d need a bit more about your requirements. Like some concrete examples. Can you add that here or email me?