Another Plone site

Another Plone site#

Sign in to this site with accounts that live on a different Plone site.

The other site needs pas.plugins.identity[server] installed and acting as an authorization server. This site needs only the core layer.

Note

Verified against the demo stack on 2026-09-05. Federate two Plone sites builds exactly this, end to end, in Docker.

1. What you need from the other site#

Ask whoever runs it for:

Issuer URL

its base URL, for example https://id.example.com

Client ID

minted when they register your site

Client secret

shown once, when the client is created

They create the client by following How to register an OAuth client, giving your redirect URI:

https://www.example.com/login-identity

Warning

The client secret is displayed once, in the response that mints it. It cannot be recovered afterwards. If it is lost, they rotate it and give you a new one.

2. Add the provider#

  1. Open the Identity providers control panel.

  2. Add a provider and choose the Plone site driver (plone-identity).

  3. On the Settings tab, fill in:

    Field

    Value

    Title

    what the button should say, for example id.example.com

    Issuer

    the other site's base URL

    Client ID

    from step 1

    Client secret

    from step 1

    Scope

    leave empty to use the driver's default

    The default scope is openid email profile address. The address scope is what this driver adds over the generic OIDC one, because a Plone profile has a location field worth carrying across.

  4. Save.

Everything else—the authorization endpoint, the token endpoint, the signing keys—is fetched from <issuer>/.well-known/openid-configuration at runtime. You do not configure any of it.

3. Test the connection#

Use the Test connection action on the provider.

It fetches the discovery document, clearing the cache first, and reports what it found. A failure here is a wrong issuer, a firewall, or a site that has not applied the server profile.

4. Decide what the other site is allowed to mean#

On the Accounts tab:

Field

Set it to

Why

Trust this provider's email verification

on, if you run both sites

See How to link accounts by email

Attach to an existing account with the same verified email

on, to merge with existing accounts

Needs the switch above

Let this provider create accounts

on, unless membership is decided here

See How to control account creation

A Plone site running this package releases email_verified: true only for addresses it has actually verified, so trusting it is reasonable when you run both ends. Trusting a site you do not run is a decision about that site's sign-up rules, not about this software.

5. Map its groups, if you want them#

On the Groups tab, leave Groups arrive in the claim at groups—that is what a Plone site running the server layer emits.

Then add one row per group you want to honour. See How to map provider groups.

An unmapped group grants nothing and is never created here.

6. Sign in#

Open /login. The provider's button is there.

Signing in sends you to the other site, which asks you to approve the request once, and returns you here signed in.

Verify#

  • /identities on this site lists the new identity, naming the provider.

  • The audit log has an authenticated entry for it—see How to read the audit log.

  • The user's profile carries the fullname, email and, if you mapped them, the website, description, location and portrait that came across.

Known quirks#

  • The issuer must resolve from both places. Your browser follows it to sign in, and this site's server fetches discovery from it. In containers those are often different networks and the same URL has to work in both.

  • Consent is asked once per user and client. To see it again, withdraw the application's access from /applications on the other site.

Contents