LynBro Plugins
/ API Auth
LynBro Plugins
/ API Auth
Most JWT plugins can issue a token. Ask one to stop a token and the only answer is “change the site’s signing key” — which signs out every app, every build script and every integration at once. This one keeps a record of each token it hands out, so taking one back is a button.
Free forever. No account, no card, no quota. Makes no external requests of any kind.
minutes, not seven days — how long the credential sent on every request stays useful.
The credential that goes out on every single request is the one that ends up in proxy logs, browser storage and crash reports. Ours expires in minutes; the long-lived half is shown once and is replaced every time it is used.
The REST sign-in route is not covered by the plugins that protect wp-login.php, so it is rate-limited here — failures only, never a lockout, and the same answer whether the account exists or not.
Every refusal is written down with the reason, on screen and downloadable as CSV. That is the difference between an afternoon lost and a fix in two minutes.
No "Pro" tier, no nag screens. The features other plugins paywall are here from day one.
Fifteen minutes by default, and you choose. The refresh token behind it does the waiting.
Each use replaces the token. If a spent one turns up again, a copy exists somewhere — so the whole session ends and it is written down.
New tokens are signed with the new key; the old one keeps verifying for a day, so nobody is thrown out mid-request.
With RS256 the public half is published at a keys endpoint, so another service can verify your tokens without holding a secret of yours.
Tie a token to routes, to capabilities, or to both. What is not listed is refused, and the refusal says which rule it hit.
Change an account’s password and its tokens stop, the way its login cookies already do.
Counted per address, never per account — so nobody can lock a real user out of the API by guessing at their name.
The commonest failure is the web server eating the Authorization header. The overview spots that setup and shows the three lines that fix it.
Answer on the old /jwt-auth/v1/ routes in the old shape, and accept the tokens the old plugin issued until they expire. Nothing needs redeploying on the day.
The plugin most WordPress sites use for this, and what WordPress already gives you for free.
| Feature | Lynbro API Auth | JWT Authentication for WP REST API | Application passwords |
|---|---|---|---|
| Withdraw a single token | ✓ | — | ✓ |
| Tokens expire on their own | ✓ | ✓ | — |
| Access token measured in minutes, not days | ✓ | — | — |
| Refresh tokens, rotated on use | ✓ | — | — |
| A changed password stops existing tokens | ✓ | — | ✓ |
| Tokens limited to particular routes | ✓ | — | — |
| Every refusal explained in words | ✓ | — | — |
| The sign-in route is rate-limited | ✓ | — | — |
| Same answer for a wrong name and a wrong password | ✓ | — | — |
| A list of what is currently issued | ✓ | — | ✓ |
| No upgrade notice in the admin | ✓ | — | ✓ |
For a script of your own on a server you control, application passwords — fewer moving parts, and they are already there. Reach for tokens when you need a credential that expires by itself, one a person obtains by signing in rather than by visiting their profile page, or one limited to part of the API. This plugin never disables application passwords and links straight to them.
Nothing, if you switch on the two compatibility settings. The old routes are answered from here in the old shape, with the same fields in the same places, and the tokens your clients already hold keep working until they expire. Switch the second one off once the last of them has run out.
The web server ate it. Apache running PHP as CGI or FastCGI drops that header unless told to pass it on. The overview screen detects that setup and shows the .htaccess lines that fix it — the plugin does not write to server configuration files itself.
No, and there is a test for it. A request that carries no token is left exactly as it was found.
Generated the first time a token is issued and stored so that it is not loaded on ordinary page views. Define LYNBRO_API_AUTH_SECRET in wp-config.php to keep it out of database backups entirely. It is never shown back to you in the admin.
No. There is no quota, no plan and no threshold at which anything stops working. Everything runs on your own server, so there is nothing for us to meter.