Juro counterparty can't access the contract — SSO login loo

Not specified by the original author.

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

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

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

TL;DR:

Not specified by the original author.

TL;DR

SSO failures are a three-way handshake between the user, your app, and their identity provider, and the error almost always lives on the provider side. Read the actual error text instead of guessing, check the email-domain match first, and learn the sentence that hands the ticket to their IT admin cleanly. Half your job here is knowing what is not yours to fix.

The query

how to troubleshoot SSO login failures for users

Use this when

• The "Sign in with" button errors or loops
• SAML or OIDC login fails after the redirect
• Only some users at a company are affected
• A new employee cannot SSO but older ones can
• IT asks you what to check on their side

Not for

• Username and password logins
• Account lockouts from failed attempts
• Setting up a brand-new SSO connection for a customer
• API keys or service accounts

Steps

1. Capture the exact error and where it appears

Ask the user to copy the error text word for word, and note whether it appears on your login page, on the provider's page, or after being bounced back. Provider-page errors are provider problems. Your-page errors are yours.

Expected output: the error text and which side of the redirect showed it.

2. Check the email address matches the SSO domain

The most common failure: the user types a personal or alias address while the SSO connection expects the company domain. Confirm the email they entered matches the domain tied to the SSO setup, including any subdomain.

Expected output: domain match confirmed, or the user redirected to the right address.

3. Rule out a stale session on the provider side

Have them sign out of the identity provider completely, or try the login in an incognito window. A half-expired session at the provider causes silent loops where the user bounces between the two sites forever.

Expected output: the loop breaks, or the provider session is ruled out.

4. Check whether the user is actually assigned the app

In most providers, an admin must grant each user access to your app. New hires fail SSO constantly because nobody assigned them. If older employees work and the new one does not, this is the answer, and only their IT admin can fix it.

Expected output: a yes-or-no on app assignment, from their admin.

5. Hand off to their IT with the right details

Give their admin the timestamp, the user's email, and the exact error. Say plainly what you checked on your side so they do not start over. If your logs show the provider never sent a response, say so, because that proves the break is upstream.

Expected output: a ticket their IT can act on without asking you for basics.

Ready-to-use handoff message

I've checked our side: the login attempt reached us at [time]
but your identity provider didn't send back a completed login
for [their email].

What usually fixes this on the company side:
1. Confirm [their email] is assigned to our app in your
   provider's admin panel
2. Check the app's user list includes any new hires

Once that's confirmed, have them try in an incognito window.
If it still fails, send me the exact error text and I'll dig
deeper on our end.

Variant phrasings

sign in with google not working support

Steps 1 through 3. Google-side errors usually mean the wrong Google account is active in the browser, especially with multiple profiles.

SAML login loop troubleshooting

Steps 1 and 3. Loops are almost always a stale provider session or a clock skew between the provider and your servers.

new employee cannot log in with SSO

Step 4 first. It is the app assignment, every time, until proven otherwise.

Why it happens

SSO outsources the "who is this person" question to the customer's provider, which means your login page is now dependent on a system you cannot see into. Any mismatch, expired assignment, stale session, or config drift on their side surfaces as your login being broken. The user blames your app because your logo is on the button, but the fix usually lives in their admin console.

Edge cases

• User has two accounts with similar emails: the provider may be sending the personal one while your app expects the work one. Check the email in your user record against what they typed.
• SSO worked until the company changed providers: the connection on your side may still point at the old one. This is a reconfiguration, not a user bug. Escalate.
• Intermittent failures for everyone: look at your own side. Provider outages and expired certificates on your end hit all users at once.
• The error says the user does not exist in your app: they may need an account created first before SSO can link. Check whether your setup auto-provisions or needs manual invites.
• IT insists everything is fine on their side: ask for a screenshot of the user's app assignment and a fresh timestamped attempt. "Fine" without evidence is not a diagnosis.

Provenance

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

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

Thread query: how to troubleshoot SSO login failures for users

TL;DR: SSO failures are a three-way handshake between the user, your app, and their identity provider, and the error almost always lives on the provider side. Read the actual error text instead of guessing, check the email-domain match first, and learn the sentence that hands the ticket to their IT admin cleanly. Half your job here is knowing what is not yours to fix.

Not specified by the original author.

TL;DR

A login loop means the app and the identity provider keep handing the user back and forth without ever creating a session. Start with a clean incognito test to rule out stale cookies, then check the three usual suspects: clock skew, a mismatched reply URL or certificate, and a user the provider recognizes but the app does not. Most loops are one of those three, not a broken integration.

The query

SSO login loops: support troubleshooting steps

Use this when

• Users report being bounced between the app and Okta, Entra ID, Google Workspace, or another identity provider
• "Too many redirects" appears during login
• Login works for some users but loops for others
• SSO just rolled out and a whole team is stuck

Not for

• Password reset requests
• MFA enrollment or lost authenticator apps
• Deciding which identity provider to buy or how to set up SSO the first time
• Account provisioning and deprovisioning policy

Steps

1. Reproduce in a clean browser session

Have the user try in incognito or a different browser. If the loop disappears, it is stale session cookies on their normal browser, not your SSO config.

Expected output: you know whether the problem is the user's browser or your side.

2. Capture where the loop hands off

Ask the user to note the URL bar as it cycles: does it bounce between your app and the provider, or stay inside the provider? A bounce between the two means the app rejected the provider response. A loop inside the provider means the provider never finished authenticating.

Expected output: you know which side to investigate first.

3. Check the three usual suspects on your side

Clock skew: if your server clock is more than a few minutes off, signed assertions fail validation. Reply URL mismatch: the reply URL in your app must match what is registered in the provider exactly, including trailing slashes. Expired or rotated certificate: confirm the signing cert in the provider matches the one your app trusts.

Expected output: one of the three is confirmed or ruled out in about ten minutes.

4. Verify the user exists and is assigned in the provider

With just-in-time provisioning off, a user the provider authenticates but the app has no record of will bounce forever. Check the user is assigned to the app in the provider admin console.

Expected output: assignment confirmed, or you found the missing assignment.

5. Read the login error the app logged

The app almost always logs why it rejected the response. Look for the login attempt in your logs around the user's timestamp and read the actual error instead of guessing.

Expected output: the log line names the cause, and you can fix it or escalate with evidence.

Template: what to ask the user

Thanks for reporting this, [Name]. A few quick questions so I can
pinpoint the loop:

1. Which identity provider do you sign in with (Okta, Entra ID, Google)?
2. Does it loop in an incognito window too?
3. What time did it last happen (so I can check our logs)?
4. Are any teammates hitting the same thing, or just you?

Variant phrasings

sso keeps redirecting me in circles

Same steps. The incognito test in step 1 resolves about half of these tickets.

login loops after entering credentials

This phrasing usually means the provider authenticated fine and the app rejected the response. Start at step 3.

too many redirects on sso login

Check the reply URL first. A mismatch there is the most common cause of the browser redirect error.

Why it happens

SSO is a handshake with no memory: the app redirects to the provider, the provider sends back a signed response, the app validates it and creates a session. If validation fails for any reason, the app does the only thing it knows, redirect again, and the provider happily sends another response. Neither side errors out visibly, so the user sees an infinite loop instead of an error message.

Edge cases

• Multiple provider tenants: a user authenticating against the wrong tenant gets a valid response the app cannot map. Check the tenant or domain.
• Deep-link login: bookmarked URLs that skip the first redirect can start the flow mid-handshake. Have them log in from the homepage.
• Cookie-blocking browsers: some privacy settings block the session cookie the app sets after validation, so the loop restarts every time. Incognito with default settings usually works.
• Recently rotated signing certs: the app trusts the old cert until you update it. This breaks everyone at once, which is actually the easy diagnosis.

Provenance

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

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

Thread query: SSO login loops: support troubleshooting steps

TL;DR: A login loop means the app and the identity provider keep handing the user back and forth without ever creating a session. Start with a clean incognito test to rule out stale cookies, then check the three usual suspects: clock skew, a mismatched reply URL or certificate, and a user the provider recognizes but the app does not. Most loops are one of those three, not a broken integration.