Identity Guard
Who gets in.
What they may do.
Decided on every call, for every customer, person, system and AI agent that reaches your APIs — and already running the moment you register.
A full authorisation server, not a login form in front of a table of usernames and passwords: OAuth2 and OpenID Connect, access control, zero trust and least privilege. Every customer gets their own credentials the moment they sign up, limited to exactly what they bought. Signing keys are published through JWKS, secrets rotate, and any credential can be revoked the moment it should stop working. Attempted logins are watched too, and abuse is flagged before it becomes access.
API keys
What they are good for,
and where they stop.
Good for
Getting started quickly. One secret, easy to issue, easy to send. Fine for public data, internal tools, or telling one calling application from another for rate limits. If your customers only ever read public data, a key may be all you need.
Where they stop
- A key says someone holds it — not which customer, person or system is calling.
- There is no authorisation behind it: once in, everything the key opens is open.
- It does not say which customer is calling. If you hand out one key per customer, where is that checked — on every endpoint, in every release?
- It does not end on its own. When someone leaves or a contract ends, it works until somebody remembers to remove it.
On every call
Three questions,
answered before it reaches you.
A call that fails any of them never reaches your infrastructure — it is stopped at the gateway, before it touches your backend.
01 // The organisation
Is this a customer
you work with?
Every call is matched to the customer it comes from, and only customers you have approved reach your systems at all.
02 // The caller
Is this person or system
allowed in?
Rights can sit on a person, an account or a team. Move someone into a team and they have what their colleagues have; move them out and it is gone. Coming: access that follows working hours, and a contractor hired for three months whose access ends on its own, with nobody having to remember.
03 // The operation
Does their grant
include this call?
Decided per operation, against the real grant — not what a screen shows or hides. Grants are resolved on every call, so one withdrawn stops working on the next, and they are only handed out through your approval process. The roles your app already uses map straight onto them.
Every app talks to an API
No path to your data
goes around it.
Your web app, your mobile app, your customers’ systems, their AI agents and your own services calling each other all reach your data through your API. The checks apply at the edge, and — with the micro-gateway in your own cluster, on hybrid or self-hosted — to service-to-service calls inside it too.
Your data stays yours
Protected,
never read.
Apiway never stores your data and has no access to your database, by design. It protects it by deciding who reaches your service — and every call that does arrives with a verified token, so your service always knows which customer is calling. That can never come from the request itself.
Zero trust
No trusted
inside.
Nothing is trusted for where it came from — inside the network, behind the firewall, or from a partner let in once. Every call proves who it is and what it may do, every time. There is no internal shortcut to leave switched on by mistake, because there is not one to begin with.
AI agents
Always on
someone’s behalf.
An agent always acts for a person and can never do more than that person could. Every action records which agent did it and for whom, and when that person’s access changes, everything acting for them changes with it.
One front desk
Every key in one place.
Including the ones you forget.
Your identity provider proves who someone is. Apiway decides what they may do — and the same front desk now holds the keys most companies lose track of: the ones your own software uses, and the ones to your other tools.
Machines are visitors too
Rolling outNo password
left in the van.
Your services and build pipelines usually prove who they are with a secret copied into their settings — one nobody can track, and changing it means stopping them. Coming: instead, the place they run vouches for them with a pass that renews itself every hour, and Apiway decides what they may do. No secret exists to leak. Withdraw the rule and they are turned away on their next visit.
Technically: workload identity federation — Kubernetes service accounts, GitHub Actions, Azure Pipelines and GitLab tokens accepted as client assertions against a federated credential, with certificates where there is no workload identity.
Your keys to other tools
Rolling outGitHub and Jira,
by who needs them.
Coming: access to your code and your tickets granted like any other access. An engineer’s team needs GitHub, so they get it when they first need it; someone in HR never does, so nothing is ever created for them. Move teams or leave, and Apiway withdraws it at GitHub or Jira itself — nothing survives, and no one has to remember. Connected to your organisation, never to the person who set it up.
Technically: GitHub, Jira and Azure DevOps registered as external APIs; one admin connection per provider and per-person tokens held by the authorisation server, injected by the gateway and revoked at the provider when the entitlement ends.
Protection that acts on its own
Rolling outCaught trying doors.
Badge taken away.
Today every refused attempt is recorded, told apart and pushed to you as it happens. Coming: the front desk acts on it too. A known caller that keeps trying doors it has no right to has its badge suspended until someone reviews it; someone hammering the entrance with wrong keys is slowed and then kept out — without ever letting a stranger lock a real customer out by pretending to be them.
Technically: automatic responses to repeated refused attempts, with limits you set per API or plan.
Who may use what
Apiway is your authorisation server.
You issue nothing.
Your users sign in with Auth0, Entra, Okta or Google; Apiway issues every token and decides, on every call, which customer and which operations. Your customers get their own credentials. Anything else you put your product behind will tell you it supports secure sign-in. That is true, and it means: you bring the thing that hands out the credentials, you configure it, you connect the two, and you run it from then on. Cheaper products skip it and give every customer the same kind of key — which cannot say what that customer is allowed to do, and cannot tell your own software who is calling.
Here it is already running. A customer signs themselves up and is issued their own credentials, limited to exactly what they bought. Nobody on your side does anything.
Issued, not configured
Nothing to stand up, connect or operate, and nobody to hire who knows how. We have built this part by hand twice, on two different commercial gateways — a year each time, and it still did not join up with how releases were shipped.
Your software knows who is calling
Every call arrives with a verified token, so your code always knows which customer and which person is calling — and that can never come from the request itself. Apiway never reads your data, and a call without the right grant never reaches it. Your existing staff login works alongside it, unchanged. And none of this means a new gateway: Apiway runs on the one you already have — Kong, Azure APIM, Apigee, Tyk or Zuplo — so adding it is a change to what your gateway enforces, not a migration of your traffic.
Limited to what they bought
Each customer reaches the parts of your product on their plan and nothing else, checked on every single request rather than trusted.
Already running.
Nothing to install, connect or operate. Register, and every API you publish is behind it from the first call.
Continue
Any Gateway, Any Provider
Keep the identity provider and the gateway you already own.
Read more →AI Agents
Agents as first-class callers — own identity, own grants, own record of what they did.
Read more →API Product Economy
Customers, subscriptions and grants across internal and external services alike.
Read more →