Fine-grained permissions for API keys - any best practices, great examples, etc?

[Cooper Marcus]

Do you have any advice on providing fine-grained permission controls for API keys? Any great example implementations you've seen? Any docs or best practices I should look at?

By "fine grained permissions for API keys", I mean that a user could create an API key with a certain set of permissions (eg CREATE resource type X, READ (but not modify) resource type Y, prohibit access to endpoints A and B, etc), then create another key with other permissions, etc. Admins could see what keys were created by whom, what permissions they have, do key regeneration, etc.

Thanks, Cooper

[Jørn Wildt]

You can take a look at Macaroons - "Cookies with Contextual Caveats for Decentralized Authorization in the Cloud". See http://macaroons.io/. There are plenty of libraries for various languages.

Macaroons can express statements like you mention: having read/update/delete/create access to resource X, searching and what ever else.

There are three resources on Macaroons:

- Google Research publication (the core algorithms)
- Techtalk by Úlfar Erlingsson

- Walktrough for you first Macaroon implementation (exists in different variations depending on language).

- Discussion group

The Macaroons libraries doesn't support provisioning/management of Macaroons - only the core algorithmic implementation.

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Andrew Braae]

This is more of an implementation consideration, but assuming you're talking about OAuth tokens, will they be:

- self-contained? (i.e. the resource server can extract the permissions from the token itself, and does not need to communicate to the authorization server)
- back channel? (i.e. the token only holds an ID, and the resource server needs to make a call with the ID to the Authorization server to understand what powers the token grants)

This is relevant because self-contained tokens (e.g. JWTs) get physically larger and larger as you compress more and more information into them. Since they need to travel in the http Authorization header with each API call you don't want them getting too large.

[Owen Rubel]

You are looking for Shared IO State (https://www.youtube.com/watch?v=mZOs7oz0JOI). The data for API's need to be separated from the architecture so it can be shared across a distributed architecture. Once you do this, you can set those states,roles, settings per api call