the problem

We were building a new product to protect API endpoints. Instead of the API server making its own decisions about who should get access and what permissions to allow, customers would be able to configure an authorization server to make those decisions. The authorization server would then pass a token which could be presented to the API server.

We needed to design a UI for configuring the authorization servers and managing what type of access should be given to which requesters in which contexts.

the process

The authorization server would use OAuth 2.0. I started by talking to the PM and engineers involved to get a tutorial on how the process works. I then read the OAuth spec.

As I started to piece together the entities involved, I saw that there was:

They interacted like this:

The entities involved in an API access authorization process.

The trick was getting all of these entities to be represented in the auth server's rules.

the solution

The solution was to allow the user to for each resource:

The UI for configuring the authorization server for an API endpoint.