1

I would like to implement a password-less login for a mobile application (discussion board/social media).

  • The data contains non-critical social media content (usernames, posts, replies, photos).
  • The goal is to keep people's identity anonymous. A user's identity would be a hashed email address, preventing people from signing up more than once.
  • The login should be easy and therefore password-less. It should happen via a "local" link (e.g. myapp://login?token=abc)
  • The app's email server would not store emails that were sent out.
  • All communication to the server in the backend is encrypted via HTTPS (TLS), email traffic is not.

The login flow would be the following:

  1. To request a login link, mobile app POSTs the user's email address to a server endpoint /sendLoginEmail.
  2. The server will store the hashed email and a temporary, random, short-lived token (both the email and the token expire after 5 minutes) and send a link containing the token to the email address the user sent.
  3. To sign in, the user opens the link with the temporary token. This will open the app and pass the token from the URL to the app.
  4. The app will use the token to retrieve a long-lived (1 month) JWT token from the server via an endpoint /getJWT. The server will immediately delete the temporary token, but keep the email hash to be the user's identifier.
  5. The app can now use the JWT to perform any actions on behalf of the user.
  6. Should the JWT be close to expiration, the app will try to obtain a new token. If the user hasn't been logging in for a month, he will have to follow the process again.

I would love to hear some feedback on this approach.

One issue that I see is that it may be slightly more insecure than a "password-forgotten" functionality: There is no secret factor that only the user could know (a security question, for example). An attacker could try to initiate the login flow himself and fetch the temporary token somewhere along the way.

Would you see this as an acceptable risk?

  • Why aren’t you using one of the many oauth systems? It achieves practically the same result with even less data about user available to you (no need to request email address at all). Most email is gmail, so you can just use google oauth and not try reinvent the wheel. – Andrew Morozko Jul 12 at 6:42
  • @Andrew Morozko "... Most email is gmail ...". I don't have any statistics but I sincerely hope that is incorrect. – user10216038 Jul 12 at 15:49
  • I don't want to rely on any third party services. – mitchkman Jul 12 at 15:55
  • 1
    Especially not Google. – mitchkman Jul 12 at 15:57
  • 2
    @mitchkman Well, you already do this by using email. But whatever, as you wish. Otherwise the architecture seems reasonable to me. – Andrew Morozko Jul 14 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.