What single sign-on gives you

• One login for your team. People sign in to Wrenbase through your identity provider instead of a separate Wrenbase login, so there’s one less password to manage.
• Central control. Your IT team decides who has access. When someone joins or leaves, you handle it where you already handle everything else, and Wrenbase follows.
• Your security policy, applied. Whatever rules you enforce at sign-in, like multi-factor, carry through to Wrenbase.

Protocols and providers

Wrenbase supports the standard single sign-on protocols, so it works with the identity provider you already run:

• SAML 2.0
• OpenID Connect (OIDC)

These are the common standards behind the major providers, including Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, OneLogin, JumpCloud, and Ping Identity. If your provider speaks SAML or OIDC, which nearly all of them do, we can connect it. If you’re not sure what yours uses, tell us who it is and we’ll sort it out with you.

Automatic provisioning with SCIM

Single sign-on decides who can get in; SCIM keeps your team roster in sync. With SCIM connected, the accounts in Wrenbase follow your directory automatically: when someone joins, their account is created; when their role changes, it updates; and when they leave, their access is removed without anyone doing it by hand.

That keeps access accurate as your team changes and means one less place for IT to remember to update. SCIM works alongside single sign-on with the same identity providers.

Getting set up

Single sign-on and SCIM are configured with our team rather than switched on from a settings page, so we can match them to how your identity provider is set up and test everything before your team relies on it.

Related

• Members and roles: how access works day to day
• Getting started: accounts, businesses, and who owns what