Client API Keys - Improvements

[anthonyphysgun]

Currently, Client API keys are created and have full access to do anything the user can without any scopes or permissions.

Let's discuss options for a good way of breaking this down into scopes

[MrSoulPenguin]

I feel, in the very least, the middleware for the application user authentication could be tweaked to do the opposite of the client api key middleware. Checking the key type to ensure an application key is being used.

This would mean a reevaluation of the application key type deprecation should probably be done. Since it will be check against even more than previously. But since it's been about 4 years since it was deprecated and it's still checked against, I can't really see a clear reason currently to not just revert the deprecation.

[DaneEveritt]

The intention was that application keys were removed and replaced with client keys. One key system to maintain and understand, and not two. It also removes some ambiguity around certain API endpoints that are vaguely admin, vaguely not.

I think the "correct" fix would just be to bring some lightweight permissions logic to the client keys, allowing you to use the same setup as the application ones, e.g. read, write, none. That is probably the simplest implementation that solves for a majority of the use cases without bringing in a significant undertaking to define all of the possible actions.

You'd probably also need to combo this with an admin-level permissions system so that you can create "bot" admin accounts with a limited set of permissions already, and then generate API keys on those accounts that are scoped even more if you really want to apply some swiss-cheese security modeling here.

[MrSoulPenguin]

I agree that there could be some scoping with client api keys. So they aren't an all or nothing in what they can access.

But my biggest hangup with the current setup is how an admin owned client api key can also access the application api unrestricted.

There is pretty big a difference in what can be done with the client api versus the application api. So I feel that actually splitting them further and limiting the opportunity for some mistake to be made in scope and permission checks to be preferable.

This is coming from my viewpoint of managing a service where untrusted users can create an api key for their account whenever they feel. So keeping the keys they can create limited to only what they should be able to access through any frontend interaction seems ideal to me. Even if the user is an admin.

If an admin has a need for an api key that can access the application api, then it makes the most sense to me to just make an application key.

I can say though that an admin-level permission system is useful, especially if you are managing different levels of staff that don't need access to everything available. With admin accounts having little to no permissions at all by default.

I think the current application api key system works decently as is, but with extra checks for the key type as I've said before, and ensure that the admin that created an application key is still an admin on authentication, so if their perms have been revoked any keys generated by them are effectively invalidated. Of course this also works best with a permission system that limits who can create and use application keys in the first place.

[JoshPiper]

Conceptually, one is user-based auth and one is application auth. If your admin user gets disabled, it shouldn't break automations tied to that. While that makes the argument for service accounts, I can also see the pain in having to log into N service accounts to rotate N*M keys.

Having the ability to scope both sets of keys would be nice, especially since I don't think we can at present scope admin account access?