Nonprofit Single Sign-On: One Login for Members and Donors

A non-profit can give members and donors one login across its website, member portal, events system and donation tools by putting a single identity service in front of them, so each tool asks that service who the person is and nobody keeps a separate password per tool. The work is mostly a decision about which tools join first and who owns the service, and the part most worth planning is cost, because many identity services charge per user, so a successful membership drive raises the bill.

This post is for the director of IT, head of technology or technical lead at a membership organization, charity or other non-profit with roughly 20 to 300 staff. It covers why members end up with several logins, what one shared login involves, how to budget for it on grant-funded terms, which security questions funders and boards tend to ask, and how much a small team can realistically run itself.

Why do members and donors end up with four logins?

Most non-profits assemble their tools over years, and each tool arrives with its own accounts. The website has a member area, the donation platform keeps its own donor records, the events system has registration accounts, and the learning or volunteer platform has another set. Each one asks the same person to choose an email and a password, and each one keeps that data separately.

For the person on the other side, this means four passwords to remember and four places to reset when one is forgotten. A member who registered for an event last year with a personal email and renewed their membership this year with a work email now looks like two people in two systems. For your staff, it means password-reset requests that arrive at several inboxes, and it makes simple questions harder to answer, such as which members also donate.

We have no survey data on how often this causes members to abandon a sign-up or a donation, and we would not trust a number quoted without a source. The cost that you can measure yourself is support time: look at the last quarter’s tickets and count the ones that were about signing in, resetting a password or finding which email an account was registered under. That count is a better basis for a business case than any industry figure.

What does one login across your tools involve?

One login means that the member’s account lives in a single identity service, and the other tools delegate sign-in to it. When someone opens the events system, it redirects them to the identity service, they sign in there (or are already signed in from a visit to another tool), and they return with proof of who they are. The standards that make this work are OpenID Connect and SAML, and most membership, donation and event platforms support at least one of them, usually under a name such as “single sign-on” or “SSO” in their settings. Our explanation of SAML vs OIDC covers the difference if you need to match a tool’s options.

In practice, a shared login covers four things:

• One account per person for the website, member portal, events and donations, so the same email and password work everywhere.
• Social sign-in as an option, so people can use an existing Google, Apple or Microsoft account instead of creating another password.
• Roles in one place, so staff, volunteers and members get different access. A volunteer coordinator can see event registrations without seeing donation history, for example.
• One place to remove access, which matters when a staff member or volunteer leaves. Our guide to the joiner, mover and leaver process explains how to make that routine.

Two caveats apply. A tool has to support external sign-in at all, and some donation platforms handle payments in their own hosted pages, where they will keep their own donor record whatever you do. Start by listing the tools your members actually use and checking each one’s documentation for SSO support before you commit to a plan.

How do you budget for identity on a grant-funded budget?

The main budgeting question is how the vendor’s pricing scales. Many identity services charge per user or per monthly active user, which means the invoice grows when your membership grows. For an organization whose goal is to grow its community, that works against you, and it is hard to forecast when a campaign can double the number of active accounts in a month.

The alternative is a model where you pay for the infrastructure the identity service runs on, and users are not counted. Skycloak works this way: users are unlimited on every plan, and the price depends on the plan and the number of clusters, which are separate environments such as a test one and a live one. The monthly plan prices are Developer at $29, Launch at $149 and Business at $599, with Enterprise priced per contract, and annual billing takes 20% off. Registered 501(c)(3) organizations and charities get 15% off. Additional clusters cost more, so the bill grows with the number of environments and regions you run and not with the number of people who sign in. The pricing page has the current detail.

How do you estimate the first year without surprises?

A realistic estimate has four parts, and only the first is the subscription:

1. The subscription, which is the plan price multiplied by twelve, less any annual-billing or non-profit discount. This is the number a funder will ask to see as a line item.
2. Setup time. Count how many tools you will connect, and allow staff or contractor hours for each. Tools with built-in SSO support take far less time than ones that need a custom integration.
3. Migration of existing accounts. If your members already have accounts in several systems, someone has to decide which record wins when the same person appears twice. Plan for a cleanup pass.
4. Ongoing time for adding tools, answering the occasional access question and reviewing who has admin rights. Track the hours during the first year and use your own figure for later budgets.

