3 ms·

> you might be stuck sheepishly asking the user to try again, because the sync control flow (including auth) starts from the user. How does this actually work

> you might be stuck sheepishly asking the user to try again, because the sync control flow (including auth) starts from the user. How does this actually work in practice? At some point you need to communicate the results of a successful or failed login attempt to the user (more generally, the initiating party) which means they're inherently waiting for something and will either see a success or a failure. A login as a precursor event to other kinds of actions feels inherently synchronous, because it's not a fire-and-forget action.

mrkeen 2y ago
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.

mrkeen 2y ago

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.