1. What is the issue? Please be detailed.
App users don't have to log in, it's enough to have the QR code and open it with ODK Collect and ODK Collect will be configured with that app user.
I am sure this question has been asked many times, but I searched the forum on words like 'authentication' and didn't get usable answers.
In short: how to authenticate app users, if it's possible.
2. What steps can we take to reproduce this issue?
Create app user, share QR code.
3. What have you tried to fix the issue?
Nothing
4. Upload any forms or screenshots you can share publicly below.
If needed I could provide but it's all standard ODK Form stuff.
AFAIK there is no way to authenticate using ODK Collect directly.
A possible workaround is creating a question asking for a password and use constraint like suggested here So a password for each user, that means you then have to keep track of users and manage the passwords.
You will still have the problem that they then can share their password and the QR code, but at least if you see the same password used with different deviceids, you can know who shared a password
Another option is to create custom QR codes and setting username, in this case you'll then have to be creating QR codes instead of managing passwords. Again they can share the custom QR but you will be able to spot by checking the deviceids.
The App User QR code is the way App Users authenticate. I'm realizing that we really should improve documentation around this as I agree that it's not very clear that this is what's going on.
App User QR codes are an example of passwordless authentication which is generally recommended over password auth when possible. Here is an article with some context. The QR codes contain a long, random string of characters (a secure token) that is specific to the App User that is being configured. When you revoke an App User's access, that token is invalidated.
App User QR codes were designed in response to poor security practices that we identified from users of Aggregate using usernames and passwords for data collectors. Project managers would either generate a single shared account with an easy password like "123" or generate one account per data collector with an easy-to-remember password pattern like "last name birthyear". These weak passwords are easy to guess and easy for data collectors to leak to others. At the same time, they were tedious to enter and could require several attempts or clarification ("was it "first name birth month?" "last name birth year?").
Tokens stored in QR codes are impossible to guess and can't be leaked through manual entry. However, the QR codes themselves need to be treated just like passwords. We see a few common device provisioning patterns:
If an App User represents a role, the auth QR code can be put up on a slide, printed, put on one device that's passed around, etc and shared during a training session. It's important that the QR code source is destroyed/secured.
The auth QR code can be sent via WhatsApp or some other secure communication channel. It's then the responsibility of the data collectors to keep that channel secure and/or delete the message.
The auth QR code can be scanned in directly from Central at "the office" / during a training so that the QR code never exists outside of Central or the device.
By default, the token or a username and password could be accessed from Collect settings. You can lock this down by setting a Collect project admin password. These admin passwords can also be included in a configuration QR code but again, you'll need to make sure the QR code is treated as confidential.
In general, you should make sure that the Android devices used are locked with a PIN or biometrics. The documentation has some references on general Android best practices.
I agree with all of @nmambre's suggested additional ways to validate and verify individual data collectors' identity.
If you say more about your scenario, we may be able to provide additional guidance. Some questions to consider:
How many data collectors do you have?
Are they using their own devices or devices managed by your project?
When do you want to configure devices (e.g. at a training, whenever a data collector is hired, etc)?
Are your data collectors trusted? Tech-savvy? Distracted? Likely to make mistakes?
What external threats are there to your project? Malicious actors who want access to your data? Malicious actors who want to disrupt data collection?