Signater now supports Single Sign-On. Your team signs in to the platform through the identity provider your company already runs, with no Signater password, and the account administrator controls which domains take that route.
The feature is live, runs on the OpenID Connect (OIDC) protocol and has been validated against Microsoft Entra ID, Okta, Google Workspace, Auth0 and Keycloak. It ships with the Enterprise plan, with no separate module to buy and no charge per authenticated user.
What Single Sign-On is
Single Sign-On means reaching several systems with one credential, the same one your company already issues to an employee. A building badge works that way, opening the doors on a floor without every room asking for its own key.
The identity provider is the system where a company keeps that credential and the access rules around it: who exists, who was offboarded, who needs a second factor. Microsoft Entra ID, Okta and Google Workspace are the common ones in that seat. With SSO on, Signater asks that provider who the person is, instead of keeping a password of its own.
The link between the two runs on OpenID Connect, the protocol corporate providers publish for this kind of integration (OpenID Foundation). Whoever administers the account never has to learn the protocol, only copy three fields the provider hands over ready to paste.
The sign-in flow
On the Signater sign-in screen, next to Google sign-in, there is now an SSO button. The path takes four steps:
- The person clicks SSO and types their work email.
- Signater reads the email domain and finds the company's connection.
- The identity provider takes over, asking for the corporate password and whatever second factor your policy requires.
- The person lands back in Signater already authenticated, with no Signater password anywhere in the trip.
If the domain they typed has no SSO enabled, the screen says so and offers the other sign-in methods.
The three switches
Configuration turns on three independent switches, and each one answers a different question.
Enable SSO
Turns the connection on and makes the button appear. On its own it forces nothing, and anyone who prefers a password keeps using one.
Require SSO
Takes passwords out of circulation. With this switch on, Signater refuses passwords and Google sign-in for anyone on your verified domains.
The account owner and administrators keep signing in with a password, and that exception is deliberate. It is the emergency valve for the day your identity provider goes down or someone misconfigures the app registration: without that way in, a single typo would lock the whole company out of its own account.
The rule also reaches people who were already inside. A session opened with a password before you required SSO does not renew itself forever: when the credentials come up for renewal, Signater applies the same rule and sends that person back to the sign-in screen, through SSO this time. If the account stops including the feature, the rule steps aside on its own and nobody ends up locked out.
Rollout uses these two switches at different moments: enable the connection without requiring SSO, have a few people sign in through the button and confirm they land in the right place, and only then require it for the rest of the company.
Create users automatically
Decides what happens on the first sign-in of someone who is not in the account yet.
On, the person is created and linked to the account the first time they arrive through SSO. A twenty-person team skips twenty invitations: the administrator publishes the app in the company portal and each person walks in on the day they need it. Off, SSO still authenticates, but only people who are already active members get through, with a named invitation before the first sign-in.
Per-person cost stays out of that decision. Every paid Signater plan includes unlimited users, so opening the platform to a whole department leaves the invoice alone.
Domain verification over DNS
Signater accepts an email through SSO once its domain is verified for that connection. The proof is a DNS record.
You add acme.com under Allowed sign-in domains, Signater hands back a TXT record shaped as signater-sso-verification= followed by a token, and you publish that record in your domain's zone. Until the record answers the lookup, the domain stays pending and nobody signs in through it.
Without that requirement, any account could claim gmail.com and start intercepting the sign-in of everyone on that domain. A verified domain is also locked: while one connection holds it, no other account can verify the same domain. The feature is listed with the rest of the account protections on the security page.
How to configure it
The screen lives at Settings → Account → Single Sign-On, visible to administrators.
The first step happens on the other side, at the provider, where the administrator registers a new application. The Redirect URI the provider asks for is already on the Signater screen before any connection has been saved, and it reads the same for every provider and every domain.
Back in Signater, three fields come from the provider:
- Authority URL: the address of your environment at the provider, the part that identifies your company inside it. In Entra ID, that address carries your tenant identifier.
- Client ID: the registration name of the application you just created. It is public, and it tells the provider who is asking for the authentication.
- Client Secret: the password of that application. Signater stores it encrypted and never returns the value to the screen, not even to you; to rotate it, type the new one over the old.
The default role completes the setup. It sets the permission a person is created with on first sign-in, either administrator or regular user, and anyone who needs more access is promoted later on the users screen. After that, add your domains, verify the TXT record and enable the connection. Every change on this screen lands in the account's audit trail with an author and a timestamp.
To put Signater in the company portal next to your other applications, the screen hands you a sign-in start URL. Pasted into the tile in Microsoft My Apps or the Okta dashboard, it takes the person straight into the platform, authenticated on the first click.
What stays the same
Single Sign-On governs your team's access to the platform: whoever builds an envelope, follows its progress or administers the account.
Anyone receiving an envelope to sign carries on as before. The client opens the link that arrived in their own inbox, with no application to install, no Signater account to create and no trip through your company's identity provider, which is not their employer. Proof of who they are keeps coming from the factors you pick on the envelope, such as the code sent to their email or the selfie taken at the moment of signing.
Availability
Single Sign-On travels with the Enterprise plan, the same way White Label and managed accounts do. Signater sells no separate SSO module, charges nothing per authenticated seat and sets no user minimum. The account is on Enterprise, the SSO screen appears for administrators.
To see the platform before talking about plans, Free is enough: create an account and send three envelopes a month, no credit card.
