Approximately 2'30’’ minutes reading time

Windmill thus far has been devoid of the concept of a user account. There hasn’t been a need since Windmill has been a standalone macOS app. With the arrival of Windmill on the iPhone the requirement to have a “user” account becomes more apparent.

On the iPhone, a user should be able to view the IPA file for each app that has been exported. There are two parts in enabling this functionality.

• Publish an export for a given “user”.
• Return a list of exports for a given “user”.

Both to be supported by a server that provides a REST API.

Requirements

The simplest thing would be to have a user create an account using a username and a password. I take a few issues with this approach.

No passwords.

First and foremost I consider asking a user for a password a compromise in security for the following reasons.

• Users tend to reuse passwords across services.
• Database leaks expose user accounts across services.
• Security is effectively weakened by using email to authenticate a user via password resets.

Cross device, platform support.

Windmill is a native macOS app. Windmill on the iPhone will be a native iOS app. A user should be able to use Windmill from macOS, iOS and possibly the web.

A solution needs to be able to work, potentially, for every Apple platform as well as the web.

Anonymous.

Ideally, I would like to take user accounts a step further and provide this functionality without even asking for an email. An email can be used to identify an individual and is data that can be exploited by a malicious third party should it become compromised.

In Summary

• No password. The server should be able to authenticate a user without the need of a password.
• Cross device/platform support. The user should be able to use Windmill from a different device and/or platform. e.g. Safari on the Mac, Windmill macOS, Windmill iOS.
• Anonymous. User shouldn’t have to enter an email to identify with the service.

Plus, it should be as seamless as possible with very little friction and overhead.

After some research and discussion¹, it looks like CloudKit might be able to check all the boxes.

I will have to investigate further.

See also

• What’s New with CloudKit - WWDC 2016 - Session 226 - iOS, macOS, tvOS, watchOS
• CloudKit Authentication
• CloudKit Web Services Reference

Some database operations require that users sign in using their Apple ID. Your web app will need to handle these authentication errors and present the user with a dialog to sign in. Apple will present the actual sign-in page through a redirect URL so that the user’s credentials remain confidential. If the user chooses to sign in, the response contains a web authentication token that you use in the subpath of subsequent requests. - “CloudKit Web Services Reference, 2016-06-13”