Juro counterparty can't access the contract - "SSO login loop" on the invite link

TL;DR: The counterparty's email domain does not match what your SSO setup expects, so Juro bounces them to the identity provider and back forever. Confirm the invite went to their corporate address (not a personal one), have them try a private browsing window to clear the stale session, and check in Juro that external counterparties are allowed past SSO or exempted.

SSO login loop

1. Check which email address the invite was sent to. Expected: it is their corporate address - personal addresses do not match SSO domain rules.

2. Have the counterparty open the invite link in a private or incognito window and log in fresh. Expected: a clean login with no loop - stale cookies cause most loops.

3. In your identity provider, confirm the counterparty's account is assigned to the Juro app. Expected: assigned - an unassigned user gets bounced back to login repeatedly.

4. In Juro's admin settings, check how external or counterparty access handles SSO: allow the invite link to bypass SSO or add a domain exception. Expected: the counterparty reaches the contract without an SSO round-trip.

5. Re-send the invite after the fix and have them accept within the link's validity window. Expected: one login, straight to the document.

Use this when

• a counterparty reports looping between Juro and their login screen on an invite link
• your team logs in fine but externals cannot
• the loop started after SSO was enforced on the workspace

Not for this skill when

• YOUR OWN users loop (that is an IdP configuration problem, not a counterparty problem)
• the invite link expired (re-send instead)
• the counterparty never got the invite at all (check delivery first)

Variant phrasings

juro sso login loop invite link

juro counterparty cannot login sso redirect loop

juro external user sso bypass

Why it happens

SP-initiated SSO redirects the invite click to the identity provider, which authenticates and returns - but if Juro cannot match the returning session (wrong domain, unassigned app, stale cookie from another workspace), it redirects to login again, and the cycle repeats. Corporate SSO policies are built for employees, so counterparties fall through the cracks by default.

Edge cases

• Users belonging to two Juro workspaces get cross-workspace cookie confusion - incognito is the fastest test.
• IdP-initiated login (from the company portal) behaves differently from the invite-link flow; test the actual link.
• Some IdPs require the user to exist before first login - pre-provision the counterparty if yours does.
• If compliance requires SSO for everyone, provision the counterparty as a guest in the IdP instead of bypassing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KgMkg0RKqyXzSrLR2LIMkA