0. The user must be already logged in to the website on their desktop via any conventional means.
1. The website generates a QR code with a hard-to-guess URL, unique for the user.
2. The user reads the QR code with their phone, and opens the link in the mobile phone's browser.
3. The URL is unique for the user and hard to guess, so the user can be logged in their mobile browser without asking for an username and password.
1. If there are XSS vulnerabilities on the website, an attacker could be able to use iframes (at least if you haven’t set X-Frame-Options to DENY) or XMLHttpRequest to retrieve an authentication QR code and use it to log into the user’s account.
2. Even without any XSS, it is possible that someone who has access to the user’s session (for example, if the user is still logged in on the website, but is away from the computer) could scan the QR code and, therefore, log into the user’s account.
Possible solutions include sending the QR code by email (actually, some users are always logged into their email accounts as well, so this might be meaningless) and prompting the user for their password before displaying the QR code (it is still much easier to type the password on a desktop/laptop computer’s keyboard rather than type the site address + login or email + password on a mobile device’s virtual keyboard).
My idea for auth with QR codes would work something like:
a) initial setup: user establishes profile with website, including creating a public/private key pair. Public key stays with the service, private key in the user's phone/app.
b) To authenticate, website presents user with QR code containing a token encrypted with user's public key.
c) user scans code with phone/app, decrypts token with private key, signs it, and returns it to service, which verifies token and signature thus authenticating user.
But then all you've done is validated the user on his/her phone... not on the computer displaying the web page with the original QR code. What am I missing?