Preflight Checklist
Problem Description
With the addition of auth_sessions, we can assume that the user already inserted user & pass on consecutive auth_requests, but because we do not store MFA status on the session, consecutive auth requests will keep requesting the user to solve the MFA challenge.
Although this behavior might be expected on certain scenarios, there are applications where this is not expected, as if the user authenticated once, it is assumed to be trusted as long as that session exists.
Proposed Solution
To solve this, we can start persisting the MFA state/trust on the auth_session and reuse it for subsequent auth requests.
This would involve:
- Extending auth_session to have some sort of MFACompleted value as boolean
- When a new auth request is initiated and we detect an existing session, instead of prompting for MFA directly, we check if the auth session got a valid MFACompleted value
- If true, we mark the auth_request with MFA validated and keep moving
To provide a way to enforce MFA check on each auth request, we should also give some way for this to be turned on/off, similar to:
Alternatives Considered
The proposed solution assumes that we "trust" the mfa challenge completed for the time a session exists, which is also a limiting factor if the admin wants, for example, to configure a session to live for weeks, while still asking for MFA every 24 hours.
As an alternative to provide a more "complete" solution, we could also track "when" an MFA authenticator challenge was completed by doing something like:
type AuthSession struct {
// ...
MFACompleted map[string]time.Time // authenticator id -> completed at
}This way we can give a configuration parameter like mfaMaxAge where we check if any of the MFACompleted challenges is still valid or if we need to re-prompt even when a session is still valid and active.
Additional Information
No response
Preflight Checklist
Problem Description
With the addition of auth_sessions, we can assume that the user already inserted user & pass on consecutive auth_requests, but because we do not store MFA status on the session, consecutive auth requests will keep requesting the user to solve the MFA challenge.
Although this behavior might be expected on certain scenarios, there are applications where this is not expected, as if the user authenticated once, it is assumed to be trusted as long as that session exists.
Proposed Solution
To solve this, we can start persisting the MFA state/trust on the auth_session and reuse it for subsequent auth requests.
This would involve:
To provide a way to enforce MFA check on each auth request, we should also give some way for this to be turned on/off, similar to:
Alternatives Considered
The proposed solution assumes that we "trust" the mfa challenge completed for the time a session exists, which is also a limiting factor if the admin wants, for example, to configure a session to live for weeks, while still asking for MFA every 24 hours.
As an alternative to provide a more "complete" solution, we could also track "when" an MFA authenticator challenge was completed by doing something like:
This way we can give a configuration parameter like
mfaMaxAgewhere we check if any of the MFACompleted challenges is still valid or if we need to re-prompt even when a session is still valid and active.Additional Information
No response