Decidim SSO and identity verification guide

Decidim SSO and identity verification: what your team is actually building

If your organization must decide who may create accounts, log in and take restricted actions such as voting or signing, this work joins two parts of Decidim: login providers, which are OmniAuth strategies configured globally or per organization, and authorization handlers, which gate the actions participants can take. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box, and any other OmniAuth strategy can be added as a custom provider. A national eID or corporate identity provider is therefore custom integration work that needs its own scope, not a settings change.

The work is harder than it looks because three separate decisions are involved. The first is login identity: proving that someone controls an account. The second is verified identity: proving a fact about that person, such as residence or membership, that qualifies them for an action. The third is per-organization policy: deciding which verifications apply to which participatory space. Mixing these together is the most common design error. A social login can prove a login identity without proving anything a vote or signature depends on, so your policy must say which handler gates which action and in which organization.

Identity data also has to map onto Decidim participant records without breaking existing accounts. Before build starts, your team should confirm how the identity provider's unique identifier will be matched to a user, what happens when an email address already exists under a different login method, and how a participant who changes address or name is handled. Decide whether unmatched identities create new accounts, are held for review, or are rejected. Each choice affects the records that auditors and moderators will later read, so write the mapping rules down before configuration.

What to confirm with your team and the identity provider: the protocol and attributes the provider exposes, who owns the callback and certificate configuration, which actions require verification, and who approves changes to those rules. Ask for a written list of the handlers and strategies in scope, the test accounts needed for each environment, and a rollback path if a provider is unavailable on launch day. These questions set the effort more reliably than any general estimate.

Plan for the work to recur. Identity providers rotate keys and change endpoints, and each Decidim upgrade can touch login code, so verification paths need regression tests and a named owner. Confirm with the Decidim documentation for your target version how social providers are configured in your deployment before committing to a design, because the configuration method and supported options depend on the release you run.

Which Decidim components and settings this integration touches

Decidim SSO and identity verification touches five connected parts: provider configuration, custom OmniAuth strategies, authorization handlers, identity records and organization scoping. A change in one can quietly alter who can log in or act, so review them together and confirm every configuration key and handler class name against the Decidim version you run.

Global and per-organization social providers

Decidim includes Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login, and each can be enabled globally or per organization. In a multi-organization instance, the per-organization scope decides which login options a city, agency or region shows its participants. Check that each provider's app registration lists the exact callback URL for every organization host, and confirm the settings keys in the social providers documentation for your version before writing them into configuration.

Custom OmniAuth strategies

Any OmniAuth strategy can be added as a custom provider, which is how a national eID or corporate identity provider is commonly connected. The strategy gem, its callback handling and the mapping from the provider's claims to Decidim user fields are the main build tasks. Confirm which strategy gem your identity provider supports, how it signs responses, and whether it returns a stable unique identifier, because that identifier decides whether a returning participant reaches the same account.

Authorization handlers that gate actions

Authorization handlers restrict actions such as voting or signing to verified participants. Because they run where the action is authorized, a participant who logs in without completing verification cannot vote, even if the login itself succeeded. List which components and actions each handler guards, and confirm the handler class names and their options for your version. Do not assume examples from another release carry over, since 0.31 and 0.32 differ in other areas.

User and identity records

An external login creates or links a Decidim user and an identity record that stores the provider name and the provider's unique identifier. These records decide whether a returning participant lands on the same account, and verification data written by the handlers is kept alongside them. Plan how existing accounts that share an email address will be merged or refused, how account deletion affects linked identities, and confirm that the database backup covers these tables before any upgrade or migration.

Organization settings that scope each policy

Login providers, verification requirements and handler options are set per organization, so each body in a shared instance can run its own policy. Map every organization to its required providers and verification level before the build, and record who owns each decision. Test that a policy for one organization does not reach another by signing in with a participant account in each organization and attempting a verified action that should fail.

Version and upgrade impact

Decidim v0.32.0 was released on July 6, 2026 with Ruby on Rails 8.1 and locale-prefixed URLs, and the 0.31 branch received v0.31.7 on September 3, 2026. Callback URLs, OmniAuth gem versions and handler interfaces can change between these lines, so each upgrade needs a regression test of every login path. Until version 1.0, only the 0.32.x and 0.31.x lines receive security updates, so upgrade one minor version at a time and back up the database first.

Which login and verification model fits your organization

This table compares four login and verification models for Decidim, plus the choice between one global login policy and separate policies per organization. Read each row for when it fits, what it costs to run, and what to settle with your identity owner before committing.

Model	When it fits	Operational cost	Confirm with the identity owner
Social login only (Facebook, Twitter, Google or Decidim-to-Decidim OAuth 2.0)	Low-stakes consultations where participants are members of the public and identity assurance is not required	Little custom code. Provider app credentials and secrets must be rotated, and provider terms and availability are outside your control. Account data is held by the social provider and by Decidim.	Whether any restricted action (voting, signing) is allowed with an unverified social account, and which providers the policy permits
Corporate IdP through a custom OmniAuth strategy	Staff, members or employees of one organization who must log in with existing corporate credentials	Your team or the partner owns the IdP connection and the strategy code. Signing certificates or client secrets need scheduled rotation, and each failed login generates support requests. Attributes received from the IdP are stored as participant data.	Protocol and metadata details, certificate lifecycle, which attributes are released, group or domain restrictions, and who approves changes to the connection
National eID used for verification	Restricted actions where the organization must confirm a participant's legal identity, such as binding votes or signatures	Ongoing dependency on the eID scheme's onboarding, certificates and availability. Verification failures need a support path. Personal identifiers may be stored, so retention and minimization must be designed in.	Whether the scheme is accepted by your legal basis, which data fields are returned, retention rules, and the scheme operator's conditions for relying parties
Verification only at a restricted action	Participation is open to anyone to register and read, but voting or signing needs proof of identity	Lower friction at sign-up. Support load concentrates at the moment of the action, and users who fail verification mid-process need clear guidance. Verification records must be kept for the period your rules require.	Which actions are restricted, the evidence an auditor or the public will expect, and whether verified status must be visible on public records
Verification at registration	Processes where every account must be verified before it can take part in anything, including comments and proposals	Higher drop-off during sign-up and more support for failed checks. Verified data is held for every registered account, which increases the retention and breach impact to manage.	Whether unverified accounts may exist at all, how existing unverified accounts are handled, and the retention period for verification data
One global login policy across organizations	Instances where all organizations share the same participant base and provider set	One set of providers, secrets and verification rules to maintain. A single change affects every organization, so testing and change control cover the whole instance.	Whether all organizations accept the same identity sources and whether a central team owns the policy
Separate login policy per organization	Instances where organizations have different governance, identity sources or legal bases	More configurations to test, rotate and document. Each organization needs its own owner for provider settings and verification rules, and support queues may need to be split.	Who owns each organization's policy, whether the legal basis differs by organization, and how cross-organization accounts are handled

How to build the Decidim login and verification flow in sequence

This sequence takes a Decidim instance from a confirmed, supported version to a tested login and verification flow in which each organization signs in through its own identity provider and verified participants alone can vote or sign. Each step ends with a check you can record before moving on.

Confirm the Decidim version and support status
Start by confirming which Decidim version you will run and whether it is still in security support. Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x, so 0.30.x and earlier are out of scope for new work. Check the supported branch on the project's SECURITY.md file and note the Ruby and Node versions the release requires, since v0.32 uses Ruby 3.4.7 and v0.31 uses Ruby 3.3.4. The output is a short written record naming the version, its support status and the runtime versions, approved by the person who owns the platform. Confirm the exact patch release with the Decidim releases page before you build anything on it.
Stage a non-production instance on the same version
Build a non-production instance on exactly the version you confirmed, using the manual installation guide or the Docker setup, with PostgreSQL configured as the installation documentation describes. Configure background jobs, file storage, SMTP and the other production services in staging so that login behavior is tested under realistic conditions rather than a bare development setup. Keep staging on the same minor version as production so that OmniAuth and authorization behavior match what you will ship. The check is a working staging login to the admin interface and a test participant account that can reach a public space, both documented in the build record.
Register the application and agree on claims
For each identity provider, register Decidim as an application in that provider's developer or administration console and record the client identifier, the secret, and the exact redirect URI for each organization host. Work with the organization's identity team to agree which claims or attributes will be sent, such as a stable subject identifier, email, name and any verification or assurance indicator the provider issues. Decide with the organization whether the identity provider or a national eID is the source of truth for verified status. The check is a signed sign-off listing the claims per organization and a provider sandbox application that returns those claims to the staging redirect URI.
Configure the OmniAuth provider per organization
Decidim includes Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login, which can be configured globally or per organization. If the chosen provider is one of these, enable it per organization in the configuration and keep its secrets in the deployment's secret store rather than in the repository. If the provider is not built in, add it as a custom OmniAuth strategy, which requires a gem or a small in-house module, tests of the callback handling, and a review of how the strategy exposes claims. Confirm each organization gets only its own provider and callback host. The check is a successful sign-in start for each organization that reaches the correct provider page and returns to the right host.
Map external identity fields to user records
Define how each claim from the provider maps to Decidim's user record, including which field becomes the unique identifier for linking a returning participant. Decide what happens on first login: whether Decidim creates a new account automatically, asks the participant to confirm details, or requires an administrator to approve the link. Decide also how a changed email address at the provider is handled, so that one person does not end up with two accounts or an account taken over by another person. Write these rules in the build record and test them with at least one new user and one returning user per organization. The check is a user record created or linked as specified, with no duplicate account appearing after a second login.
Implement the authorization handler for voting and signing
Decidim includes flexible identity verification and authorization systems that let an organization restrict actions such as voting or signing to verified participants. Configure the authorization handler that gates each restricted action, and map its requirements to the verified claims agreed in the earlier steps, such as a verification indicator from the provider or a completed eID check. Confirm which actions each organization restricts, because a process may allow proposals from any logged-in user while voting requires verification. Document the rule for each action so that moderators and auditors can explain why a participant was allowed or refused. The check is a verified test participant who can vote and an unverified test participant who is refused the same action with a clear message.
Test with real provider sandboxes
Run the full flow against each identity provider's sandbox or test environment, not only against mocked responses. Cover the cases that fail in practice: a cancelled login, an expired session, a provider returning incomplete claims, a participant who is unverified, and a participant who changes their email at the provider. Confirm that the application logs the verification outcome for each attempt without writing secrets or unnecessary personal data into the logs, and review that log output with the security team. Record results per organization and per provider. The check is a completed test matrix where every case shows the expected outcome and a log entry that records each verification decision.

What drives the effort and cost of SSO and verification work

This table lists the drivers that change how much work Decidim SSO and identity verification takes, and what each one asks of your team. Read each row as a decision point: the choices you make before build usually determine whether the work stays contained or grows across several rounds of testing. The main takeaway is that agreeing policies, attributes and test access early keeps most of the effort predictable.

Driver	Why it changes effort	How to keep it down
Organizations and login policies	Each Decidim organization can have its own social providers and login rules, so every extra policy adds configuration, testing and support paths.	Agree one shared login policy for all organizations, and document any exception before build starts.
Type of identity source	Social providers, corporate IdPs and national eIDs differ in protocol setup, onboarding and who approves access, so each source adds its own workstream.	Limit the first release to one or two sources and confirm which OmniAuth strategy each one needs.
Attribute mapping and directory quality	Missing, duplicated or inconsistent attributes in the source directory force custom mapping logic and manual cleanup.	Agree the attribute set with the identity owner before build and request a sample export to check data quality.
Restricted actions requiring verification	Each action limited to verified participants, such as voting or signing, needs its own authorization rule and its own test cases.	List the restricted actions up front and reuse one authorization handler where the rule is the same.
Account linking or migration of existing participants	Matching existing Decidim accounts to new identities adds rules for duplicates, conflicts and participants who change emails.	Decide the matching key and the conflict policy in writing, and test with a copy of real account data in a controlled environment.
Environments (development, staging, production)	Each environment needs its own identity configuration, callback URLs and test identities, which multiplies setup and checks.	Ask the identity owner for a sandbox with test identities, and keep configuration in one versioned source for all environments.
Compliance evidence requirements	Assessors may ask for records of who was verified, how checks ran and how access was reviewed, which adds logging and documentation work.	Confirm the evidence list with your auditor or compliance lead before build, and design logs for those specific questions.

How the setup changes by install method and network model

A manual installation runs Decidim as a Rails application on a server or virtual machine that your team manages directly. The installation guide targets PostgreSQL 17.4 or later on Ubuntu 24.04.3 LTS, and Decidim v0.32 requires Ruby 3.4.7 and Node 22.14.x. Because the host is yours, every SSO and verification setting lives in files and services you control, which gives full visibility but also full responsibility for consistency across environments.

