Plugin idea: sign-in providers (OpenID Connect, passkey policies) for shared and hosted installs #1261

New issue

Open

opened 2026-11-13 10:51:55 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-11-13 10:51:55 +00:00

Owner

Idea

Postulo signs people in with a password, passkeys, TOTP and recovery codes. A shared or hosted install (a school, an employment office, a family server) may need OpenID Connect (Keycloak, Authentik, Authelia, Entra, Google), or a policy that requires passkeys. A plugin could add a provider without core carrying every protocol.

What to settle

Whether sign-in can be a plugin at all given what depends on it (account recovery, the transport lock of #104, the invitation flow, the API tokens); the security review (SEC2, #992) is the standard any change here meets.
Account linking and the rule that an external account never grants more than the person has locally; the first sign-in's rules with registration closed.
Removing the provider must never lock anyone out.

Wanted

A design note first, reviewed against the authentication issues already closed, then a reference OIDC plugin if the design holds. It may conclude that core should keep this and only document the setup behind a reverse proxy.

Rules that apply to every plugin

Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (plugins/consent.py); nothing is fetched on page load.
Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed.
The plugin surface (plugins/api.py, the published postulo.plugins.testing check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only.
Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI).

Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). Not started; the maintainer decides if and when.

## Idea Postulo signs people in with a password, passkeys, TOTP and recovery codes. A shared or hosted install (a school, an employment office, a family server) may need **OpenID Connect** (Keycloak, Authentik, Authelia, Entra, Google), or a policy that requires passkeys. A plugin could add a provider without core carrying every protocol. ## What to settle - Whether sign-in can be a plugin at all given what depends on it (account recovery, the transport lock of #104, the invitation flow, the API tokens); the security review (SEC2, #992) is the standard any change here meets. - Account linking and the rule that an external account never grants more than the person has locally; the first sign-in's rules with registration closed. - Removing the provider must never lock anyone out. ## Wanted A design note first, reviewed against the authentication issues already closed, then a reference OIDC plugin if the design holds. It may conclude that core should keep this and only document the setup behind a reverse proxy. ## Rules that apply to every plugin - Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (`plugins/consent.py`); nothing is fetched on page load. - Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed. - The plugin surface (`plugins/api.py`, the published `postulo.plugins.testing` check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only. - Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI). Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). **Not started; the maintainer decides if and when.**

tiagoagueda added the

enhancement

label

2026-11-13 10:51:55 +00:00