Single Sign-On (SSO) Integration

Tickaroo supports Single Sign-On for your editorial team, so your colleagues log in to Tickaroo Pro and the Liveblog Editor with the credentials they already use everywhere else. Accounts are created, updated, and deactivated from your identity provider (IdP) — no separate Tickaroo user administration.

Not what you are looking for? This page is about your newsroom staff logging in to Tickaroo. If you want the readers of your website to be recognised by interactive liveblog features such as comments, see Enduser SSO.

What we support

Connection types

Type	Notes
SAML 2.0	The most common choice. Works with Entra ID (Azure AD), Okta, Google Workspace, Keycloak, ADFS and any other SAML 2.0 provider.
OIDC	OpenID Connect, for providers you prefer to connect that way.

Both support mapping your groups to Tickaroo roles.

User provisioning

Method	How it works	When to choose it
JIT (Just-in-Time)	The account is created on the user’s first successful login, from the attributes your IdP sends. Nothing has to be prepared per user.	The default. Works with every IdP, no extra configuration on your side.
SCIM	Your IdP pushes users and group memberships to Tickaroo as they change, without waiting for a login.	Larger teams, or when you want joiners, movers and leavers to be applied without waiting for the person to log in. Requires SCIM support in your IdP.

Choose one or the other — your setup runs on JIT or on SCIM, not both.

How a setup runs

We prepare everything on our side first and then hand you a configuration link, where you connect your identity provider yourself — no metadata exchanged by email, no waiting on us between attempts.

Step	Who	What happens
1. Preparation	Tickaroo	We prepare your configuration, your organization(s), and the roles your groups will be mapped to.
2. Configuration link	Tickaroo → you	We send you a personal link to your SSO configuration page.
3. IdP connection	You	You connect your identity provider on that page: SAML or OIDC, attribute mapping, group mapping — and test the connection there.
4. Mapping check	Tickaroo	We verify the group-to-role mapping, especially with more than one organization, and send you your SSO login link.
5. Test	Both	A colleague without an existing Tickaroo account signs in through that link, end to end.
6. Domains	You → Tickaroo	You send us the email domains that should be routed to your IdP.
7. Go-live	Tickaroo	We route those domains to your identity provider and enforce SSO for them.

Steps 3 and 6 are the only ones that need configuration work on your side. A straightforward single-organization setup is usually done within a day; a multi-organization setup depends mostly on how quickly the group names are agreed.

What we need from you

Have these ready before we start:

Which connection type you want: SAML 2.0 or OIDC.
Which provisioning you want: JIT or SCIM.
Your email domains — every domain your staff use, including subdomains (example.com, contractors.example.com).
Your group names — an admin and a user group per organization (see Mapping groups to roles).
A technical contact who can configure your IdP and receive the configuration link.
A test user who does not yet have a Tickaroo account.

Connecting your identity provider

You receive a link of this form:

https://auth.tickaroo.com/sso/setup/XXXXXXXX?t=XXXXXXXX

Treat this link as a credential. Anyone holding it can change how your organization signs in. Send it only to the colleague who configures your IdP, and not through a public channel. If it no longer works, ask us for a new one.

The page walks you through the connection. Two things are worth knowing before you open it:

The Tickaroo-side values are on the page. Entity ID, ACS (reply) URL and the signing certificate are generated for your account and shown there. Use those values in your IdP — do not reuse values from another Tickaroo customer, from an older integration, or from older Tickaroo documentation.

You can connect by metadata or by hand. For SAML, either provide your IdP metadata URL, or enter the entity ID, the sign-on URL and the certificate directly. For OIDC, you provide the discovery URL, client ID and client secret.

There is a test button. Use it as you go: it runs a sign-in against your identity provider so you can confirm the connection without leaving the page.

Mapping user attributes

Tickaroo needs two attributes from the assertion or token. Map them on the configuration page:

Attribute	Required	Used for
Email	Yes	The user’s identity in Tickaroo. Must be unique and stable — it is how a returning user is recognised.
Name	Yes	The display name shown on posts and in user lists. Either a full display name, or first name plus last name.

Besides these profile fields, Tickaroo stores the organization roles derived from your group mapping and whether the account is active.

Mapping groups to roles

The roles

Role	Permissions
`Owner`	Full administrative access, including user management and billing.
`Admin`	Create and edit liveblogs, full access to all content and options.
`User`	Create and edit liveblogs.

The mapping

Your group names are yours to choose; you map each one to a Tickaroo role on the configuration page. By default the roles are named:

Your group (example)	Tickaroo role name	Role
`tickaroo-owners`	`tenant-admin`	Owner
`tickaroo-admins`	`liveblog-admin`	Admin
`tickaroo-editors`	`liveblog-user`	User

A user whose groups match none of your mappings can authenticate, but arrives without access to any organization. Make sure everyone who needs Tickaroo is in at least one mapped group.

With more than one organization

One SSO connection can serve several Tickaroo organizations — for example one per brand or region, and more can be added later. In that case:

You need one admin group and one user group per organization, so news-admins, news-editors, sports-admins, sports-editors and so on.
Send us those group names before you configure the mapping, so the matching roles are ready on our side.
Owner is not a per-organization role. It comes only from tenant-admin, which grants Owner in every organization — so do not create a per-brand owner group. Map tenant-admin once, for the few people who should administer all organizations.

Logging in

Your colleagues have two ways in, and you can offer either or both:

Your SSO login link — https://pro.tickaroo.com/login/<your-id>, which we send you once your connection is configured. It goes straight to your identity provider with no email prompt, and works before your domains are routed, which is what makes it the link to test with. It is the one to put in your intranet or your IdP’s app portal.

The standard login — https://pro.tickaroo.com. A user enters their email address and, if the domain is one of yours, is forwarded to your identity provider.

If you want your users to start from your IdP’s application portal (IdP-initiated login), tell us which provider you use — the exact configuration differs between providers and we will confirm it with you.

Email domains and enforcing SSO

Send us every email domain your staff use. Users with an address on those domains are routed to your identity provider from the standard login.

By default we enforce SSO for those domains: nobody with an address on one of them can sign in with a Tickaroo password, so your identity provider stays the only way in. Individual accounts can be excluded — worth keeping for a break-glass administrator who must still get in if your identity provider is unreachable. If enforcement does not suit your setup, tell us before go-live.

Offboarding

What you do in your IdP	What happens in Tickaroo
Remove a user from a mapped group	With SCIM the change reaches us as your directory pushes it, and an open session picks it up at its next token refresh. With JIT we learn of it only when they next sign in, so an open session keeps the old role until then, or until it expires.
Disable or delete the user	They can no longer start a new session. An open session keeps working until its token is next refreshed: with SCIM that refresh then fails and access ends, with JIT we never learn of the change at all, so the session runs until it expires.

Because access is tied to your directory, an employee who leaves loses the ability to sign in as part of your normal offboarding — there is no separate Tickaroo account to close. If someone must lose access immediately rather than at their next token refresh, tell us and we will end their active sessions.

Testing the integration

The test button on the configuration page confirms the connection to your identity provider. This second test goes further: it also exercises provisioning and role mapping in Tickaroo, so it is worth doing even when the button is green.

Test with a colleague who has not used Tickaroo before:

With JIT, they should be created the first time they sign in.
With SCIM, check they have arrived in Tickaroo after your directory pushes them, and then have them sign in.

Then check that:

The login completes and lands in Tickaroo.
Name and email are correct on the user’s profile.
The role matches the group they are in — someone in an admin group should see the organization settings, someone in a user group should not.
With more than one organization: they see exactly the organizations they should, and no others.

Good to know

Number of organizations. We comfortably support up to 50 organizations under one SSO connection. Beyond that, talk to us first — we will look at your setup before committing to it.
Role changes are not instant. A role changed in your IdP applies once the user’s session token refreshes, or at their next login.

Troubleshooting

Symptom	Where to look
Login fails at your IdP	The user is not assigned to the Tickaroo application in your IdP.
Login succeeds but Tickaroo is empty	The user’s groups match no mapping, so they have no organization role. Check the group mapping.
The user is asked for a Tickaroo password	Their email domain is not on the list you sent us, or they are using the standard login with an unlisted domain.
Wrong role	The group-to-role mapping, and whether the user is in more than one group. Remember a role change needs a token refresh.
Configuration link does not open	The link has expired or was already replaced. Ask us for a new one.

When you contact us, the user’s email address, the time of the attempt and any error message shown are enough for us to find the corresponding entry in the authentication log.

Support

Reach out to support@tickaroo.com, or to your Tickaroo contact directly if you are in an ongoing setup.