How Authentication Works
Duro has two ways to prove who you are. Picking the wrong one costs you a day, so start here.
A script, integration, or backend service acting as your organization
An API key in the x-api-key header — see Authentication
An identity provider signing your people in
SAML SSO and SCIM, covered in this section
An application signing in as an individual person
The account APIs below
Most integrations want an API key. If yours authenticates with x-api-key, nothing in this section changes anything for you.
What lives where
Duro runs its own authentication — there is no third-party identity provider in the path. Account creation, verification, sign-in, password reset, Google, and SAML all run on Duro's own domain.
Anything that creates or destroys a credential is REST, under /auth/* on the API host. Anything that configures identity is GraphQL, alongside the rest of the API.
https://api.durohub.com/auth/… authentication
https://api.durohub.com/graphql everything elseBecause authentication is REST, none of it appears in the GraphQL schema or Apollo Explorer.
Signing in is not the same as having access
Worth knowing whichever credential you use, because it is the surprise that catches people:
A successful sign-in does not mean the caller can use Duro.
Duro admits someone when any of these is true:
They already belong to an organization
A live invitation exists for their verified email address
An organization's allowlist covers their address or domain
They hold a pending organization-creation grant
An account with none of those can read its own profile and little else; organization-scoped queries are refused. user { me { hasOrganizations } } is the cheapest way to check — see Current User.
Note verified in point 2. An address must be verified before an invitation, allowlist entry, or domain match will apply to it.
Where to go next
Sign up and verify an account through the API
Let your identity provider sign your people in
Provision users and teams automatically
Last updated
Was this helpful?