Skip to content

Instantly share code, notes, and snippets.

@kurtzilla

kurtzilla/LoginProject.md

Last active August 30, 2017 21:31
Show Gist options
  • Save kurtzilla/033006a4917265bade805d206aca6238 to your computer and use it in GitHub Desktop.
Save kurtzilla/033006a4917265bade805d206aca6238 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
LoginProject.md

Logging In

Motivation
An email address will be the singularity that the Accounts table will be founded upon. An account is the starting point for any identity. An account may be entered into from multiple login providers (username/pass, facebook, google, github, etc). An account will act as the entry point for a grouping of customers/users/characters. After logging in, a user will be given the option to select a user-entity or a default user-entity may be automatically selected. Single-user systems will be a commonplace structure. It may be easiest to think of an account in terms of a single billing source that may contain multiple user-entities.

The proposed schema can be represented in either a SQL or NoSql database. I have only included a bare minimum of fields and expect this to grow as requirements are identified. Login ERD

Flow scenarios and Rules

For purposes of resetting a password, the user must have either initially registered with a local (email/pass) strategy or after using a social provider strategy, have added a password to their account after initial creation via a profile mgmt page. The existence of a password will be the only way to unlock the ability to receive a password reset email.

TODO DISCUSS should a user request a password reset, is it confusing for a user, who has no password set, to not receive an email? Should we cater to the user who thought they were using a local strategy, but actually had used a social strategy (perhaps sending a notification of their latest login provider)?

I would like the login providers to be interchangeable at any time for any user, but there needs to be an understanding of the following scenarios. My thought is that it is very possible that after a length of time, the user may forget how they initially registered.

  1. If a user initially signs up with a social provider, there would be no local password

    • clicking on a forgot password link would not send a reset email (existing password req'd)
    • they would be allowed to add in a password via profile mgmt which would unlock the reset password email mechanism
    • there would still be options to login via other social providers

  2. If a user initially signs up with a user/pass (local) strategy

    • reset password email flow is enabled due to the existence of a password
    • the user could also use a social provider for the login

  3. Password Rules

    • Reset password would never reveal the old password - a new password is required
    • cannot use any of last 3 passwords (as an option)
    • allow for simple password complexity types - include an option for regex
      • complexity is only necessary when validating at time of registration or resetting/creating a new password

TODO

  • multifactor implementation

Inspirations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment