What I said about batched handling of support cases probably doesn't apply to logins - you're not going to 'fix' a login in time for it to be useful. Yes, the

What I said about batched handling of support cases probably doesn't apply to logins - you're not going to 'fix' a login in time for it to be useful. Yes, the user is waiting for their login to return, so it will feel synchronous to them. ( As some background, BankID is the de-facto auth service here. In its previous form, you typed your personal number in, and you'd get a popup on your phone where you'd enter your pin. They made the flow more secure by displaying an animated qr instead of typing in your personal number. Here's the new flow as used by the Tax Office: https://m01-mg-local.auth.funktionstjanster.se/mg-local/auth/ccp5/grp/this https://m01-mg-local.auth.funktionstjanster.se/mg-local/auth... Swedbank didn't get the memo and is still using the old flow: https://online.swedbank.se/app/ib/logga-in https://online.swedbank.se/app/ib/logga-in ) Check out the BankID flow charts: https://developers.bankid.com/getting-started/use-cases https://developers.bankid.com/getting-started/use-cases. If you're a small business integrating against BankID, it probably doesn't matter if each iteration of the backend<->bankid /collect loop uses its own thread (sleeping for 1-2s each time). But at BankIds scale there's no way they'd be maintaining a separate thread of execution for each user, it would need to be batched.