Two things worth asking any vendor are what happens to the price if you add a second environment, and how you would take your accounts with you if you left. At Skycloak, Launch and above can export a full realm, including users and password hashes, as an encrypted standard Keycloak file, which imports into any Keycloak server. Realm export is not available on the Developer plan. The same question deserves an answer from every vendor on your list, and our guide to identity service contracts and SLA requirements lists what to ask for in writing.

What security questions do funders and boards ask?

Funders and boards generally want to know that member and donor records are protected, and the questions tend to fall into two groups.

Multi-factor authentication. They will ask whether the people who can see donor data have MFA turned on, meaning a second proof of identity such as an authenticator app on top of a password. A shared identity service lets you require it for staff and administrators once, instead of enabling it separately in each tool and hoping nobody was missed.

Who can see records, and how access ends. They will ask who has access to member and donor records and how that access is removed when someone leaves. With one identity service, removing a person there removes their ability to sign in to every tool that relies on it for sign-in; sessions already open last until they expire, and tools that keep their own accounts need a separate step. An audit trail of sign-ins (available on Skycloak’s Launch plan and above) shows who signed in to which connected tool and when. Our guide to user access reviews describes how to check that access list on a regular schedule, and what security questionnaires ask about login lists the wording these questions usually take.

If a funder asks for independent assurance, Skycloak’s security page describes its controls, and its SOC 2 Type II report is shared under NDA alongside its ISO 27001 certification. Hosting is available in four regions (US East, EU Central in Germany, Asia Pacific in Sydney and Canada), which matters if your members’ data has to stay in the US, the EU, Australia or Canada.

Who runs it, and what can a small team take on?

The software has to run somewhere, and someone has to keep it updated and secure. There are two realistic options for a small team. You can run an open source identity server such as Keycloak yourself, which costs staff time for upgrades, patches, backups and monitoring. Or you can use a managed service, where the provider runs the infrastructure and applies the updates. At Skycloak that covers upgrades and security patches, infrastructure and uptime monitoring, and certificates and your custom sign-in domain. You keep your members’ accounts, your branding on the sign-in page, and control over who has admin access.

If you have no one on staff with identity or security experience, the managed route is usually the more realistic one, since the work that is hard to do part-time is the patching and the monitoring. Our guide to picking an identity vendor without an identity team and the worksheet on what login costs your engineering team each quarter help you compare the two on your own numbers. The non-profits page summarizes how Skycloak fits this case.

A checklist to take to your next board or finance meeting

• List every tool where members, donors or volunteers have an account, and mark which ones support SSO.
• Count last quarter’s sign-in and password-reset tickets to establish your starting point.
• Decide which tools join first, usually the member portal and the events system.
• Ask each vendor how pricing changes as your membership grows, and whether there is a non-profit discount.
• Decide who is the named owner of the service and who is the deputy.
• Agree that staff and administrators with access to donor data must use MFA.
• Confirm how you would export your accounts if you changed provider.
• Put the subscription, setup time and ongoing hours into the budget as separate lines.

Frequently asked questions

Can a non-profit use single sign-on for members and donors, not only staff?

Yes. The same identity service can sign in staff, volunteers, members and donors, with different roles for each. The usual limit is whether each connected tool supports external sign-in.

Do we need single sign-on for every tool at once?

No. Most organizations connect the member portal and the events system first and add other tools later, as each one’s SSO support and renewal date allow.

Does one login mean one shared password for everyone?

No. Each person has their own account. “One login” means that a single account works across your tools instead of each tool keeping its own.

What happens to our budget if membership doubles?

It depends on the vendor’s pricing model. With per-user or per-monthly-active-user pricing, the bill grows with membership. With infrastructure-based pricing, as on Skycloak where users are unlimited on every plan, the price changes when you add environments or move to a larger plan and not because more people sign in.

Is there a non-profit discount?

Skycloak gives registered 501(c)(3) organizations and charities 15% off. Check any other vendor’s terms directly, since discounts differ.

Can we take our member accounts with us if we change provider?

On Skycloak’s Launch, Business and Enterprise plans you can export a realm, including users and password hashes, as an encrypted standard Keycloak file that imports into any Keycloak server. It is not available on Developer. Ask every vendor for their equivalent in writing before you sign.

Summary

One login for members, donors and events tools replaces several separate accounts with a single identity service that your tools sign in through. To plan it, list your tools and their SSO support, count the sign-in tickets you have today, and choose a pricing model that does not grow with your membership. Then name an owner, require MFA for anyone who can see donor data, and bring the subscription, setup and ongoing hours to your finance meeting as separate lines.