Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customizable redirect after successful external login #316

Open
byewokko opened this issue Nov 1, 2023 · 0 comments
Open

Customizable redirect after successful external login #316

byewokko opened this issue Nov 1, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@byewokko
Copy link
Collaborator

byewokko commented Nov 1, 2023

Current behavior

Successful login via external identity provider redirects the user to "My account" page of Seacat Auth UI, whicxh is sort of a dead end for the user.
See

response = self._my_account_redirect_response(state=state)

Expected behavior

Successful login via external identity provider redirects the user to whatever the original requested URL was. If this fails, there should be a configurable fallback URL.

This must also extend to registering a new external login for an existing user.

Proposed implementation

Option 1: Adding state to the existing flow

  • When an authorization request results in redirection to login, Seacat Auth stores an internal state - an unique opaque string mapped to the original requested URL (and possibly other necessary authorization metadata).
  • The state string is propagated to the login page (as a query parameter). The login UI ensures this state is added to the external login URLs obtained from GET /public/features
  • When external login succeeds, the external identity provider redirects the user to GET /public/ext-login/{ext_login_provider} with the state parameter.
  • Seacat Auth decodes the state parameter and redirects the user to the corresponding URL.

The flow for registering new external login provider for an already logged-in user should be analogous, but i'm not sure how to store the state in this case yet.

PROs:

  • Easier implementation on backend.

CONs:

  • Reliance on the UI.
  • Not sure how to solve it for the registration of external login providers for already logged-in users.

Option 2: Authorization flow with OpenID ACR values

  • OpenID authorization endpoint defines a way for the client to request a specific authentication class (e.g. single-factor auth, two-factor auth, hardware key auth etc.) using the acr_values parameter. It is up to the authorization server to define its own ACR values.
  • Seacat Auth specifies a set of ACR values for external identity providers, e.g. seacat:ext:google, seacat:ext:github etc.
  • When the authorization request specifies acr_values=seacat:ext:google and prompt=login, Seacat redirect the user directly to the external identity provider login (with a state parameter).

Reference:

PROs:

  • Does not rely on UI.
  • Solves both login and registration.
  • Closer to standard OpenID approaches.
  • Less endpoints - we might eventually ditch the /public/ext-login/{ext_login_provider} endpoints altogether.

CONs:

  • More implementation work on backend.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant