I've got an existing customer base. A customer has appointments. Currently they cannot access or change their appointments without contacting me directly.

I want to offer them a way to access and change their upcoming appointments, with as little hassle as possible (more effort for the customer means less chance they'll use it, and less profit).

My thought is this: Generate a UUID (as "securely random" as possible), and send them an SMS with instructions for installing an app (Android/iOS) and a associated app URL (app://UUID).

When opening the app with this URL it stores the UUID and uses this to make requests through the app to my web service with HTTPS which then fetches their appointments and potentially changes their appointments (this is the only "write" operation).

Since the app won't be available through a regular web browser I'm thinking that supplying the UUID in an app-URL will keep people from "leaving" their URL everywhere in random browsers, they will only have to use the URL once, and I control that all web service requests are done through the app on HTTPS so that the UUID isn't spilled that way.

While I'm thinking of making this UUID "last forever", I will be adding an option for customers to report their ID as lost and requesting a new ID (invalidating the old).

Given this scheme I'm thinking that:

  • Losing your phone means losing your identity (stored in app)

  • Forwarding/losing the SMS/URL means losing your identity (should not be required more than for the initial opening of the app to save identity, but I'm not expecting most people to bother to delete it even if told to)

  • Weak if UUID can be guessed

What pitfalls and security scenarios have I not thought of? Keep in mind that ease of use for customers is important (preferably not filling out anything/much), and while the information is concidered private it isn't very high value.

Comments on using UN/PW:

Since the customer base exists I need to know what customer has what login. I'm thinking that either they'd have to create it themselves in office (which I'd like to avoid to have as little input as possible), or give them some generated UN/PW which they can use (but then again I'm distributing it), or they create it online and somehow supply enough information to identify themselves and connect.

In general I'd like some scheme where the starting point is they can identify without any fuss given some information which I then know is them. I'm open to suggestions as I may be hoping for too much from very little information.

  • 1
    Why not just use an ordinary webpage with an ordinary username and password login? Sounds more practical from a customer perspective to me, since I don't have to install any untrusted software on my phone, and it works even when my phone is out of battery.
    – Anders
    Jun 21, 2016 at 11:08
  • @Anders the app would be published so it wouldn't be untrusted in that way, if that is what you were thinking. I've edited my post with some info on my thought process. I may be missing something simple, and I'm open to input. I see you reasoning on website for availability, but I'm thinking that if I go website the UUID-approach is clearly too weak as the URLs would be spread far and wide (input in browser every time they want access) and I can't control that they always access the URL with HTTPS. I'd have to go UN/PW, but then the user effort goes up (registration+login vs installing)... Jun 21, 2016 at 12:28
  • I agree that for a website you should not just rely on a unique random URL for authentication. You would need proper login.
    – Anders
    Jun 21, 2016 at 12:38

1 Answer 1


The primary risk is later exposure of the link if the original message is leaked.

A similar strategy of using a unique token is pretty standard for forgotten password resets or pregenerated accounts on websites, with the following caveats:

  • the token is not guessable (a securely generated UUID should be fine here)
  • the uuid/link is one (successful) use only
  • the uuid/link expires after some amount of time (the exact duration is tradeoff between user convenience and potential exposure)

See https://www.troyhunt.com/everything-you-ever-wanted-to-know/ for more details of password reset strategies.

For your approach, once the app is downloaded you would then need to generate a second key for future access and store it locally. It would mean that you need to re-issue the link with a new UUID ocassionally if a user gets a new phone or forgot to use it the first time.

Rather than an app, I'd suggest that you do a website with un/pw and then just precreate accounts and send out signup links with a UUID to each user (i.e they set UN/PW on first access). That way you can have one (hopefully easy to remember) domain and website that is easy to access. It also means that the signup links cannot be reused later and can be expired.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .