Skip to main content
Single sign-on lets the people of your organisation sign in to the wede dashboard with the work account they already have, through your own identity provider. Passwords, multi-factor authentication and account policies stay where you already manage them. wede supports OpenID Connect and SAML 2.0. Any provider that speaks one of them can be used, for example Microsoft Entra ID, Okta, Google Workspace, ADFS or PingFederate. Your organisation uses one protocol at a time and can switch at any moment: each person is linked again at their next sign-in, so nobody is locked out. Only a company_admin of your organisation can configure single sign-on, in Settings > Single sign-on of the dashboard.

​
How a sign-in works

  1. The person types their email on the wede sign-in page. If the email domain is verified for your organisation, wede offers single sign-on.
  2. The browser goes to your identity provider, which authenticates the person with the rules you set there, including multi-factor authentication.
  3. Your provider sends the browser back to wede with a signed answer. wede checks it and decides the role.
  4. wede hands the dashboard a one-time code, valid for 60 seconds, that the dashboard exchanges for a session. The session token never travels in a URL.
The session is the same as with a password: it expires after 8 hours and ends at once when the account is suspended.

​
Tied to the browser that started it

Every sign-in only completes in the browser tab where it started. Before going to your provider, the dashboard creates a random secret in that tab and sends wede only its SHA-256 hash. The one-time code is exchanged for a session only together with that secret. A sign-in link copied from one browser and opened in another is refused, the code is spent and the attempt is recorded in the audit log as browser_mismatch. This closes login cross-site request forgery, where someone tricks a person into working inside the wrong account. A sign-in attempt expires after 10 minutes and can be used once.

​
OpenID Connect

In your identity provider, create a web application (OpenID Connect, confidential client):
  • Redirect URI: the address shown in the dashboard, https://api.wede.pt/v1/auth/sso/callback.
  • Scopes: openid, email and profile.
  • Groups (optional): to give roles by group, add a groups claim to the ID token.
Then enter in the dashboard the Issuer of your provider, the Client ID and the Client secret. wede uses the authorization code flow with PKCE (S256), checks the signature of the ID token against the keys published by your provider, its issuer, audience, expiry and nonce, and accepts only a verified email. The client secret is encrypted with your organisation key and is never shown again.

​
SAML 2.0

wede gives each organisation its own SAML service provider, shown in the dashboard with Copy buttons: Create a SAML application in your provider by importing the metadata address, or by copying the Entity ID and the reply address. Then, in the dashboard, paste the metadata of your provider (XML or an https address) and press Read metadata, which fills the provider Entity ID, the sign-in URL and the signing certificates. wede accepts a SAML answer only when all of these hold:
  • The assertion is signed with one of the certificates you saved. Unsigned answers are refused.
  • It answers a request that wede itself sent, for this organisation, in the last 10 minutes, and it has not been used before.
  • The issuer is your provider’s Entity ID and the audience is your organisation’s Entity ID.
  • It is within its validity window, with 2 minutes of tolerance for clock differences.
Send the email as the NameID or as an email attribute, and, for roles by group, a groups attribute. The NameID is linked to the account at the first sign-in, and later sign-ins must carry the same one. Changing the provider Entity ID clears those links so the new provider can link again. Certificates. You can save up to 3 signing certificates, so you can add the next one before the current one ends. The dashboard warns 30 days before the last valid certificate ends. Sign-ins that start at your provider. wede accepts only sign-ins it asked for (service provider initiated). A SAML answer that wede did not request, for example from a tile in your provider portal, is refused and recorded as unsolicited_response. For a wede tile in your portal, use the Sign-on address: it passes for a moment through the wede sign-in page and starts a normal sign-in. Encrypted assertions and single logout are not supported yet.

​
Email domains

Single sign-on applies to emails in the domains your organisation has verified. To verify a domain, add it in the dashboard and publish the TXT record shown in that domain’s DNS. wede asks the domain’s own name servers for the record. A domain can be verified by one organisation only. A new account is created at the first sign-in only for an email in a verified domain, and only when Create the account at the first sign-in is on. Otherwise the account must already exist.

​
Roles from your groups

You map groups of your provider to wede roles. At every sign-in the first matching line decides the role, so a change of group in your provider changes the role in wede at the next sign-in. When no line matches, the Default role is used; with no default, the sign-in is refused. The roles your provider can give are company_admin, company_tech, operational_supervisor, field_operator and corporate_client. wede roles and country roles never sign in through a customer’s single sign-on.

​
Require single sign-on

Require single sign-on turns off passwords for everyone in your organisation except the emergency account: one company_admin account of your organisation that keeps its password, so you can still get in if your identity provider is down. Requiring single sign-on needs a verified domain and an emergency account. While it is on, password reset does not send links to the other accounts.

​
Audit

Every sign-in and every refusal is recorded in the immutable audit log, and can be sent to your SIEM with the security export. Common reasons for a refusal: To create and update accounts from your directory before people sign in, see Provisioning (SCIM).