Skip to content

spec: Specify select account flow with custom ui#5788

Open
tung2744 wants to merge 6 commits into
authgear:mainfrom
tung2744:dev-3670
Open

spec: Specify select account flow with custom ui#5788
tung2744 wants to merge 6 commits into
authgear:mainfrom
tung2744:dev-3670

Conversation

@tung2744

Copy link
Copy Markdown
Contributor

ref DEV-3670

Comment thread docs/specs/custom-ui-select-account.md Outdated
…tinuation

Custom UI hosted same-site with Authgear (shared registrable domain)
lets SameSite=Lax cookies flow on a POST form submit, not just a GET
navigation. Cross-site Custom UI simply doesn't get this feature and
falls back to the normal authentication flow.
@tung2744

tung2744 commented Jul 3, 2026

Copy link
Copy Markdown
Contributor Author

Updated the spec with the assumption of same-site custom ui.

Comment thread docs/specs/custom-ui-select-account.md Outdated
…dentify option

Supersede the out-of-band x_select_account_token + redirect design with a
new identification option, select_account, inside the identify step of the
login and signup_login flows. This reuses the existing Authentication Flow
API and CORS/session infrastructure instead of introducing a new token
store and endpoints, and documents config, HTTP API shapes, CORS behavior,
security analysis, and use cases for the new approach.

Also cross-reference the new spec from the identification: select_account
section of the Authentication Flow API reference.
@tung2744

Copy link
Copy Markdown
Contributor Author

Redesigned using authflow api with assumption on same site custom ui.
Key changes:

  • Added identification: select_account to login and signup_login flows
  • Specified CORS behavior of authentication flow api

…arams

signup/reauth/account_recovery are design scope boundaries, not edge
cases within a supported flow, so they move to a new Scope section.
Also document max_age, id_token_hint, prompt=select_account, and
acr_values against the actual authorize-endpoint behavior, and fix an
existing inconsistency where login_hint was said to omit the option
"regardless of match" though only a mismatch does.

- **`prompt=login`**: option omitted (see [Session and account resolution](#session-and-account-resolution)).
- **`prompt=none`**: not applicable — decided before any flow exists.
- **`prompt=select_account`**: not supported — has no effect, despite sharing its name with this feature's `select_account` identification option (unrelated concepts).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Research on prompt=select_account behavior

- **`max_age`**: not a separate rule. An expired `max_age` is folded server-side into a synthesized `prompt=login`, so it's already covered by the `prompt=login` case above.
- **`id_token_hint`**: option omitted when its `sub` claim identifies a different user than the session — the same rule as a mismatched `login_hint` (see [Session and account resolution](#session-and-account-resolution)).
- **`acr_values`**: not supported — no interaction with `select_account` today.
- **`login_hint` matching the session's user**: option is still offered — only a *mismatched* `login_hint` omits it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check existing login_hint behavior on api / default auth ui

Compares how Google, Azure AD, Auth0, and Keycloak actually handle
prompt=select_account, login_hint, and id_token_hint at their
authorize endpoints, based on live testing and reading Keycloak's
source.
@tung2744

Copy link
Copy Markdown
Contributor Author

@carmenlau @fungc-io @chpapa

Added a section on research of well known idp's behavior on prompt=select_account.

  1. All tested Idps never returns account_selection_required error as the spec stated. All fallback to normal login.
  2. login_hint, id_token_hint do not constraint login, they only prefill or provide choices.

So my take:

  • We do not need to follow the spec strictly to return account_selection_required error when there are no choices. Fallback to normal login is a more common UX.
  • login_hint and id_token_hint do not constraint the API. We should still pass them to the custom UI as a hint. The custom UI should decide how they should be used, select_account options on API level will not be affected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants