| 开发者 | mpmike |
|---|---|
| 更新时间 | 2026年10月23日 06:00 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
[agentid_login] shortcode and a Gutenberg block for anywhere else.client_secret_basic, and require PKCE (S256).For applications, yes — AgentID does not charge sites per sign-in. You register your own application and there is no usage pricing. This plugin is also free and open source.
No — and no plugin could. Registering an application asserts ownership of a site, so it has to be done by the site owner in their own AgentID console account. The plugin's job is to make everything on the WP side a copy-paste.
No. The agent gets its own account on your site. The account records who the owner is (when AgentID returns owner details), and its permissions are capped at the owner's when one is recorded — but the agent never receives the owner's credentials or session.
It can no longer start new sign-ins. A session your site already issued runs until it expires, which is why this plugin keeps agent sessions short by default.
Yes. With WooCommerce active, the button also appears on the WooCommerce login form, and agent accounts are ordinary WP users, so customer-role provisioning and My Account work as expected. HPOS compatibility is declared. Store-management roles (such as Shop manager) count as administration roles for agents and cannot be assigned to agent accounts.
Uninstall keeps the agent user accounts (they belong to your site) but removes their AgentID identity data. On reinstall, an agent whose account used a placeholder email address reconnects to its retained account automatically on its next sign-in, rejoining at the site's configured default role for agent accounts — the placeholder is derived from the agent's immutable ID, so it can only match that agent's own account. An agent whose account used a verified email address cannot be matched automatically (an agent is never signed in to an existing account by email alone); an administrator can reconnect it by adding the agent's subject ID as the agentid_sub user meta on the retained account, or delete the retained account and let it be re-created on the next sign-in.
WordPress sessions belong to user accounts, so a verified agent identity needs a local account to hold its session, role and sign-in record — the same reason other SSO integrations provision accounts. An account is created only after AgentID's signed ID token passes verification (signature, issuer, audience, expiry, nonce, and an actor_type of "agent"; every check fails closed), and accounts are matched by the agent's immutable AgentID subject ID, never by email. The account receives the site owner's configured default role only when that role grants none of the plugin's hard-denied site- and store-administration capabilities; otherwise the least-privileged stock role is used, and if no safe role exists, provisioning is refused. While the plugin is active, those capabilities stay denied to the account whatever role it holds, and the account cannot use passwords, password resets, or application passwords. One boundary to know: sign-in completes through the plugin's OIDC callback, which issues the standard WordPress auth cookie and fires the standard wp_login action, but does not run the authenticate filter chain — login-policy plugins that enforce rules only inside that filter do not apply to AgentID sign-ins.
No. It is an independent community integration, built on AgentID's public documentation. AgentID and AgentMail are trademarks of their respective owners.