Authentication and identity

You sign in to Disco Parrot with an identity you already have: a Microsoft or Google account. There is no Disco Parrot password to create, store, or reset, because the platform never holds one. Sign-in rides on the identity provider you already trust, and your Disco Parrot account is the thing those logins point at.

This page is about that account and the ways into it: the providers you can sign in with, how one account can carry more than one login, what happens when two accounts turn out to be the same person, how to see and end your active sessions, and how a verified email domain can place you into a workspace the first time you sign in. For where you land once you are in, read workspaces and tenancy.

Signing in

Disco Parrot uses two identity providers for sign-in: Microsoft Entra and Google. Both use the standard OAuth authorization-code flow with PKCE, the proof-backed handshake that keeps the exchange safe even on a public client, so a sign-in is a redirect to your provider and back, never a credential you hand to Disco Parrot.

GitHub is not a way to sign in. GitHub is how Disco Parrot authenticates to your code, your repository providers and the GitHub integration, and that is a different job from logging a person in. It is deliberately kept off the sign-in screen, so a GitHub account alone can never be used to enter the product. The same applies to the brandmarks you might expect from "sign in with": the only two login providers are Microsoft and Google. For what GitHub authentication does cover, see repository providers.

One account, many identities

A single Disco Parrot account can carry more than one login. You might start with your work Microsoft account and later add your Google account, or add a second account from the same provider, and afterward sign in with any of them and arrive at the same Disco Parrot identity, the same workspaces, the same role in each. Your linked logins are managed under Settings → Profile, in a Linked accounts section that lists each one and lets you add another.

Two safeguards shape this. You can never unlink your only login, because that would leave you with no way back in, so the last one is held in place. And linking is exclusive: a given provider login can belong to one Disco Parrot account at a time. If you try to link a login that already belongs to someone else, you are told so plainly rather than silently moving it. Unlinking a login does not on its own end sessions that are already open; to close those, revoke them under Active sessions below.

How a new login finds your account

There is also a quieter path that links accounts without your having to ask. When you sign in with a new provider whose verified email matches an account that already exists, Disco Parrot recognizes it as you and links the new login to that existing account rather than creating a second one. So when Tom Asare, who has always signed in with Microsoft, one day signs in with Google using the same work email, he lands in the same account with both logins attached, instead of spawning a duplicate.

This email-match resolution is how the product keeps one person from quietly becoming two. The match is on an email the identity provider has verified, not one a user can type, so a new login attaches only to an account whose address it can actually prove.

Every login that arrives runs the same check, and there are only three outcomes. A verified email that matches nobody starts a fresh account. A verified email that matches you joins your account. And a verified email that already anchors a different account stops short of linking and offers a merge instead.

When two accounts are really one

Email-match handles the clean case. The messier case is when you have genuinely ended up with two separate Disco Parrot accounts, two logins that resolve to two different identities, each with its own workspaces, and you want them to be one. Disco Parrot detects this the moment you try to link a login that already anchors another account, and instead of refusing outright it offers to merge.

A merge folds one account into the other, and your current account is the survivor. It moves the other account's logins onto yours, brings its workspace memberships across, and then retires the emptied account. The confirmation is detailed on purpose: it shows you the account being merged in, the logins that will move, and every workspace involved, marking which ones come across and which solo workspaces, ones where the other account is the only member, you can choose to keep or let go. Nothing happens until you confirm.

After a merge, the logins that used to reach the old account reach yours, the memberships you chose to keep are yours, and the old account's sessions are ended so nothing keeps running under a name that no longer exists. The whole operation is recorded as an account-merge event, so there is an audit trail of two identities becoming one.

Your active sessions

Every time you sign in, Disco Parrot opens a session, and you can see and end them under Settings → Profile in Active sessions. Each session has a limited life: it lasts up to seven days before it expires on its own, and it is tied to the workspace you were last acting in. The list marks the one you are using right now as current, and lets you revoke any of the others.

Revoking a session ends it at once: the next time that device tries to act, it is signed out and has to sign in again. You cannot revoke the session you are currently using from this list, because that is what sign out is for; the distinction keeps "end my other sessions" and "end this one" from being the same confusing button. Managing your sessions is a self-only action, so you act on your own sessions and no one else's, and no one acts on yours.

