Enterprise SSO

Digital Business Cards with SAML Single Sign-On

Employees sign in to QRBold with the credentials they already have. SAML 2.0 single sign-on works with Okta and Microsoft Entra ID, so your existing MFA, conditional access, and session policies apply to QRBold without any extra configuration — and there is no separate password for anyone to forget, reuse, or leave behind.

Start Free

Last updated

SAML 2.0

Industry-standard federation

2 IdPs

Okta and Microsoft Entra ID

Inherited

Your MFA and access policies

Tracked

Certificate expiry, warned in advance

Does QRBold support SAML single sign-on?

Yes. QRBold supports SAML 2.0 single sign-on with Okta and Microsoft Entra ID. Employees sign in with existing corporate credentials, so your MFA requirements, conditional access rules, and session policies apply automatically. QRBold marks a connection verified only after a real authentication round-trip succeeds.

Why teams choose QRBold for saml single sign-on

Your security policy, not ours

Federating authentication means QRBold does not get a vote on password strength, MFA, or session length — your identity provider decides, exactly as it does for every other application. Conditional access rules like "corporate device only" or "block sign-in from outside these countries" apply with no QRBold configuration at all.

No password to leave behind

A local password outlives employment unless somebody deletes it. Federated sign-in cannot: revoking access in the identity provider ends access to QRBold in the same action, which is the difference between offboarding being a checklist and offboarding being a control.

Verified means verified

QRBold marks SSO verified only after an authentication round-trip actually completes. Saving configuration does not set the flag. A dashboard that showed a green tick over a connection that has never authenticated anybody would be worse than showing nothing.

Certificate expiry, before it bites

IdP signing certificates expire, usually on a two or three year cycle, and the failure mode is an entire company locked out on a Monday morning. QRBold tracks the expiry date and raises an expiring-soon flag well ahead of it.

Configure SAML SSO in four steps

1

Copy the service provider values

QRBold shows the ACS URL, the SP Entity ID, the metadata URL, and the NameID format. The labels match the vocabulary of whichever identity provider you selected — Okta and the Entra admin centre use different names for the same SAML fields, and echoing the wrong one at an admin is how a setup wizard stops being usable.

2

Create the application in your IdP

Paste those values into the Okta app wizard or register the enterprise application in the Microsoft Entra admin centre. Assign the users or groups who should be able to sign in.

3

Return the IdP details to QRBold

Provide the IdP sign-in URL, the IdP entity ID, and the signing certificate — or supply the metadata URL and let QRBold read them. The certificate is validated on entry rather than at first sign-in, so a malformed paste is caught immediately.

4

Test, then enforce

Run the connection test and confirm the round-trip succeeds. The result, including the failure reason if it did not, is recorded with a timestamp. Once verified, roll SSO out to your users — and keep an eye on the certificate expiry date QRBold now tracks for you.

SSO specification

The technical detail an evaluation actually turns on, in one place.

ProtocolSAML 2.0
FlowsSP-initiated and IdP-initiated sign-in
Identity providersOkta · Microsoft Entra ID
Service provider valuesACS URL · SP Entity ID · Metadata URL · NameID format
IdP configuration inputSign-in URL, entity ID, and X.509 signing certificate — or a metadata URL
Certificate validationChecked on entry; expiry date stored and an expiring-soon flag raised in advance
Connection testingOn-demand test with last result, timestamp, and error message retained
Verification semanticsVerified set only after a successful authentication round-trip
Connection statesPending · Connected · Active · Paused · Error · Disconnected
Relationship to provisioningIndependent switch — SSO governs sign-in, SCIM governs card issuance

Why a business card tool needs enterprise SSO

It is a fair question. A digital business card is not a finance system, and the instinct that SSO is overkill for it is understandable.

The answer is that a card platform holds two things worth protecting. The first is the employee directory subset it has been given — names, titles, departments, direct phone numbers, and email addresses for the whole customer-facing organisation, which is precisely the dataset a targeted phishing campaign wants. The second is publishing rights: whoever controls the platform controls what appears on pages that carry your brand and that customers scan from printed material.

Neither is catastrophic on its own. Both are meaningfully worse when protected by a password an employee chose, reused elsewhere, and still knows after they leave. SSO is not overkill; it is the cheapest way to bring a public-facing tool under controls you have already built and already pay for.

What you inherit automatically

Federating to Okta or Entra ID means QRBold stops making security decisions that your identity team has already made better.

  • Multi-factor authentication. Whatever factors your policy requires apply to QRBold, including hardware keys and phishing-resistant methods.
  • Conditional access. Device compliance, network location, risk-based rules — all evaluated by the IdP before QRBold is ever reached.
  • Session lifetime. Your idle and absolute session timeouts govern, so QRBold does not become the tab that stays authenticated for a month.
  • Instant revocation. Disabling the account ends QRBold access in the same action, with no second system to remember.
  • Audit centralisation. Sign-in events land in the same IdP logs your security team already monitors, rather than in a separate tool nobody has alerting on.

The certificate that ends the quarter badly

The most common SAML outage has nothing to do with the initial setup. It is a signing certificate reaching its expiry date two or three years after a successful rollout, at which point every sign-in fails at once and the people who configured it have often changed roles.

QRBold stores the certificate expiry date at configuration time and raises an expiring-soon flag ahead of it, so the renewal appears as a warning in the dashboard rather than as a Monday morning incident. It is a small feature that exists because the failure it prevents is entirely predictable and still catches people out constantly.

SAML Single Sign-On questions, answered

The questions that come up in real evaluations, answered directly.

Bring cards under the controls you already run

Enable SAML 2.0 single sign-on with Okta or Microsoft Entra ID and inherit your MFA, conditional access, and revocation policies on day one.

Start Free

No credit card required