A bit more context and detail. TL;DR: clients today are expected to use a special URL as auth. There's a possibility that an additional auth option will be added in the near future.
We try to design Central and other ODK tools generically but the primary use-case we have in mind is enumerator-mediated data collection in remote areas by enumerators who have limited training. In these contexts, there's usually a big difference between "field staff" and "office staff" and little overlap in responsibility. Some of the additional design considerations that led to App Users being separate from Web Users and using a URL-embedded token:
- Devices are sometimes provisioned offline
- It's common for many devices to be provisioned at the same time (e.g. during a training)
- Typing in a password is time-consuming and provides no significant security benefit if it's shared
- Identification of individuals is often done through deviceid or a question in the form
- We want Central account holders to have an email address and manage their own password (security best practice) but enumerators often don't have email or aren't comfortable with it
- Provisioning devices to be connected to a "project slice" (subset of forms in a single project) is simpler to reason about than connecting them to an identity which could have access to many projects. We think of the "data collection view" as separate from the "back office view"
- Devices can be offline for a very long time
- We really don't want people putting their Central admin credentials in clients
- Basic and digest auth both have security issues (e.g. no strong backend password encryption for digest) and are slow (because credentials are checked with each request)
- There isn't a single token auth flow (see e.g. Moving to a Modern Authentication Method)
QR code provisioning and App Users as roles with access to a subset of forms has been a big hit with the majority of our users. The biggest pain points we hear about currently are cases where there are many (e.g. 1000s) of data collectors and a desire to be able to revoke their access on an individual basis and cases where Enketo is used for filling out data but individuals should only have access to a subset of forms in a project.
As I hinted at during the last TAB call, a couple of things shift as we introduce the Entity concept:
- We feel a stronger need to identify individuals for data protection purposes
- We see more likelihood of data collectors needing server access in more complex workflows