This is the control to reach for when you have signed in somewhere you should not have, an old laptop, a shared machine, a borrowed browser. When Sarah Chen signs in on a conference-room machine to show a dashboard and walks out without signing off, she opens Active sessions from her laptop that afternoon, finds the stray session, and revokes it. The conference-room browser is signed out on its next move, and the laptop she is working on is untouched.

Join a workspace by your email domain

If your organization has claimed and verified your email domain on a workspace and turned on auto-join, you do not need an invitation to that workspace. The first time you sign in with Microsoft using an email on that domain, Disco Parrot places you into the workspace as a member and drops you straight into it. There is nothing for you to accept and no link to find; belonging follows from signing in.

Three specifics matter from the person's side:

• It is Microsoft sign-in that carries this, matching how organizations run their workforce identity on Microsoft Entra.
• You arrive as a plain member, not with elevated access; your role is shaped from there.
• It only adds you to a workspace you are not already in, so signing in again never does anything surprising.

The setup that makes this possible, claiming the domain, proving control through DNS, and enabling auto-join, lives on the workspace side in workspaces and tenancy. If no workspace has claimed your domain, none of this applies, and you land in a personal workspace of your own instead.

Single sign-on, SAML, and SCIM

Teams arriving from other tools often ask about SAML, OIDC, and SCIM by name. Here is the straight answer for how identity works in Disco Parrot today.

What is live is OAuth sign-in with Microsoft and Google, plus domain auto-join. For most organizations that combination is the practical shape of single sign-on: people sign in with the corporate identity they already use, and a verified domain lands them in the right workspace automatically. No separate identity-provider integration is needed to get there.

Tenant-configured SAML or OIDC and SCIM provisioning are commercial-plan capabilities rather than a setup flow you turn on yourself. They appear in the plan catalog as line items for the plans that include them, and adopting them is a conversation with the Disco Parrot team rather than a self-service screen. If your security review asks for them by name, treat them as plan entitlements, not as a switch in admin settings.

SCIM's deprovisioning behavior, what happens to workspace membership when your identity provider removes someone, is part of that scoping conversation rather than something to read off the name. For what each plan includes, see plans and usage.

Why authentication works this way

The decision not to hold passwords is the foundation everything else rests on. A password Disco Parrot never stores is a password that cannot leak from Disco Parrot. Sign-in delegates to Microsoft and Google because they already do this job well, with the multi-factor prompts, the conditional-access rules, and the device checks your organization has already configured, and inheriting that is stronger than anything a project tool would reinvent. The PKCE handshake is the current standard for doing that exchange safely; it is table stakes, not a feature to advertise.

One account carrying many logins is the answer to a problem every team eventually hits: the same person reaching the tool from a work account, a personal account, a second tenant. Rather than letting that scatter into duplicate identities with split history, the model pulls them back together, automatically when an email gives it away, and deliberately through a merge when it does not. The result is that a person is one person, with one set of workspaces and one role in each, however they happen to sign in on a given day.

Sessions are short and yours to end because access should be revocable without ceremony. A seven-day life means a forgotten sign-in does not live forever, and a per-session revoke means losing a device is a thirty-second fix rather than a reason to rotate everything. And domain auto-join is single sign-on's most useful property without its heaviest machinery: the right people arrive in the right workspace by signing in, gated by a domain you proved you control, while the full SAML and SCIM apparatus stays available for the organizations whose plans and policies genuinely call for it.

For everyone who signs in, getting in is a redirect to an account you already have, and your linked logins mean it does not matter which one you reach for. There is no new password to keep.

For an engineer, the account model is why your Microsoft and Google logins land in the same place, why an accidental duplicate can be merged back rather than lived with, and why ending a session on a machine you walked away from takes seconds.

For a team lead, identity is the foundation under membership. People bring the corporate accounts your organization already governs, a verified domain can place them automatically, and you are not administering a separate set of credentials on top.

For the person who owns identity and security, this is the honest map. Sign-in is OAuth with Microsoft and Google over PKCE, with no password held in the product; GitHub is a code credential and never a login; membership is explicit or by a domain verified through DNS; sessions are short-lived and self-revocable; and SAML, OIDC, and SCIM are plan capabilities to scope deliberately, not undocumented switches. Nothing about how a person gets in is left to guess.