Authenticating to the registry

You sign in to the registry with the identity you already have. There is no separate registry credential to request, rotate, or store: docker login takes your qibdo email address as the username and an existing qibdo access token as the password, and the registry does the rest through the standard OCI bearer protocol that every Docker-compatible client already speaks.

The exchange

Signing in involves two parties: your client and the registry. The registry serves the token endpoint itself, leaning on qibdo’s identity service only to check your credential and sign the result. None of the steps below need any client configuration.

flowchart LR
  classDef primary fill:#e8e8ff,stroke:#1100ff,stroke-width:2px,color:#0e0d1a
  classDef accent fill:#e2faec,stroke:#00e64d,stroke-width:2px,color:#0e0d1a
  classDef neutral fill:#ececf1,stroke:#302e45,stroke-width:2px,color:#0e0d1a

  client["Docker client"]:::neutral -->|"1. request"| reg["Registry"]:::primary
  reg -->|"2. challenge"| client
  client -->|"3. email + token"| realm["Registry token endpoint"]:::accent
  realm -->|"4. short-lived token"| client
  client -->|"5. retry with token"| reg

1. Your client makes a request the registry will not serve anonymously.
2. The registry answers with a challenge naming where to get a token.
3. Your client presents your email address and your access token to that endpoint.
4. The registry returns a token that is valid for 60 seconds and names exactly the access you hold. It authenticates you through the identity service, then works out the scope itself, because it is the registry that owns your roles, policies, repository visibility and cross-workspace grants.
5. Your client retries with the token. Clients re-run this exchange on their own whenever a token expires mid-operation, so a long pull is unaffected.

Two kinds of credential work as the password: a person access token, and a service account’s token. Both produce the same result, so a pipeline and a person sign in the same way.

Credentials that are not sign-in credentials do not work, and that includes some that look close: a refresh token, an activation link’s token, and a password-reset token are all refused. So are an expired credential, an unknown one, and any credential belonging to a deactivated principal.

Every refusal looks the same

A failed sign-in returns an identical response whatever went wrong. A wrong password, an email that does not exist, a real email paired with somebody else’s valid credential — all of them come back the same. This is deliberate: a response that distinguished them would let an outsider discover which email addresses and workspaces exist by watching how the registry answers.

A token carries the access you already have

The token your client receives is scoped to the repositories it asked about, and it carries only the actions you are actually entitled to. This is the part worth understanding, because it explains an outcome that otherwise looks like a bug: signing in succeeds even when you can do nothing at all.

A client asks for a set of actions on a repository — typically pull, push, or both. The registry resolves who you are, works out what you hold on that repository, and issues a token naming the granted subset:

You ask for	You hold	The token grants
pull,push	pull only	pull
push	push only	push
pull,push	nothing on this repository	nothing

Asking for more than you hold is not an error. The request narrows, and the narrowing surfaces later as a refusal on the operation itself rather than as a failed sign-in. Plain docker login, which asks about no repository at all, therefore always succeeds for a valid credential — it proves who you are and nothing more.

Pull and push are independent. Holding push does not imply pull, and a token that grants one does not grant the other.

What a scope names

A repository is named by its organisation, its workspace, and its own name:

<organisation>/<workspace>/<repository>

The first two segments are always the organisation and the workspace; every segment after them belongs to the repository name, so a repository name may itself contain slashes. A scope naming a workspace that does not belong to the named organisation grants nothing.

Visibility and workspace state

Two things beyond your own grants shape what a token carries.

A public repository grants pull to any authenticated principal, even one with no grant on that repository specifically. Visibility only ever adds pull: it never contributes push, though a principal who holds push through a role or a policy still gets it, because the three sources are combined rather than replaced.

Public does not mean anonymous

In many registries “public” means anyone on the internet can pull without signing in. It does not mean that here. A public repository is readable by any authenticated qibdo principal; there is no way to obtain a token without a valid credential, and the registry serves no anonymous traffic.

A suspended workspace removes push from every token, so images already published stay readable while nothing new can be written. It does not add pull: a principal who held only push is left with nothing. An archived workspace grants nothing at all, and the pull path refuses it besides.

What this means in practice

• Nothing to rotate. No registry-specific secret is created, stored, or expires, so nothing has to be re-issued on a schedule or scrubbed from a CI configuration.
• Changes apply almost immediately. Granting or removing access takes effect on the next token, and an already-issued token stops working when it expires — under a minute later.
• Every sign-in is attributable. Each exchange is recorded against the principal that made it, and a refusal is recorded with a reason that the client is never shown.

See also

• Authenticate a user and manage the session
• The authorization model
• Roles and permissions