I'm not sure I see the benefit of creating a generic pipeline vs just having a "manager" class or function that calls each step in succession. The process of "logging in" is conceptually a single step, thus it makes sense to have one unit that abstracts over the entire process. Factoring out the logic of successive calls into a pipeline doesn't seem very useful here. I could see a benefit if it were the case that each subprocess existed and is executed independently, but in the login case and probably most cases in general web development, this usually isn't true.

To me, the benefit of a pipeline is when each filter can register itself (e.g. an event queue), thus the entity generating it has no knowledge of where it is going or who is processing it. A key indicator of this is when order of execution doesn't matter. In the case of logging in, order is critical so something somewhere must control the order each filter is ran. At this point you might as well have a unit that orchestrates this process itself.