Skip to main content

Protect an API

Decide who may call a route. The guides go from the key the first API asked for to signed tokens, a sign-in through your identity provider, and the restrictions by name, team label, network and request shape. Each guide does one job, in the order the console does it, and ends with a request you send and the answer to expect.

Before the guides, read Authentication. It explains how the gateway tells clients apart and what follows once it knows who is calling.

Read in this order​

  1. Require an API key. Put key-auth on a route and give the first client its key.
  2. Give a client its key, and replace it. Create a key, hand it over, and replace it later without a gap.
  3. Accept signed tokens. Put jwt-auth on a route and give the client the credential that checks the tokens it signs.
  4. Ask for a username and password. Put basic-auth on a route so that a client signs in with a username and password, and a browser asks for them.
  5. Allow only named clients. Let only the consumers you list call a route, by name or by consumer group.
  6. Allow a team by label. Let consumers through by a label they carry, so a route stays as it is when the team changes.
  7. Allow a network. Let only requests from the networks you list reach a route.
  8. Refuse requests that do not match a schema. Check the body of each new order against a JSON Schema at the gateway and refuse the ones that do not match.
  9. Let a browser app call the API. Put cors on a route so a web app served from another origin can call the API from the browser, cookies included.
  10. Sign people in with your identity provider. Send browsers to Keycloak or another OpenID Connect provider before they reach an internal web application.
G8 dev