Best new user approach for mobile app W/O new user email confirm

Authentication & Security
1

I have a DF instance as a simple write-only front-end to a DB which will be accessed by a mobile app. Each user of the mobile app has a distinct UUID generated when the app is first begun.

I’ve been looking at the different ways to handle “new users”. Because the app is self-contained, I don’t want to add the extra step of email-confirmation:

  1. Allow open registration, each login name is the UUID from the app, create a password on the fly. Save login information locally to the app.

  2. Have each user of the app login through a single user account and differentiate the data on the backend only by the app-generated UUID. Turn off open registration.

Cons to #1: Open registration means any script or bot could technically register new users with junk data.

Const to #2: Possible per-user limits to # of concurrent logins. Would there be a problem if 400 users at any one time were logged into the same account, each depositing data under separate UUIDs?

2

+1 on this. I am also interested to know the said approach.

3

This should be no issue, as long as you’re serving the API up in an environment that could handle 400 concurrent users anyway (i.e., there should be nothing special about them all instantiating separate sessions with the same user credentials).

Beyond that, either of your proposed options sounds workable. Another possibility would be to script user creation, and register users via calling that script with whatever logic you need to implement contained in the script. Do post back once you’ve settled on and implemented a strategy!