Secret injection: OAuth client IDs and secrets are typically supplied as environment variables or encrypted Rails credentials. Keep them out of the repository and confirm the file permissions on the application's environment files.
Callback URLs: The redirect URI registered with the identity provider must match the public host and the locale-prefixed path that Decidim generates for each organization. Register one callback per organization host.
Certificate trust: The Ruby and system trust stores must contain the identity provider's certificate chain, including any internal certificate authority. Test this from the application user, not from your own shell.
Background jobs: Verification callbacks and post-login processing run through ActiveJob. Confirm that the job worker runs as a separate process under a service manager, so a stopped worker does not silently stall authorizations.
Logs: Application logs, web server logs and job logs are written to the local host unless you ship them elsewhere. Define the retention period and who can read authentication events.

Before go-live, check the install and update documentation for the Ruby, Node and PostgreSQL versions that match your chosen release, and confirm each item above on a staging host.

What to monitor, document and renew after go-live

After launch, the SSO and verification integration needs ongoing checks, because most failures appear as user complaints rather than as obvious errors. Set up monitoring for failed sign-ins and for authorization rejections, and break both down by organization. A spike at one organization usually points to its identity provider, its social login configuration or its verification handler, while a spike across all organizations points to a shared component such as the certificate or the callback setup. Ask your identity team which sign-in reports the provider can export, and confirm with your Decidim operator where the application logs for each organization's login attempts are kept and how long they are retained.

Certificates and client secrets expire, and an expired one stops sign-in for every user of that connection at once. Keep a register of each identity provider signing certificate and OAuth client secret with its expiry date, the person responsible for renewing it and the date the replacement must be deployed. Callback URLs need the same discipline. Whenever a hostname, a path or a locale prefix changes, the URL registered with the provider must match the one Decidim sends. Decidim v0.32 introduced locale-prefixed URLs, so confirm with your integration team whether the callback paths you registered are affected by the version you run.

Claim mappings are the link between what the identity provider sends and what Decidim stores, so they must be reviewed whenever the provider changes its attribute names, its tenant structure or its verification level. Treat any change to the provider as a change to the integration, and retest with accounts from each organization before the switch. Upgrades need the same care. Decidim's update guide asks you to move one minor version at a time, following each release's instructions and backing up the database first, because some releases change database structures. Decidim's security policy gives implementers 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed. Build your upgrade calendar around those windows, and confirm with your operator how the OmniAuth gem and the authorization code were tested against the target minor version.

The handover file is what lets a new administrator restore access when something breaks. It should contain the provider registration records for each connection, with endpoints, client identifiers and the callback URLs registered, and the attribute maps that connect provider claims to Decidim fields. It should also describe the authorization handler logic in plain language, so reviewers can see which claims grant verified status, and it needs a runbook for locked-out users, including who can reset an account and how that action is logged. Finally, record who owns each identity connection on your side and on the provider side. Ownership gaps are the most common reason a certificate renewal is missed, so review this register at every upgrade.

Securing login, verification data and identity secrets

Single sign-on and identity verification add trust to a Decidim deployment, and they also add credentials and personal data that attackers want. The cards below cover the controls that sit specifically on the login and verification path, from how OAuth secrets are stored to what gets logged when a participant is verified.

Keep OAuth secrets out of the repository

Each OmniAuth provider issues a client ID and client secret that Decidim uses to exchange authorization codes. Store them in environment variables or a secrets manager, never in configuration files committed to git, and keep them separate per organization when social providers are configured per organization. Check your repository history as well as the current tree, since a secret committed once stays exposed. Ask your identity provider how rotation is done, so a secret can be replaced without a service outage.

Enforce HTTPS on every callback

OAuth and OpenID-style flows redirect the browser back to Decidim with authorization data, so every callback URL registered with the provider should use HTTPS and match the exact production hostname. Confirm that the provider rejects mismatched or http redirect URIs, and that the Decidim host and proxy settings produce https URLs in generated links. A callback registered on a development or staging hostname is a common source of open redirect exposure and should be removed.

Limit the claims Decidim stores

Identity providers often return more attributes than the platform needs, such as full names, dates of birth, national identifiers or addresses. Map only the attributes required to create or match an account and to satisfy the verification rule you chose, and drop the rest before they reach the database. Review what the user record and authorization records keep after login. Data minimization reduces the impact of a breach and simplifies your data protection obligations.

Protect admin access to provider settings

Changing a provider's client ID, redirect target or verification handler changes who can log in and who counts as verified. Limit the admin roles that can edit these settings, require strong authentication for those accounts, and record each change with the administrator who made it. Review the list of admin users on a schedule, and remove accounts for staff who have left the organization or changed roles. Treat these settings with the same care as the database credentials.

Log decisions without raw documents

