Identity And Login

AgentHub uses TokenDance ID as the identity authority. The public AgentHub Home site should link users into TokenDance ID instead of implementing a separate local password card.

Login Flow

The website login flow is intentionally simple:

1. The user clicks Log in from AgentHub Home.
2. AgentHub creates a browser-side OIDC authorization request with PKCE.
3. The browser redirects to TokenDance ID.
4. TokenDance ID handles password, third-party providers, account linking, and session policy.
5. TokenDance ID redirects back to the AgentHub callback.
6. AgentHub stores only the low-risk website user profile and expiry needed by the static site UI.
7. The user returns to the localized page that started the login.

AgentHub Home must not present itself as a second identity provider. If the login page needs a visual state, it should be a redirect or transition state into TokenDance ID, not a standalone credential form.

Responsibility Split

Browser State

AgentHub Home is a static site, so browser state must stay narrow:

• store the user display profile and expiry for UI personalization;
• keep the returnTo path same-site and localized;
• do not persist access tokens, ID tokens, refresh tokens, authorization codes, or provider responses;
• do not request offline_access for the static site;
• clear local website state on logout before redirecting to TokenDance ID logout.

If a future Web workbench needs high-trust product access, it should use Hub-owned sessions and server-side validation instead of treating the static-site personalization state as authorization.

Authorization Boundary

Authentication answers "who is this user?". AgentHub authorization still has to answer a separate set of product questions:

Do not treat a successful website login as permission to read local files, start a runtime, approve a tool call, manage TokenDance Gateway keys, or perform Feishu/Lark actions.

Callback And Return Path

The callback route should be boring and auditable:

• accept only the expected OIDC callback parameters;
• verify the browser nonce or state created before the redirect;
• exchange the authorization code through the configured TokenDance ID issuer;
• reject off-site or malformed return paths;
• return users to /en, /zh, or a valid localized same-site route;
• show a clear failure state if the OIDC state, issuer, client id, or callback configuration is wrong.

Public docs can describe the callback shape and expected redirect behavior. They must not publish client secrets, admin keys, raw callback payloads, refresh tokens, or private error responses.

UI Requirements

The login entry should follow the product-site design system:

• keep the primary login button on the right side of the top navigation;
• preserve language and theme controls without making them compete with login;
• use TokenDance Blue for focus and active states;
• avoid a separate black-background login page;
• keep the transition state compact and clear;
• keep Chinese and English copy in the same i18n dictionary structure.

When testing the homepage mock and login state together, theme and language changes should not desynchronize the mock UI, navigation labels, or login state.

Failure Triage

Documentation Rules

When changing login or identity behavior, update these surfaces in the same pass:

• localized homepage login copy and navigation order;
• this identity and login page;
• Security and Troubleshooting if the boundary or failure path changes;
• llms.txt, sitemap, search index, README route inventory, and changelog;
• TokenDance root identity governance docs if the callback, token storage, third-party provider ownership, or relying-party rules change.

Related Pages

• Security
• Configuration
• Data And Privacy
• Troubleshooting