eBrigade Single sign-on (SSO) module
Sign in with your existing company account
Managing a separate eBrigade password for each staff member means more forgotten passwords and reset requests. The SSO module delegates authentication to your identity provider via OIDC / OAuth2: your staff sign in with the Azure AD (Entra ID), Keycloak or Okta account they already use, and disabling an account in your directory cuts off their access to eBrigade.
These buttons are about this optional module: add-on pricing and a 1-month trial of the module.
OIDC / OAuth2 authentication: your staff sign in to eBrigade with their existing company account.
What is eBrigade’s Single sign-on (SSO) module?
OIDC / OAuth2 authentication: your staff sign in to eBrigade with their existing company account. It is available as an option so that each organisation can switch it on as needed.
Why use SSO?
In a large organisation, a fire and rescue service (SDIS) or a local authority, your staff already have a company account. Making them use an extra eBrigade username and password means more forgotten passwords, more resets and more work for your IT team — not to mention access that stays open after someone leaves until the eBrigade account is disabled by hand.
What SSO changes in eBrigade
SSO delegates authentication to your identity provider via the OIDC / OAuth2 protocol. A dedicated sign-in button, which you customise (label, image, colour), redirects the staff member to your directory; when they return, eBrigade matches them to their existing account via their email or their UPN (Azure AD). No eBrigade password to remember, and clear visibility over which sign-in methods are allowed.
What you can do with Single sign-on (SSO)
The SSO connector is based on the OpenID Connect / OAuth2 flow (authorization code), compatible with Azure AD (Entra ID), Keycloak, Okta and most enterprise identity providers that comply with this standard.
The SSO button shown on the sign-in page is fully configurable: label, image and colour, to match your organisation’s visual identity.
At sign-in, eBrigade matches the user to their existing account via their email address or their Azure AD User Principal Name (UPN). An existing eBrigade account is required: no access is granted to an unknown user.
For each member status, you allow or forbid native eBrigade sign-in and/or SSO sign-in. This lets you require SSO for permanent staff while leaving local access for profiles that have no account in the directory.
For members who sign in only through SSO, a customisable message replaces the “forgotten password” link and points them to the right contact (for example their organisation’s administrator).
SSO is controlled by a global on/off switch, and its configuration is protected by a dedicated “Edit SSO” clearance reserved for authorised profiles.
Step by step
In the module settings, enter your directory’s OIDC / OAuth2 parameters: client ID, client secret, authorisation URL, token URL, user info URL and logout URL (Azure AD, Keycloak, Okta or any compatible provider).
Set the label, image and colour of the SSO button shown on the sign-in page, as well as the message shown to SSO-only users in place of “forgotten password”. Also choose, status by status, whether native eBrigade sign-in and/or SSO is allowed.
The staff member clicks the SSO button, authenticates with your directory, and eBrigade matches them to their existing account via their UPN or email. For SSO-only statuses, an account disabled in the directory can no longer sign in to eBrigade.
Where this module really pays off
Fire and rescue services (SDIS) & local authorities: staff authenticate via Microsoft Entra ID (Azure AD) or Keycloak, with no extra eBrigade username to manage.
Multi-site organisations: sign-in delegated to the existing identity provider; with SSO enforced, an account disabled in the directory can no longer sign in.
Mixed organisations of permanent staff and volunteers: SSO sign-in or native eBrigade sign-in allowed status by status.
Establishments connected to a central IT system: unified sign-in with the existing company account via OIDC / OAuth2.
Frequently asked questions
Which protocol and which identity providers are compatible?
The module works with OIDC / OAuth2 (authorization code flow). It covers the main providers that comply with this standard: Microsoft Entra ID (Azure AD), Keycloak, Okta and most enterprise solutions. The SAML protocol is not supported.
Does SSO automatically create accounts for new staff?
Yes, if you enable it. By default, SSO matches the staff member to their existing record, by their UPN or email. The “Create account on first sign-in” option creates the record in the organisation and status you choose, with the User profile, from the first name and surname sent by your provider. Departures and group changes are not synchronised: this is not SCIM.
Can SSO sign-in and native eBrigade sign-in coexist?
Yes, and in a fine-grained way: for each member status, you allow or forbid native eBrigade sign-in and/or SSO sign-in. For example, you can require SSO for permanent staff while leaving local access for volunteers.
Can the sign-in page be customised?
Yes. The SSO button is configurable (label, image, colour), and SSO-only users see your custom message when they click “Forgotten password”.
Is SSO compatible with LDAP and MFA?
Yes. They are complementary layers: LDAP synchronisation or account creation on first SSO sign-in populate the accounts, SSO delegates authentication and MFA adds an extra verification step.