Related, is OpenRosa Basic Auth still supported for app users against Central, or must you use QR code/token (if so, how do you config a Central app user with a username + password...?)
It is not. You must use URLs with tokens.
OK. We should probably update the Central developer docs to reflect this, since presently we still have:
OpenRosa Endpoints
...
4. Authentication API, which defines how users authenticate with the server. ODK Central provides three authentication methods. One of these is HTTPS Basic Authentication, which is recommended by the OpenRosa specification.
I think it's complete! The next part:
However, because we do not follow the try/retry pattern required by the OpenRosa and the RFC specification, ODK Central is not compliant with this component. Our recommendation generally is to use App User Authentication when submitting data from survey clients.
The only reason we have partial Basic Auth support is for OData clients.
1 Like
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
1 Like