AuthDock is one authentication plugin instead of five: social login, magic links, passkeys, two-factor authentication, brute-force protection, audit logging, session control and wp-admin access rules — with a WordPress-native UI, a REST API, and nothing phoning home.
Every feature ships switched off; turning one on is your decision. There is no telemetry, no licence check and no upsell, and with everything off the plugin makes no outbound request at all.
Every form is a shortcode, a block and a theme-overridable template, so the login, registration, password-reset and account screens can live anywhere in your theme.
The feature list is below. What each feature does and does not send to a third party is under External services; what is stored, and for how long, is under Privacy.
External services
AuthDock contacts a third-party service only where you have switched on a feature that
needs one, and never otherwise. There is no telemetry, no usage reporting, no licence
check, and no phone-home of any kind. Every feature below is off by default, and with all
of them off the plugin makes no outbound request at all.
Ten features can talk to somebody else’s server. Each is listed here with what is sent,
when, and to whom.
1. Social Login
When: a provider is configured with your own OAuth credentials and a visitor clicks its
sign-in button.
Clicking a provider’s button redirects the visitor’s browser to
that provider, carrying the client ID you configured, the redirect URL back to your site, the
requested scopes, and a single-use state and PKCE challenge. Your site then makes one
server-to-server request to exchange the returned code for an access token, and one to read
the profile it grants. AuthDock reads only the account ID, display name, email address,
email-verified flag, and avatar URL from that profile, and sends the provider nothing about
your site or its other users.
If no provider is enabled, none of this runs.
- Google OAuth —
accounts.google.com,oauth2.googleapis.com,www.googleapis.com— Terms | Privacy - Facebook Login —
www.facebook.com,graph.facebook.com— Terms | Privacy - GitHub OAuth —
github.com,api.github.com— Terms | Privacy - X (Twitter) OAuth —
twitter.com,api.twitter.com— Terms | Privacy - Sign in with Apple —
appleid.apple.com— Terms | Privacy - Microsoft / Entra ID —
login.microsoftonline.com,graph.microsoft.com— Terms | Privacy - LinkedIn —
www.linkedin.com,api.linkedin.com— Terms | Privacy - Discord —
discord.com— Terms | Privacy - Twitch —
id.twitch.tv,api.twitch.tv— Terms | Privacy - Slack —
slack.com— Terms | Privacy
Apple is the one that behaves differently: it returns the account holder’s name once, in the
form POST of the very first sign-in and never again, and it offers a relay address ending
@privaterelay.appleid.com in place of a real one. AuthDock stores the name on that first
sign-in because there is no second chance, and treats a relay address as a real address.
2. Bot Protection, when a CAPTCHA provider is selected
When: Bot Protection is enabled and its provider is set to Turnstile, hCaptcha or
reCAPTCHA. The default provider is Proof of work, which runs entirely in the visitor’s
browser and contacts nobody.
With a CAPTCHA provider selected, the visitor’s browser loads that provider’s script, and
the provider sets and reads its own cookies under its own domain. When the form is
submitted, your site makes one server-to-server request to the provider’s verify endpoint
carrying the secret key you configured, the token the widget produced, and the visitor’s IP
address. Nothing about the account being signed into is sent.
- Cloudflare Turnstile —
challenges.cloudflare.com— Terms | Privacy - hCaptcha —
js.hcaptcha.com,api.hcaptcha.com— Terms | Privacy - Google reCAPTCHA —
www.google.com/recaptcha— Terms | Privacy
3. Breached-password detection
When: Breached Passwords is enabled and somebody registers, resets a password, or
changes one on their profile.
Your site SHA-1 hashes the password and sends the first five hexadecimal characters of
that hash and nothing else to Have I Been Pwned’s range API. The service answers with the
suffixes of every breached hash sharing that prefix, and the comparison happens on your
server. The password does not leave your site, and neither does its full hash — this is the
k-anonymity model the service was designed around. No account name, email address or IP
address is sent. Responses are cached for 24 hours. If the service is unreachable the check
is skipped and the password is allowed, so an outage there never blocks a login here.
4. Location & Network rules, when a database URL is configured
When: Location & Network is enabled and you have pasted a database download URL into
its settings. There is no default URL and no built-in provider — with the field empty,
nothing is ever downloaded.
A weekly scheduled task fetches the file from the address you gave it and stores it under
wp-content/uploads/. It is a plain download: no visitor data, no site data, and no IP
address is sent, and it happens on a schedule rather than on a request. Look-ups afterwards
read the local file. If your host already reports a country — Cloudflare’s CF-IPCountry,
or a server-configured GEOIP_COUNTRY_CODE — that is used instead and no download is
needed at all.
The address is whatever you configure. If you point it at MaxMind’s own endpoint you are
using their service under their terms with your own licence key:
5. Single sign-on (OpenID Connect)
When: you have added an OIDC provider of your own — Okta, Auth0, Keycloak, Entra ID,
Google Workspace, or anything else that publishes a discovery document — and somebody uses
it to sign in. There is no built-in provider and no default address.
Your site fetches the discovery document and the signing keys from the issuer URL you
configured, over HTTPS only, and caches both. Sign-in is the same OAuth exchange as above,
with the identity token’s signature verified against those keys on your server. AuthDock
reads the subject, name, email address, email-verified flag and — if you have configured
role mapping — the group claim. Nothing about your site or its other users is sent.
- Your OIDC provider (only the issuer you configure) — their terms and privacy policy
6. Text-message codes
When: SMS is enabled as a second factor and you have connected a gateway yourself.
No SMS provider ships with this plugin. There is no account, no balance and no
credentials of ours anywhere in it, and none of your messages pass through anything of ours.
Connecting Twilio, Vonage, MessageBird, AWS SNS or a corporate gateway is a filter —
authdock_send_sms — and until something is hooked to it, no message is sent and no
outbound request is made. What is sent, and to whom, is entirely determined by the gateway
you connect.
- Your SMS gateway (only the one you connect) — their terms and privacy policy
7. Log streaming (webhooks)
When: Log Streaming is enabled and you have entered a webhook URL. There is no default
endpoint.
Security events are POSTed as JSON to the HTTPS address you gave, after the response has
already been returned to the visitor, so an endpoint that is slow or gone never delays a
sign-in. Each request carries the event type, the account ID, the event’s context, your
site’s URL and a timestamp, signed with an HMAC-SHA256 of the body using the secret you set.
Which categories are sent is your choice. Plain HTTP endpoints are refused. A failed
delivery is retried four times over about an hour and then given up on.
- Your webhook endpoint (only the one you configure) — their terms and privacy policy
8. Scheduled log exports
Never leaves your server. A retention copy is written as JSON Lines into a directory
under wp-content/uploads/ that is closed to the web server. If you give it an email
address, it sends a note saying an export was written and how many entries it holds — never
the log itself, which would put your whole audit trail through a mail server. Listed here
because it writes files, not because it contacts anybody.
9. Passkeys
Never. WebAuthn is verified entirely on your own server — the CBOR parsing, the COSE key
handling and the signature checks are all implemented in this plugin. No attestation is sent
anywhere and no third party is contacted. It is listed here only to say so.
10. Telegram notifications
When: you connect a Telegram bot on the Delivery Channels screen and choose Telegram as a
delivery channel. Off until you do, and the plugin contacts Telegram at no other time.
Where: https://api.telegram.org — Telegram Bot API, operated by Telegram Messenger Inc.
What is sent: the text of the notification. That is the same content the email version
carries — for example the IP address that was locked out, the username an attempt used, and
the time. Also your bot token, which is how the API authenticates the request.
When else: while somebody is connecting their own Telegram account, the site reads the
bot’s pending messages so it can match the one-time token they were given. That reads only
messages sent to your own bot, and only during the minute or two somebody is linking.
Terms: Telegram Terms of Service ·
Telegram Privacy Policy ·
Bot API Terms
What is stored: your bot token, encrypted; the chat ID alerts are sent to; and, for each
member who connects their own account, that member’s Telegram chat ID and handle. Member
linking is off by default. All of it is removed when the plugin is uninstalled, is included
in a personal-data export, and is removed by a personal-data erasure.
Reporting a security issue
This plugin is the front door of the site it runs on, so security reports are welcome and
are handled ahead of feature work.
Please do not report a vulnerability in the WordPress.org support forum or a public issue
tracker. Report it privately instead, by opening a security advisory at
https://github.com/FlyToRakib/AuthDock/security/advisories/new — which is private by
construction and can issue a CVE — or by asking for a private channel through the contact
form at https://degird.com/.
You can expect acknowledgement within three working days and an assessment within seven.
Disclosure is coordinated: a fix ships first and the advisory follows. Reporters are
credited by name in the release notes unless they ask not to be.
Findings that require a site administrator to act against their own site are out of scope,
as are the documented break-glass constants behaving as documented — they exist so a
locked-out administrator can get back in, and they require access to wp-config.php.
The full policy, including scope and supported versions, is in SECURITY.md in the source
repository.
Privacy
What AuthDock stores. The audit log records authentication events — sign-ins, failed
attempts, lockouts, two-factor changes, password resets — each with the IP address and user
agent of the request. Lockouts are stored against an IP address. Two-factor secrets, backup
codes, magic-link tokens and trusted-device records are stored hashed or encrypted, never in
plain text.
How long. The audit log is trimmed on a schedule you set on the Audit Log screen —
30 to 365 days, or unlimited. Lockout records expire on their own. Magic links expire in
minutes, and trusted devices on the duration you configure.
How much. The What to Record setting on the Audit Log screen chooses between
everything, security events only, and failures only, so a site that does not want a record of
every ordinary sign-in does not have to keep one.
How much of an address. The Addresses setting on the same screen chooses between
storing the whole address, the network only (198.51.100.0), a one-way hash, and nothing at
all. It defaults to the whole address, which is what the plugin has always done. Lockouts and
the allow and block lists are deliberately unaffected — they have to compare a real address
against a range, so anonymising them would switch the protection off. They keep an address
only for as long as the block lasts.
On uninstall. Deleting the plugin removes its settings, its tables and its user meta by
default. If you need the audit log to outlive the plugin — as a compliance record often must
— switch on Keep my data when the plugin is deleted on the Audit Log screen before
deleting.
Data subject requests. AuthDock is registered with WordPress’s own privacy tools. Tools
Export Personal Data returns the account’s connected social accounts, known addresses,
remembered devices and last sign-in, plus every audit row belonging to it. Tools Erase
Personal Data deletes those account records and strips the account, address and browser from
its audit rows, keeping the events themselves — an audit trail a request can empty is not one.
Two-factor secrets and backup codes are kept, and the report says so: removing them would lock
the account out of its own second factor. Deleting the account removes them.
Suggested policy text. Settings Privacy Check the policy suggestions includes an
AuthDock section describing what is collected and for how long, using the retention period
this site actually has configured.
The full inventory — every field, where it lives, why, its lifetime, and three gaps named
rather than left to be found — is in docs/PRIVACY.md in the plugin’s repository.
Bundled libraries
AuthDock ships one third-party library, unmodified and unminified:
- QRious 4.0.2 (
admin/js/vendor/qrious.js) — neocotic/qrious,
GPL-3.0. Draws the enrolment QR code in the browser, so a two-factor secret is never sent
to a QR image service. It loads on the profile screen only, and only while enrolling.
It is the distribution its author published, copied by bin/build-vendor.js and verified
byte for byte by npm run check:build — there is no minification step to reproduce, because
the file that runs is the file that was released.
QRious is GPLv3 and AuthDock is GPLv2-or-later, which permits the combination; the plugin as
distributed is therefore effectively GPLv3. Both are GPL and both are compatible with the
WordPress.org guidelines.
Screenshots
Dashboard — Overview of authentication activity with live stats and quick feature toggles.
Social Login Settings — Configure Google, Facebook, GitHub, and X OAuth providers with button style options.
Magic Link Settings — Configure link expiry, rate limiting, allowed roles, and force-magic mode.
Two-Factor Authentication — TOTP and email-based 2FA setup with QR code provisioning and backup codes.
Login Protection — Brute force settings with progressive lockout, IP whitelist/blacklist, and notification options.
Dynamic Redirects — Role-based login and logout redirect rules with first-login redirect.
Audit Logs — Searchable, filterable log of all authentication events with CSV/JSON export.