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.
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
seacat-auth/seacatauth/external_login/handler.py
Line 147 in d2b7561
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
stateto the existing flowstate- an unique opaque string mapped to the original requested URL (and possibly other necessary authorization metadata).statestring is propagated to the login page (as a query parameter). The login UI ensures this state is added to the external login URLs obtained fromGET /public/featuresGET /public/ext-login/{ext_login_provider}with thestateparameter.stateparameter 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
statein this case yet.PROs:
CONs:
Option 2: Authorization flow with OpenID ACR values
acr_valuesparameter. It is up to the authorization server to define its own ACR values.seacat:ext:google,seacat:ext:githubetc.acr_values=seacat:ext:googleandprompt=login, Seacat redirect the user directly to the external identity provider login (with astateparameter).Reference:
idp:google(https://stackoverflow.com/q/71159908)PROs:
/public/ext-login/{ext_login_provider}endpoints altogether.CONs: