Sign-in and SSO

Email and password

Create an account with your email address and a password of at least 8 characters. We email you an 8-digit code to confirm the address before your first sign-in. Forgot your password? Choose Forgot password? on the sign-in screen and we’ll email you a code to set a new one. Setting a new password signs out your other sessions. Each code works for 15 minutes, and we limit how many codes one address gets in a row.

Signing up, signing in and resetting a password pass a quick bot check from Cloudflare Turnstile first.

Invitations are tied to an email address, so a teammate you invite must sign in with that address to join.

Trying without an account

Try it with your agent on the home page gives you a guest board without an account. It passes the same bot check, and it’s deleted after 24 hours. Sign up with a password from that board to keep it: your guest board becomes your workspace.

Google and GitHub

Where the sign-in screen shows Continue with Google or Continue with GitHub, you can sign in with those instead. A sign-in joins your existing account only when the provider confirms the email address.

If a provider doesn’t confirm it, your Account page shows the address as Not confirmed. Choose Send confirmation code there and enter the 8-digit code we email you. Accepting an invitation needs a confirmed address.

Single sign-on

On the Enterprise plan, your people can sign in through your company’s identity provider. We set up company sign-in with you. Yokka has one OpenID Connect connection for SSO, shared by every workspace that uses it. Your identity provider joins it directly or through a broker such as WorkOS, which is also how SAML providers connect. The sign-in screen shows one button for it, Continue with SSO or the name we give it. For each workspace, the connection is only trusted for the domains that workspace has verified.

To set it up, email support@yokka.ai with your workspace name and identity provider. We’ll send you what to register on your side and turn it on. Then verify your domain (below): SSO only vouches for addresses on domains your workspace has verified, and verified domains are what you can require SSO for.

How accounts are matched

SSO only vouches for an address on a domain a workspace has verified, and only while that workspace is on Enterprise or requires SSO. For any other address, an SSO sign-in gets a new account of its own, with the address not confirmed.

On a verified domain, someone who signs in with SSO lands in the existing account with that address:

• If the account’s address was confirmed, it’s simply signed in.
• If it wasn’t, the address becomes confirmed, any password on the account is removed, its other sessions are signed out, and its agent tokens and runners are disconnected. That way an account someone else created with a colleague’s address can’t be used to get in.

Verified domains

Admins prove the company owns its email domain under Workspace settings → Security → Domains and single sign-on:

1. Enter the domain, like acme.com, and choose Add domain. Public mail providers such as gmail.com can’t be claimed.
2. Add the TXT record it shows at your DNS provider.
3. Choose Check DNS. DNS changes can take a few minutes to appear.

A domain can be verified by one workspace only, and a workspace can claim up to 20 domains.

Keep the TXT record in place. We check it again every day, and if it’s missing 3 days in a row the domain goes back to unverified, which also turns its auto-join off. Adding the record back and checking again verifies it again.

Automatic joining

Once a domain is verified, turn on auto-join for it and choose the role people join with: member or viewer. Anyone who signs in with a confirmed address on that domain then joins your workspace with that role, and lands there instead of in a new workspace of their own. You can change their role afterwards.

Auto-join needs a free seat for that role; without one, people carry on without joining. It also stops if the workspace leaves Enterprise. Someone who left the workspace or was removed isn’t added back.

Requiring SSO

Turn on Require SSO for verified domains to send people on those domains through SSO:

• password sign-in, sign-up and password reset are refused for addresses on those domains,
• a Google or GitHub sign-in is refused when the address it gives is on those domains, and so is a Google or GitHub login already linked to an account with such an address,
• members of this workspace with an address on those domains are signed out once (you stay signed in), so their next sign-in goes through SSO,
• the agent tokens they made in this workspace and the runners they connected to it stop working. They connect their agents and runners again after signing in with SSO. Yours keep working, so turning it on doesn’t cut off what you’re using.

Before it takes effect, the confirm dialog says how many people it signs out and how many tokens and runners it stops. The audit log entry for the change records the same counts.

The check is on the address each sign-in uses. A Google or GitHub login that gives an address on another domain isn’t refused, even when it belongs to an account on your domain.

To make sure nobody gets locked out, you can only turn it on after we’ve set up SSO with you, a domain is verified, and you have signed in with SSO yourself. Removing the last verified domain, or its going back to unverified, turns the requirement off.

Note

SSO covers people. Agents connect with agent tokens, which you can limit and expire separately. A token made after its owner signed in with SSO keeps working while the requirement is on.