Operators need to know whether a verification succeeded, failed or was rejected, and why, to answer participant questions and to audit outcomes. Log the decision, the handler name, a timestamp and a non-sensitive reference, but not identity documents, document images, national ID numbers or full claim payloads. Confirm that application logs, error trackers and background job records do not capture request bodies from the verification step, since these often reach third-party monitoring tools.

Track advisories for every dependency

Decidim publishes security reports through security@decidim.org and GitHub Security Advisories, and it gives implementers a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed. Subscribe your team to both channels and assign an owner who checks them. Also track advisories for the OmniAuth strategy gems and the identity provider SDKs you use, since those are outside Decidim's core release notes and can affect the login path directly.

How to test that logins and verification work and fail safely

The test plan for Decidim SSO and identity verification should prove two things before launch: that every login path creates the right account, and that every failure leaves the platform in a safe state. A login that works on the happy path is only the starting point. The harder questions are what happens when a token expires, when the identity provider refuses a user, and when a participant who is logged in but not verified tries to vote or sign. Plan these cases as written test scripts, with an expected result for each, and keep the results as evidence for your own governance review.

Start with the happy path. Run a successful login for each social or custom OmniAuth provider you have enabled, and repeat it for each organization that has its own provider configuration, since Decidim supports provider settings globally or per organization. For first logins, confirm that a new user record is created once, with the expected name and email handling, and that a second login with the same identity reuses that record. Then test account linking: a participant who first signed in with one provider and later with another should land on the same account only if your rules say so. Write down the rule before testing, because the test result is only meaningful against a stated expectation.

Next, test the failure paths. Revoke a token at the identity provider and retry a session that depends on it. Let a token expire and confirm that Decidim asks the user to sign in again rather than keeping a stale session. Deny a user at the identity provider and confirm the user gets a clear message and no partial account. For verification, sign in as a participant who is authenticated but not verified, then attempt a vote or signature. The action must be refused by the authorization handler, and the refusal must not reveal which verification step is missing. Finally, simulate a provider outage by blocking the provider endpoint in a test environment. Public processes, assemblies and proposals should stay visible, while login, voting and signing should be denied with a message that offers a retry path.

Two checks cut across all of these tests. First, search application logs, background job output, error tracker payloads and public pages for verification data such as document numbers, national identifiers, dates of birth or raw provider responses. Run the search after each failure scenario, not only once, because error handlers often log more than the happy path does. Second, test the rollback path. Disable the integration for one organization, confirm that its login and verification options disappear, that existing accounts and votes are not altered, and that other organizations keep working. Confirm with your identity provider and eID operator how a disabled configuration should be handled on their side, and ask the implementation partner to document the exact steps in the runbook.

Questions buyers ask before hiring help with Decidim SSO

Can our own developers build Decidim SSO without a partner?

Yes, if your team has Ruby on Rails experience and will own the work after launch. Decidim is open source and supports custom OmniAuth providers, so an in-house developer can add an identity provider login. The code is the smaller part of the job. The larger part is testing against your identity provider's test environment, mapping returned attributes to Decidim profiles, deciding who may register and who may be verified, documenting the setup, and retesting login through every Decidim upgrade. Those tasks compete with the people who already run the platform. Before deciding, ask who will carry the work through upgrades, because each supported minor version change can affect authentication code.

What drives the cost and timeline of a Decidim SSO project?

The main drivers are scope, the number of identity sources, and how much the other party has to do. A single corporate identity provider with a documented protocol is a smaller job than several providers, a national eID, and separate rules for each organization on the same instance. Attribute mapping, test cases, security review, and access to sandbox environments all add time. Costs fall into two groups: one-time build and testing, and recurring work such as renewing certificates or secrets, retesting after upgrades, and handling provider changes. When you request a quote, ask for an itemized scope, the assumptions it depends on, the test cases included, and what the handover package contains. Internal staff time is a cost even when no invoice shows it.

What do we need to provide before SSO work starts?

You need to provide access, decisions, and a named owner. Typical inputs include administrator or client registration access to the identity provider, sandbox or test credentials, and the callback URLs your environment will use. Attribute agreements should list which claims the provider releases, their format, and what each one maps to in Decidim. Someone must own policy decisions: who may log in, which organizations may use which providers, and what counts as verification for each action such as voting or signing. You also need staging access that matches production closely enough to test, and a person who approves production changes. Missing any of these usually pauses the project, so confirm each item in writing before scheduling build work.

Do social logins count as identity verification for Decidim?

