Currently, the GET /v1/oauth2/authorize endpoint returns a 401 {"error": "login_required"} response when the user is not already authenticated. This requires clients to handle login externally, which is inconvenient for applications that cannot render their own login UI.
Proposed Change
When a client issues a GET /v1/oauth2/authorize request and the user is not authorized, the authorization server should instead render a hosted login form rather than returning an error.
The hosted login form should:
- Support standard username/password authentication.
- Handle MFA challenges if the user’s account requires it.
- Preserve the original query parameters from the
GET /v1/oauth2/authorize request, including client_id, redirect_uri, state, and scope. These values will be reused in the subsequent POST /v1/oauth2/authorize request when the form is submitted.
Upon successful authentication, the authorization flow should redirect to the client’s registered redirect_uri, completing the OAuth2 authorization sequence.
Implementation Notes
- Update the Auth SDK to support rendering and handling the login form for authorization flows.
- Ensure the login form properly posts to
/v1/oauth2/authorize with the correct query parameters.
- Integrate MFA handling into the form workflow (e.g., secondary code prompt).
- Modify end-to-end tests to verify the new login flow, including both standard and MFA cases.
- Consider the interaction between this change and existing session handling (e.g., already-authenticated users should still bypass the login form).
Currently, the
GET /v1/oauth2/authorizeendpoint returns a401 {"error": "login_required"}response when the user is not already authenticated. This requires clients to handle login externally, which is inconvenient for applications that cannot render their own login UI.Proposed Change
When a client issues a
GET /v1/oauth2/authorizerequest and the user is not authorized, the authorization server should instead render a hosted login form rather than returning an error.The hosted login form should:
GET /v1/oauth2/authorizerequest, includingclient_id,redirect_uri,state, andscope. These values will be reused in the subsequentPOST /v1/oauth2/authorizerequest when the form is submitted.Upon successful authentication, the authorization flow should redirect to the client’s registered
redirect_uri, completing the OAuth2 authorization sequence.Implementation Notes
/v1/oauth2/authorizewith the correct query parameters.