Reader SSO — let your people open your library with their work account
Set up single sign-on for the people who read your publications, so employees, students or members open your library with the account they already have — no separate ZenFlip password.
Reader SSO
Reader SSO lets the people who read your publications sign in with the account they already have at your organization. An employee opens your library, is sent to your usual sign-in page, and comes back with their library ready. No ZenFlip password is issued, reset or revoked, and somebody who leaves loses access when their directory account is switched off.
This is an Enterprise plan feature, set up under Settings → Reader SSO.
Reader SSO is not the same thing as SSO / SAML
ZenFlip has two separate single sign-on setups, and they are not interchangeable:
Who it signs in | Where to set it up | |
|---|---|---|
SSO / SAML | your back-office team — the people who upload and publish | Settings → SSO / SAML |
Reader SSO | your readers — employees, students, members | Settings → Reader SSO |
They are different applications in your identity provider, with different reply URLs and their own on/off switches. That is deliberate: your publishing team and your five thousand readers are not the same people, and you will almost certainly want them switched on at different times. Registering one application for both would make every reader a dashboard user.
What you need before you start
The Enterprise plan
Admin access to your identity provider — Microsoft Entra ID, Okta, or any
OIDC or SAML 2.0 provider
Ten minutes in your provider's console
Use OpenID Connect if your provider offers it, and Microsoft Entra ID does. It is the option ZenFlip recommends on the settings page, it needs fewer values, and there is no certificate to rotate.
Setting it up
1. Register an application in your identity provider
Create a new application for your reader library — separate from any existing ZenFlip application for your staff.
For OpenID Connect, ZenFlip gives you two values to paste in, on Settings → Reader SSO under Paste these into your identity provider:
Redirect URI — where your provider sends people back after sign-in
Sign-out redirect URI — where it sends them after signing out
For SAML 2.0, ZenFlip gives you three:
Entity ID (audience)
Reply URL (ACS)
SP metadata URL — import this if your provider accepts a URL; it saves
typing and keeps our certificate current
2. Fill in your provider's details in ZenFlip
For OpenID Connect you need the issuer URL, a client ID and a client secret from the application you just created. For SAML you need the IdP entity ID, the sign-on URL and the signing certificate.
The client secret is write-only: once saved, ZenFlip will show you that one is set but never show it back. Leaving the box blank when you save something else keeps the stored secret.
3. List the email domains you own
Only addresses in these domains are let in. Anyone your provider signs in with an address outside them is refused, which matters if your application can be reached by guest or personal accounts.
Leave it blank only if the application you registered serves your organization alone.
4. Decide who sees what
By default everyone who signs in gets your whole library, including anything you publish later. That is usually right for a staff magazine.
If different groups should see different things, add group rules under Who sees what. Each rule names a group from your identity provider and the collections its members may read. Someone in two groups gets both. Someone in none gets an empty library.
Group rules follow the collection, not the publication, so anything you add to a mapped collection later reaches the same people automatically with no further admin.
Use the group name your provider actually sends. Microsoft Entra sends group object IDs rather than names unless the enterprise application is configured to send names. If a rule seems to match nobody, that is the first thing to check — paste the object ID in as the group name, or change the application to send names.
Group changes take effect the next time somebody signs in, in both directions: moving department adds the new collections and removes the old ones.
5. Turn it on
Switch Reader SSO on. From that moment, for this library:
Readers sign in through your identity provider
The ZenFlip password form is closed for your readers
Reader self-signup is closed
Your own publishing team is unaffected — they keep signing in the way they do now.
What happens to accounts
A reader account is created the first time somebody signs in, from the email address and name your provider sends. There is nothing to import and no list to keep up to date.
If you also use SCIM provisioning, deactivating somebody there signs them out of their reader account and stops them signing in again. Their library is kept, so if they rejoin, their shelves, bookmarks and notes are still there.
Turning it off
You can switch Reader SSO off at any time, whatever your plan is doing. Your readers go back to the ZenFlip password form, and anyone who only ever signed in through your provider will need to use Forgot password to set one.
When it does not work
"This library uses your organization account" on the password form — that is Reader SSO working as intended. Use the sign-in link instead; it is on Settings → Reader SSO as Employee sign-in link.
Signing in bounces back to the login page — the most common causes are a redirect URI that does not match what ZenFlip published, character for character, and an email domain that is not on your list.
Signed in, but the library is empty — your group rules matched none of this person's groups. Check the group name against what your provider actually sends, per the note above.
Reader SSO is off and you cannot switch it on — if the page says ZenFlip has turned it off for your organization, contact support; that switch is ours, not yours, and we will tell you why it is set.