Single sign-on (SSO)

Single sign-on (SSO) lets the people in your organisation sign in to Urlicer through your own identity provider, such as Okta, Microsoft Entra ID or Google Workspace. Urlicer supports OpenID Connect and SAML 2.0. SSO is part of the Enterprise plan, and only the workspace owner can set it up.

How it works

• You connect your provider once. The connection belongs to your account and works for every workspace you own.
• You verify the email domains it covers with a DNS record. Only addresses on a verified domain can sign in through it.
• Someone signing in through it for the first time gets an account, and can join one of your workspaces with the role you choose.
• You can require SSO for a workspace. Members then open it only after signing in through your provider.

Open the workspace, go to Settings and choose the SSO tab. The page has four steps.

1. Your provider

Create an app for Urlicer at your provider first, then choose your provider on our page, enter what it gives you, and click Save. After the first save, the page shows our values to enter at your provider.

Okta (OpenID Connect)

1. In Okta, create an app integration: OIDC, web application. Assign the people or groups who may sign in.
2. On our page, choose Okta and enter the Issuer URL (your Okta address, for example https://acme.okta.com), the Client ID and the Client secret. Click Save.
3. Copy the Callback URL our page now shows into Okta as the sign-in redirect URI.

To keep people signed in without a new sign-in every 12 hours, turn on the Refresh Token grant type for the app in Okta.

Microsoft Entra ID (OpenID Connect)

1. In Entra ID, create an app registration and a client secret for it.
2. On our page, choose Microsoft Entra ID. The Issuer URL is https://login.microsoftonline.com/<your tenant ID>/v2.0. Use your own tenant ID: we refuse "common" and "organizations", because they would let any Microsoft tenant in.
3. Enter the Application (client) ID and the secret, and click Save.
4. In the app registration, add the Callback URL our page now shows as a Web redirect URI.

Google Workspace (OpenID Connect)

1. In Google Cloud, create an OAuth client ID of the web application type.
2. On our page, choose Google Workspace and enter the Client ID and the Client secret. The issuer is filled in for you. Click Save.
3. Add the Callback URL our page now shows to the OAuth client as an authorised redirect URI.

Only accounts of your Google Workspace domain can sign in. A personal Google account that uses a work address is refused.

Any SAML 2.0 provider (including Entra ID and Okta)

1. Choose SAML 2.0 (any provider), give your provider's metadata URL or paste its metadata XML, and save.
2. Enter our values at your provider: the Entity ID / metadata URL and the Reply URL (ACS). Many providers can read them from the metadata URL.
3. Send the email address as an attribute named email. First and last name are optional.

Use a NameID that never changes, such as the persistent format. If your NameID is the email address, enter an attribute with a permanent user ID in Attribute with a permanent user ID. For Entra ID that is http://schemas.microsoft.com/identity/claims/objectidentifier. Otherwise, someone who later gets a reused address would get the previous person's account.

Allow sign-in from your provider's app dashboard is off at first. When you turn it on, a click on the Urlicer tile in your provider starts a normal sign-in from our side.

Session length and roles

Maximum session length (8 hours, 24 hours, 7 days or 30 days) is how long someone stays signed in before they sign in again. Where your provider allows it, we check with it every hour that the person's account is still active, and the page shows "Silent renewal: on". Without that, a session ends after 12 hours at most. SAML always works this way.

Role for people who arrive through SSO is the role they get when they join this workspace on their first sign-in.

2. Your email domains

Add each domain your people's addresses use, for example acme.com. For each one, add the TXT record the page shows at your DNS provider, then click Verify. DNS changes can take a while to show.

Keep the record in place: we check it every day. If it is missing for 7 days, the domain stops working for SSO and we email you.

Shared mailbox domains such as gmail.com can't be added, and a domain can belong to only one organisation.

3. Test sign-in

Click Test sign-in and sign in at your provider with an address on a verified domain. The test signs nobody in to Urlicer. When it works, SSO sign-in is switched on and the page shows Working. If you change the provider, client or certificates later, run the test again.

4. Require SSO for this workspace

Click Require SSO. Members can then open the workspace only after signing in through your provider; with a password session they see a page that asks them to sign in with SSO. Their other workspaces are not affected.

• You, as the owner, can always sign in with your password, so a problem at your provider never locks you out.
• While a workspace requires SSO, addresses on your verified domains can't sign in to Urlicer with a password, a password reset or Google sign-in at all.
• API keys and connected apps keep working. When you turn on Require SSO, the page lists the ones other people made and offers to revoke them. While SSO is required, a member you remove from the workspace also loses the keys and app connections they made in it.

Guests, such as a contractor on another domain, keep signing in to the workspace with a password. Click Make guest next to their name.

When someone leaves

Remove them at your provider. Where silent renewal is on, their Urlicer session ends within about an hour; otherwise when it ends, after 12 hours at most. They can't sign in again through your provider, and while a workspace requires SSO they can't use a password either. To take their seat back, also remove them from the workspace's members.

Changes on the SSO tab, such as domains, Require SSO and guests, are recorded in the workspace's audit log.