Login & User Management

Many websites and apps require some way of identifying who you are and what you’re permitted to do. This is called “Authentication and Authorisation”.

Mobiconnect has a flexible and extendable User Management module to simplify building this, which integrates with other commonly required features and modules including push notifications, subscriptions, payments, and more.

Authentication can range from very relaxed anonymous accounts, for example linked to website cookies or mobile app device ids – without ever having asked for a name or email address to set up an account, to accounts requiring username/passwords, 2 factor authentication, or Single Sign On (SSO) via a 3rd party authentication provider (like “sign in with Apple/Google).

Registration: Our platform API for registering a user with email being the unique identifier and  APIs for login which will return an Authentication token. This Authentication token can be used to access any private data.

POST https://live.aotomot.com/api/user/registration
Content-Type: "application/json"
Payload:
{
   "email":"testuser@gmail.com",
   "enabled":true,
   "firstName":"Test",
   "lastName":"User",
   "matchingPassword":"Password",
   "password":"Password"
}

Access Levels: Authorisation defines what access and actions a specific authorised user can do, for example the differences between anonymous and registered users, the difference between free users and paid users, or the difference between basic plan subscribers and pro plan subscribers.

Our platform provides 3 access levels

  • Super Admin: Access to platform payments and other account level access

  • Admin: Has the ability to create new content and invite new users

  • User: Generally app users. They have the ability to view the content and limit access to create content.

Send User Invite: Most of these accounts will require some common supporting functionality is addition to just being able to log on. most projects will require some form of account/identity confirmation (like an email or sms with a confirmation link). This can be done in our platform by setting the attribute sendWelcome to true.

Login and User update: Accounts need to store user preferences and profile information. Some critical from a legal perspective (for example privacy related GDPR or CCPA style consent) and some for personalisation use (like preferred display name and pronouns, or push notification tokens for mobile app users who grant push notification permissions).

POST https://live.aotomot.com/api/login
Content-Type: "application/json"
Payload:
{
   "email":"testuser@gmail.com",
   "password":"Password"
}

Response:
{
   "Authorization":"Bearer XYZ",
   "firstName":"Super",
   "termsAccepted":false,
   "roles":[
      "ROLE_SUPER_ADMIN"
   ],
   "tokenExpiry":1604965973146,
   "userId":118415,
   "changePassword":false
}

Use the Bearer token to update your profile or for any other authenticated apis.

Password Recovery: You’ll also need some form of password recovery (a forgot password email or an admin webpage where customer service can reset a password or account email address after suitable over the phone identification). For free trial or paid subscriptions there’ll need to be an automated expiry date, along with some logic about what happens before or after the expiry (free trial accounts might get downgraded to the free plan after 30 days, paid accounts might get send subscription renewals 30 days before expiry).

Below api sends a forgot password email to the registered email.

POST https://live.mobiddiction.com/api/user/resetPassword?email=test@gmail.com

There are significant privacy implications around a lot of user account data, and laws in various jurisdictions pertaining to it like the Australian Privacy Act, Europe’s GDPR, and California’s CCPA for example. These laws typically set restrictions on what data you are allowed to collect without explicit consent, rules around an individual being about to request a copy of all their personal data you hold and mechanisms to allow correction of incorrect data, and reporting responsibilities and penalties in the case of a data breach. This requires a well engineered and  secure user management system, with strong encryption of data both at rest and on the move. It requires strong access controls for administrative users to limit access to personal information, and an audit trail for administrative users with permission to access other user’s personal information. There needs to be mechanisms to export user data for a specific user (either by the user themselves, or by a suitably authorised admin user, or both), a mechanism to update incorrect data, and a secure mechanism to delete all user data (including suitable protection for archived database backups to not inadvertently restore deleted PII during disaster recover).