API Tokens
A more accessible and secure way to access the Finite State API
Project Overview
Team: PM, UX Designer, Front End Developer
Role: UX Designer
Project: Finite State needed a more accessible and secure way to generate API tokens for their customers. I designed a feature for creating API tokens in the frontend that adhered to business logic requirements which would make downloading and renewing tokens a simple and data-safe task for anybody on the platform.
Duration: 2 weeks
Tools: Figma, Slack, UserZoomGo
Problem
Finite State took a Wizard of Oz approach to generating and sharing tokens for accessing its API. There were a few issues with this approach:
1.) Email is not secure. Anybody who happened to access the email Finite State sent would have access to a unique API Token.
2.) Time consuming. Users had to wait on Finite State to generate and email the tokens.
3.) Inflexible. Administrators wanted API credentials mapped to particular roles and endpoints. Every time they needed to update these things, they had to go through Finite State.
Proposed Solution: An API Token feature that allowed users to generate unique API Tokens and change permissions via the Finite State application’s frontend.
Solution and Impact
Along with receiving qualitative feedback that our solutions were working for our customers, we also judged success based on quantitative metrics:
Quantitative Metrics:
Increased API hits by 30%
Typical length of API session increased by 5%
Our API hits increased by 30% and session length increased by 5%. It was clear more users were using our API, and they were getting more done while using it, thanks to our frontend work.
Proposed Solution: Scoped Permissions
User defines permissions (including user permissions) for multiple areas of their token.
How does this work?
A user can “scope” or define the permissions of their API Token when they create it. They can set read and write permissions for certain actions and aspects of the app such as notifications, user access, and deleting data.
Why did we need to simplify things?
According to our users, the ability to define permissions for users was the main functionality they desired. This solution included lots of other areas where permissions could be configured. That expanded functionality was not in line with how users told us they typically used our application, i.e. permissions in the application were role-based and not necessarily customizable.
Accepted Solution: Role Based Permissions
Select Entity Access Flow
Step 1: User defines the entity that will have API access.
Step 2: User defines permissions (based on existing RBAC permissions).
How does this work?
A user can allow full access to all users in an organization, or they can limit the token to permissions based on existing roles already defined in the application in the following way:
Kick off flow by selecting card labelled “Select Entity Access”
Choose the sub-organization (we call them Business Units)
Define permissions for the API token within that sub-organization (either Viewer or Editor)
Submit form and create token. Success!
Why does this work?
According to our customers, the ability to set permissions for users was the main functionality they required. Since we were already defining permissions in the app based on user roles, we could use those permissions to define API token access, as well.
It also solved the problem we stated earlier. Users could now use our application’s frontend to securely and easily generate API tokens with permissions set for users in their organization.