QR Code authorisation/login


has anyone implemented a client authorization (mainly desktop) via QR code similar to Telegram or Instagram. (in Meteor indeed).

Was looking for some inspiration for the best practice.

Thank you

Maybe is right to using “magic link” authorization and take it’s QR code

No different than any OTP or login tokens implementation. Just that the OTP or tokens are displayed as links converted to QR Code.

Ok, the OTP is generated on the client I need to log in (desktop) and with a logged device I confirm the OTP is valid for my own client, or rather add it to my own client (logged on my mobile) and then I log the session that generated the OTP with my own token … I think the difference here is that I don’t know yet what is the user at the time the OTP (QR) is generated.

Sorry @rjdavid, I feel your answer is a bit minimalistic which hints to the fact that this should be simple but I think I did not get all pieces together.

Can you expound your user flow?

The QR code part here is just a UI representation equivalent to the user clicking a link.

The user flow is the same as in Telegram or Whatsapp (and most crypto apps wallets or exchanges).

For ease of logic, I will use Desktop for not authenticated device and Mobile for the authenticated one.

You have a logged in Mobile app (or web session).
You generate/show a QR code in a browser on Desktop.
You scan the QR code with the Mobile.
Your Desktop gets logged in.

In desktop, you generate a time-limited token in server, save in a collection, and then send as a publication to the client. The client page, will display the corresponding QR code to the subscribed token.

Mobile scans the qr code, and visits the link (technically getting the token). Search the token collection and update the record with the corresponding userId of the logged in user.

Since the desktop app is subscribed to the token, it will get the userId of the user and use that record (userId and token) to auto-login the user to the desktop


I do exactly what @rjdavid described, but using a very short lifespan 6-digit number instead of a QR code/token because I’m dealing with devices without cameras. Same as other OTP but on-demand/ad-hoc instead of time-based codes.

1 Like

@paulishca, 2FA is being added right now, see: 2FA for accounts · Discussion #11514 · meteor/meteor · GitHub

1 Like

Thanks a lot. I think I now have enough info to actually make a more complex workflow that includes all 3 suggestions. Will probably drop email/password in favor of passwordless and on authenticating a new client using an already logged client, request the input of a 6 digits token on the new client as the result of scanning the QR (or requesting a 6 digit code if a camera is not present).