<div dir="ltr">I claimed on the last call that I intended to model a Duo 2-factor login as a post-interceptor flow, and on further consideration I'm feeling fairly uncomfortable with that plan. I have a requirement to toggle the flow on/off based on user attributes, which naturally requires attribute resolution as a prerequisite. That requirement drove me to look at interceptor flows since they happen _after_ attribute resolution. But the authentication is already committed at that point (IdPSession created), and I have to undo at least session creation if I go the interceptor route. So the process becomes:<div><br></div><div>1. Undo session creation</div><div>2. Run 2-factor flow</div><div>3. Redo session creation on success</div><div><br></div><div>I believe it's a feasible solution, but it's sufficiently hackish to make me want some input before I head that direction.<br></div><div><div><br></div><div>It occurs to me that perhaps there's a reasonable feature that might be implemented to support this case, namely authn flows driven by user attributes, which I anticipate could be commonplace. Add a flag to defer the UpdateSessionWithAuthenticationResult action until after the interceptor flows complete. I haven't fully analyzed the consequences of that choice, but it seems straightforward to implement and I believe it would meet my needs.</div><div><br></div><div>Of course hooks could be added to the authn flows directly for these cases, but I have the sense that would be even more hackish given the requirement for an AttributeContext. My concerns aside, are there any other reasonable solutions that might be realized in the 3.2.0 timeframe? I'm fully willing to commit dev cycles to support this case as we need it now if not sooner ;)</div><div><br></div><div>Thanks,</div><div>M</div><div><br></div></div></div>