Customer API keys at UTURN

We allow some of our customers to integrate with us using an api_key rather than our usual "token" based approach.

Generating new API keys

When customers request integration, product team will manually generate them an API key. That is weird. Product team will then send users their api key over email in plaintext. That is unsafe. They will then request us (dev team) to manually add the api_key to the database, where it is stored in plaintext in partykey. That is unsafe.

The reader is recommended to replace this system and revoke existing api keys, I never got around to it.

Determining the authenticated user from the api_key

api_key's themselves only inform us to the authenticated organization, not which user. The missing information is due to the fact that the partykey table only stores the related orgId, not a userId. To figure out which user should be authenticate for a request, we allow the user to send in a requestedBy header, with their email-address. We assume that user input and can be trusted.

Authentication with api_keys.

Many (legacy) endpoint will be of this form:

public void exampleMethod(@RequestHeader(value = "api_key") final String apiKey,
                          @RequestHeader(value = "requestedBy") final String requestedBy) {
  // ...
}

And then manually get the user. That is no longer necessary or recommended, as BearerTokenFilter will set the SecurityContext with api_key authentication, so one should use @AuthenticationPrincipal etc.