XMPP Portál
OAuth console (tokens & client maintenance)Nápověda k této stránce · kliknutím rozbalíte

A superadmin workbench for the host you are viewing: watch live login tokens, mint a token for any account, revoke access in one click, and maintain clients.

Tato příručka pokrývá:

  • What it does
  • How it behaves, and why
  • Common use cases

Otevřít celou příručku

OAuth console (tokens & client maintenance)

Access & OAuth

A superadmin workbench for the host you are viewing: watch live login tokens, mint a token for any account, revoke access in one click, and maintain clients.

What it does

The console shows, at a glance, how many clients are registered on this host and how many tokens are currently active. From here you can:

  • Issue a token — create an access token for any existing account, with a chosen lifetime and scopes.
  • Revoke a token — instantly invalidate one live token.
  • Maintain a client — open it to change its allowed scopes, rotate its secret, or delete it.

Unlike the basic clients page, everything here is scoped to the host shown in the badge: token and client lists only show items belonging to that host.

How it behaves, and why

Issued tokens are shown exactly once. After the confirmation page there is no way to view the token again — by anyone. This is deliberate: it mirrors how passwords are handled and limits exposure. Copy the token to a password manager or hand it to the user before leaving the page. If it is lost, simply issue a new one and let the old one expire.

Token lifetime can be set from 1 hour up to 720 hours (30 days), defaulting to 24 hours. The account must already exist on the host. Tokens work immediately and appear in the live list.

Revocation is immediate and permanent. The app or user holding that token loses access at once and must sign in again. This is the fastest way to react to a leaked token — you do not need to disable the person's account.

Scope edits apply in both places — the gateway registry and the XMPP server — so the tighter limits take effect right away.

Rotating a secret generates a fresh secret for a password-grant client and shows it once. The old secret stops working immediately, so expect to reconfigure the app at the same moment. Only password-grant clients have a secret; browser clients use redirect addresses instead. Deleting a client removes it from both the server and the registry, and asks for confirmation first.

Common use cases

  • Help a user connect a legacy app that cannot do the interactive sign-in: mint a short-lived sasl_auth token and send it to them securely.
  • Respond to a leaked token: find it in the live list (the user's JID and scopes are shown next to it) and revoke it.
  • Test an integration before wiring up the full sign-in flow — issue a token, try it, let it expire.
  • Tighten an over-privileged app: trim its scopes, or rotate its secret after a developer leaves the project.

Osvědčené postupy

  • Use short lifetimes; 24 hours suits almost everything, 1 hour for tests.
  • Grant only the scopes needed — sasl_auth alone if the token is just for logging in.
  • Copy shown-once tokens and secrets to a password manager immediately.
  • Revoke a user's tokens when they leave, before anything else.
  • After rotating a secret, confirm the app works with the new one before closing the page.