Validating a token inside every service is duplication. It is the same twelve lines in every language you run, subtly different in each, and wrong in exactly one of them. Doing it once, at the edge, before any application code executes, is the version of this that scales.
No major identity vendor ships the edge. They hand you a token and wish you luck, and you assemble a reverse proxy, an OIDC plugin, a session layer and certificate automation from four sources that have never met.
SkipAuth ships it: an OpenResty gateway, configured from the same database that issued the token.
What it does
Verifies at the edge. The signature is checked against a key preloaded by key identifier and held in shared memory, so verification does not make a network call. A request that fails never reaches your service.
Injects what your service needs. Downstream, the request carries the tenant, the authentication type, the calling application and, where one applies, the identity being acted for. Your handler reads headers rather than parsing tokens.
Enforces path rules. Each application has an access list of protected and public paths, and the most specific match wins. A public health path beside a protected API is two lines of configuration, not a branch in your middleware.
Runs three modes on one proxy. A browser application gets a cookie and a redirect. An API accepts bearer tokens only. Anything in between accepts both.
Mints per-application tokens from one sign-in. A dedicated token-exchange grant lets the gateway produce a token for the application the visitor is currently using, from the session they already have. Moving between your applications does not produce a second login, and no application ever holds a token minted for a different audience.
Coordinates revocation. A revoked session is published to every gateway instance, so it takes effect across the fleet rather than when a cache lapses.
Punishes replay properly. Refresh tokens rotate. Presenting one that has already been used revokes the entire family descended from it, not just the token that was replayed, because a replay means the chain is compromised and not that one request was unlucky.
Renews its own certificates. Issuance, renewal and rotation are scheduled per hostname well ahead of expiry, with domain validation through your DNS provider or a record you place yourself. Certificate expiry is the most avoidable outage in this industry and it should not be on anybody's calendar.
How to check it
- Put a service behind the gateway with no authentication code in it at all. Request a protected path without a token. You should get a redirect or a refusal from the gateway, and your service should show no request.
- Sign in, then request the same path. Your service should see the request with the tenant and calling application already in the headers.
- Mark one path public. Request it with no token. It should pass through.
- Take a refresh token, use it, then use it again. The second use should revoke the family, and the session should be gone from every instance.
- Look at the certificate list and find the renewal date. It should be roughly a month before expiry, and nobody should have set it.
Where it stops
You may already have a gateway you like. Most large organisations do, and that is a real reason not to use this part. The rest of the product does not require it: an application can validate tokens itself against the published key set, in the ordinary way, and still get the issuer, the directory, the role graph and the trust model.
The certificate lifecycle is automatic for authorities that support it. Issuance and renewal are driven by the standard protocol for it, with domain validation through your DNS provider or a record you place yourself. A certificate from a commercial or private authority is uploaded and managed by you, which is usually what a policy requiring one also wants.
It is a gateway, not an API management product. Routing, edge authentication, path rules and sessions are what it does. Rate plans, developer portals, request transformation and monetisation are somebody else's job, and this sits behind or in front of the product that does them.
What the alternatives ask of you
| Approach | What it asks of you | SkipAuth |
|---|---|---|
| Validate the token in every service | The same code in every language you run, and a quiet defect in one of them. | Verified once, at the edge, before your code runs. |
| A proxy plus an OIDC plugin plus certificate automation | Assemble three products, then keep their configuration in step with your identity system by hand. | One deployment, reading the same database that minted the token. |
| A zero-trust access product | A strong edge with a thin authorization model, usually hosted. | The same edge posture with the role graph behind it, self-hosted. |
| A session per application | A second login every time somebody moves between your applications. | One session, and a per-application token minted from it. |
Back to the capability index, or start at integrate once, replace the provider later.