Authentication providers#

Reportworq authenticates every user before any shell mounts. Exactly one authentication provider is active at a time, chosen in Settings, Integrations, in the Authentication family.

This page is the decision: which provider, and what it costs to change your mind. The step-by-step activation procedure, the self-service password flows and the lockout recovery path are in Sign-in and SSO.

The providers#

Every OIDC client secret is stored encrypted at rest.

Why this is an early decision#

Three facts make the choice hard to reverse, and all three are worth knowing before you onboard a single user.

Switching strands the accounts on the previous provider. Changing the active provider does not merely drop permissions. Existing accounts stay bound to the provider they were created under and become reachable again only if you switch back. Under the new provider, their entitlement and group grants have to be re-established.

A service restart is required. Changing the active provider takes effect only after the Reportworq service restarts. Until then the previous provider stays active, which means the change is not something you can validate instantly.

There is no Test action. Authentication providers are excluded from the integrations hub's connection tests, including Test all connections, because there is no test path for them. You find out whether the configuration is right by restarting and trying to sign in.

Plan the cutover before you make it#

If you are moving from Native to an OIDC provider, particularly Entra:

1. Provision your way back in first. Supply an initial administrator email that already exists in the identity provider, and confirm it resolves there before you cut over. Because the switch strands the old accounts, that pre-provisioned administrator is how you get back in if the cutover goes wrong.
2. Enter the provider's fields and save.
3. Mark the provider Active.
4. Restart the service.
5. Sign in as the pre-provisioned administrator and re-establish entitlements and group grants.

If even the pre-provisioned account fails, there is an operator-driven recovery path that requires restarting the process with an environment variable set. That deliberate friction is the proof you control the server. It is documented in Sign-in and SSO.

Roles can come from the identity provider#

Once an OIDC provider is active, group or role claims from the identity provider resolve to Reportworq entitlements. That means you can assign a user's role through identity-provider group membership rather than granting it locally in Reportworq.

This is usually the reason to move to SSO in the first place: joiners and leavers are handled where they are already handled. Decide the claim-to-entitlement mapping with whoever owns your identity groups, not afterwards.

For what those entitlements actually permit, see Accounts, groups and entitlements.

One account per person#

Licenses are sold as named users, and each account is one person. Sharing a login between several people breaches the terms of service, and it also destroys the audit trail, because every action is recorded against the account that performed it. If several people need access, give each of them an account.

This matters more, not less, under SSO, where it can be tempting to create a shared service identity for a team.

The Office add-in#

The same sign-in surface handles the Excel and Office add-in login. When the login carries an Office cloud host, a successful sign-in posts the token back to the add-in's dialog host rather than navigating the shell, so the task pane connects without a separate browser session. HTTPS is required for the add-in.

Related pages#

• Sign-in and SSO for the activation procedure, the native self-service flows, and lockout recovery.
• Microsoft 365 OAuth setup for the Azure app registration.
• The integrations hub for where the Authentication family lives.
• Plan your integrations.