No. A social login alone usually proves control of an account, not that a participant is who they claim to be or is eligible to act. Decidim supports Facebook, Twitter, Google, and Decidim-to-Decidim OAuth 2.0 login out of the box, and these can be enabled globally or per organization. Whether a social login counts depends on the authorization handler you configure and the policy behind it. For example, an organization that lets any verified Google account vote has a different assurance level than one that requires a government-backed check before voting. Decidim includes authorization systems that restrict actions to verified participants, so the policy decision belongs to your legal and governance owners, not to the developers who configure the handler.

Can a national eID connect to Decidim without a custom OmniAuth strategy?

It depends on whether your eID provider supports a protocol that an existing OmniAuth strategy already handles in your Decidim version. Decidim accepts any OmniAuth strategy as a custom provider, so a custom strategy is one route. It may be avoidable if the eID offers a standard protocol and a maintained library. Confirm with the eID provider which protocol, SDK, and library they support, whether they publish a Ruby or OmniAuth integration, and which Decidim minor version they have tested against. Also confirm which identity attributes the eID returns and how they map to the authorization handler you need. Ask the provider in writing, and test the chosen approach on the Decidim version you actually run before committing to a design.

Which Decidim versions should we confirm before scoping SSO changes?

Confirm that your instance runs 0.32.x or 0.31.x, the two minor versions that receive security updates until version 1.0. Earlier versions, including 0.30.x and older, are not supported. Decidim v0.32.0 was released on July 6, 2026 with Ruby on Rails 8.1, followed by v0.32.1 on July 30, 2026. The 0.31 branch received v0.31.7 on September 3, 2026. Version 0.32 requires Ruby 3.4.7 and version 0.31 uses Ruby 3.3.4, with Node 22.14.x for both. Decidim allows implementers two months to apply patches for standard vulnerabilities and four months for critical ones before details are disclosed. Upgrade one minor version at a time, follow each release's instructions, and back up the database first, because some releases change database structures.

What do we keep after the SSO handover is complete?

You should keep ownership of the code, the configuration, the credentials, and the documentation. Ask for the provider configuration and any custom code in a repository your organization controls, with access granted to your staff. Secrets, client credentials, and certificates should live in your own secret store, with a record of who can rotate them. The handover should include the attribute mapping, the authorization rules per organization, the test cases, and a runbook covering login failures, certificate renewal, and provider changes. Also confirm who receives security advisories for Decidim and how patches will be applied, since those timelines constrain SSO work. Recurring costs continue after handover, so decide in advance whether your team or a retainer will handle upgrades and retesting.

How do authorization handlers work alongside single sign-on in Decidim?

Single sign-on establishes who logged in, while authorization handlers decide whether that account may perform a specific action. After a participant signs in through a provider, the handler checks the attributes or verification result it requires. If the check passes, the account is authorized for actions such as voting or signing; if it fails, the action stays blocked. Decidim's identity verification and authorization systems let organizations set these rules per action. Illustrative example: a login may be enough to comment on a proposal, but voting may require a verified attribute from an eID. Engineers should test both the login path and each handler outcome, including rejected and expired checks, and confirm the rules with the policy owner before launch.

How DeployOpen works on this

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and Decidim identity work follows the same path. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm which identity provider, national eID or social login providers the organization needs for Decidim participants.
Record which actions, such as voting or signing, must be restricted to verified participants and which stay open.
Agree in writing which organizations on the instance get which login methods and authorization handlers.
Identify the Decidim version and hosting environment, since the work depends on the supported release line in use.

How we build

Configure OmniAuth strategies for the chosen identity provider or eID and test the callback flow end to end.
Set per-organization social login settings and confirm each organization only exposes the providers it should.
Implement or configure authorization handlers so verification rules match the agreed participant restrictions.
Test failed, expired and duplicate verification cases, and confirm personal data is handled as the written scope specifies.

How we hand over

Deliver configuration, custom provider code and authorization handler documentation for the organization's own engineers.
Provide a runbook covering secrets, callback URLs, provider certificate renewal and how to add another organization.
Walk the client's team through verification test cases so they can repeat them after each Decidim upgrade.
Confirm the handover items listed in the written scope are accepted before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Re-test login and verification flows when identity providers change their endpoints or when Decidim is upgraded.
Keep identity configuration aligned with the supported Decidim minor versions, upgraded one minor version at a time.
Agree response expectations and the testing cadence in the retainer scope, not in general terms.

Decidim SSO and identity verification