Quote from Matt Hopkins on May 27, 2026, 1:07 pm

So, you’ve configured SSL and now you’re ready to configure SSO.

Those two steps really go hand in hand: if you're moving Reportworq to an external identity provider, SSL should be in place first. In practice, SSL is part of the foundation for a proper SSO rollout, so it makes sense to treat SSO as the next stage once secure HTTPS access is already configured.

If you've been running Reportworq with native authentication (the default username/password setup) and your organization is ready to consolidate authentication with a corporate identity provider (IDP), this post covers the key things to know before and after making the switch.

Why configure SSO?

Configuring SSO really benefits accessibility to Reportworq for Administrators and End Users.  If you have multiple workspaces/administrators, Contribution End Users, or Reporting/PowerPoint End Users then configuring SSO will make accessing the application a more seamless process.  

Enabling SSO means establishing consolidated access management at the IDP layer. If a user leaves or a new employee is going through onboarding, the access admins have one place to change permissions instead of "yet another app" to maintain access to. SSO also enables role based access where an admin can maintain access at a group level instead of individually. 

What SSO options are available?

Reportworq supports four authentication providers:

• Native authentication
• Microsoft Entra ID (Azure Active Directory)
• Google-based authentication
• Custom OpenID Connect (OIDC) for other OIDC-compliant identity providers

You configure this under Administration -> Authentication by selecting the Authentication Provider.

Before you switch — the most important thing to know:

If you switch authentication providers, existing Reportworq accounts remain but exist for the previously used IDP and are only available if you switch back.  For the new IDP you’ll only have 1 administrative account configured which is set when switching so that you can still login. 

You should expect to rebuild or remap access through your new identity-provider-based role/group model before users can work normally again. Because of that, it’s a good idea to plan your groups, roles, and claims mapping before you switch providers.

If you get locked out don’t forget there is still a way into Reportworq on the landing page.  See authentication documentation for more details.

Setting up Microsoft Entra ID (the most common path)

First, create your app registration in Microsoft Entra / Azure as described in the Microsoft 365 documentation. Make sure you capture:

• Application (Client) ID
• Directory (Tenant) ID
• Client secret value
  (important: the secret value, not the secret ID)

Then in Reportworq:

1. Go to Administration - > Authentication
2. Select Microsoft Entra ID as the authentication provider
3. Enter the Client Id, Client Secret, and Tenant Id
4. Provide the email address for the initial system administrator account when prompted
   • That email address must exist in Microsoft Entra ID
5. Restart Reportworq when prompted

Managing group memberships and licenses via SSO roles

Once you're using a non-native authentication provider, Reportworq can manage group membership using roles or claims from your identity provider.

When accounts are created in Reportworq, they are automatically mapped to users from the authentication provider by matching email address, and each user’s security claims are propagated to their Reportworq account.

One especially helpful detail: when access is managed this way, assigned entitlements do not consume licenses until the user logs in for the first time.

When using SSO with providers like Microsoft Entra ID, Reportworq can automatically place users into the correct groups based on security roles defined in your company's identity system.  Instread of manually managing users and permissions inside Reportworq, administrators create roles in Entra ID, assign users to those roles, and Reportworq automatically applies the matching access and licenses when users sign in.  This keeps user management centralized, makes onboarding and offboarding much easier, reduces administrative effort, and helps ensure employees always have the right level of access based on their job role.  For step-by-step setup instructions see Using-security-claims-to-manage-group-membership

FAQ

Q: A user left the company. I removed them from our identity provider, but their Reportworq license hasn’t been freed up. Why?

Changes made in the authentication provider are not automatically relayed to Reportworq.

If a role is removed from a user in the IDP, any associated licenses are not released for reassignment until that user logs in again. If you need to release the license immediately, select the account in the Reportworq authentication interface and clear the Last Claims box.

Q: I switched providers and now no one can log in. What happened?

When you switch providers, existing accounts remain but permissions are removed.

During the switch, Reportworq prompts you to define the initial system administrator account for the new provider. That email address must exist in the identity provider you’re switching to. Log in with that account first, then rebuild or remap access from there.

Q: Do report recipients need SSO accounts?

No. Users who only receive distributed or bursted reports by email and do not log in to the Reportworq interface do not require licenses or authentication credentials. SSO only applies to users who actually sign in to Reportworq.

Q: Is there a way to recover access if the admin account gets locked out?

Yes. If the administrator account is locked out or the password is forgotten, access can be recovered using local administrative control. See the authentication documentation for the recovery steps.

Documentation

• Authentication: https://docs.reportworq.com/docs/authentication/
• Microsoft 365 / Entra app registration: https://docs.reportworq.com/docs/office-365-oauth2/

Questions? Drop them below or reach out to support@reportworq.com.