Authentication describes any of the processes by which an application confirms the truth of a user’s identity. Applications authenticate using a wide variety of protocols, from the standard passwords and single sign-on solutions to signature matching, RFID tags, fingerprint scanning, and more. Authentication is important to your application because in order to both secure your data and allow user access, you need to know who those users are. This could simply include profile data that your users provide, the contents of the database they’re accessing to read or edit, or it could be the backend architecture that you use to administer your systems.
Keep in mind: Authorization is NOT a part of authentication. Authentication is all about verifying a user’s identity, whereas authorization is how permissions are associated with, and verified for, a user. (We talk about authorization all across our blog, but this is a great place to start.)
At the end of the day, you need to know that your users are who they say they are. That’s authentication.
Applications authenticate by comparing user-provided, trustworthy, verifiable credentials, to credentials already on file in their database of authorized users. (Psst… Stormpath provides hosted user databases as well as some awesome APIs and SDKs to access the data stored in Stormpath) If the credentials match up, the user is authenticated, and authorized access is granted based on their defined set of permissions.
There are a variety of authentication methods, based on the type of credentials being presented. Each has its own benefits, restrictions, and use cases. Let’s take a look at the primary methods.
Passwords sometimes get a bad rap, but they remain the most widely used method of authentication. There are newer methods out there (from token authentication to API keys and ever-evolving multi-factor protocols we’ll discuss below), so why do developers stick with passwords? Two reasons:
- Nothing even comes close to passwords for usability and ease of deployment, both for the devs building user management and for the users logging in.
- Passwords can provide the level of security needed for most applications if basic protocols are properly implemented on both the client and server-sides.
The majority of security breaches are not the result of a determined attacker exploiting an obscure vulnerability. More often, malicious or otherwise ungranted access stems from these types of simple mistakes and oversights. One of the most common oversights is in password security protocols. The best user management systems hash all password data and require users set “strong” passwords that include a blend of numbers, letters, cases, and symbols.
One of the biggest problems is that many web applications are storing passwords in plain text, and/or authenticating over unencrypted HTTP.
- Along with setting ‘strong’ password requirements for users, you also need to mind how you’re securing those secure passwords. We recommend you:
- Hash passwords with strong one-way algorithms.
- Add “salt” to your password hashing process. A salt adds randomly generated bits of data that result in a unique password hash when added to plain text input. By salting your hashes, you can be sure that even when your application receives identical passwords from multiple users, each one is hashed with a very different output.
- Add work-factor to your password hashing. Work-factor adds additional computational complexity, increasing the time it takes to brute-force a password. This added time is only milliseconds (so it never impacts the end user) but it can exponentially increase the time it will take an attacker to crack multiple passwords.
- Encrypt your password hashes. Always use a private key stored in a separate location. Rotate keys to ensure they’re never reused.
- Frequently and automatically update your password encryption. This is where we typically see password security fall apart. Although an encryption algorithm may be the bleeding edge of security today, 18 months from now it will likely be compromised. Stay on top of the latest in password hashing and cryptographic best practices, and prioritize implementation of upgrades to your security measures.
Token authentication is a more modern approach, designed to solve problems that can’t be solved by session IDs stored server-side. Token authentication increases the scalability of your application and can lower your server load, streamline permission management, and provide better support for distributed or cloud-based microservices.
Access and Refresh tokens are the most commonly used, and most relevant to our authentication discussion. In a nutshell: When a user first authenticates into your application they are given both tokens. The Access token is set to expire after a brief period (you control this duration, “short” is simply a best practice) and once expired the Refresh token instructs your application to generate a new Access token for that user. Refresh tokens have a set expiration, allowing for unlimited use up until that expiration point is reached.
Stormpath can be used to generate, manage, check, and revoke both Access and Refresh tokens.
API keys function as a traceable tool for authentication that is never exposed in the UI. An API key is a machine-generated, password alternative that applications can send to gain access to your API. They can also grant system access to multiple devices. These keys increase API security (especially in comparison to the other primary machine-to-machine authentication method of username/password pairs) in a variety of ways:
- Usernames are difficult to revoke. API keys are easier because they’re not connected to a user’s identity.
- API keys are randomly generated, much longer than the standard username, and never contain words that could be found in a dictionary. This eliminates many of the most common avenues of attack.
- A leaked API key is still keeping users protected because it contains no identifying information.
Pro tip: API key security is critical to the security of your application, so please don’t store your key (and secret) someplace easily accessible (like, your email inbox, or a source file that could end up checked in to a git repo). As a best practice, we encourage you utilize environment variables or a file readable only by the application.
Multi-factor authentication is one of the hottest topics for application developers looking at building user management. A ‘factor’ in authentication simply means a supporting piece of evidence (aka a ‘credential’) that provides reasonable assurance that you are who you say you are. Therefore, multi-factor authentication simply means that two or more independent credentials are required for access.
One of the most common second factors is Google Authenticator, which can be attached to almost any application. If Google Authenticator is attached to an application you need to access, you’ll be prompted to enter a code along with or immediately after your password. This code is delivered either through the Google Authenticator app for iOS and Android or through a simple SMS message.
A second factor of authentication obviously improves your data security, by applying more stringent access control. Using the Google Authenticator example, a malicious agent would need both a user’s password and physical access to their mobile device to gain entry. This is possession-based authentication which is only one type of additional factor you can authenticate against. Let’s explore each type:
The knowledge factor, somewhat obviously, uses something your users will know. This is usually a username/password pair, but it could also be a PIN code or the answer to a secret question. You and the user both know the information being requested. Thus, your application can authenticate them.
Possession-based authentication adds a layer of complexity, in that the user is required to present a specific, owned credential. These credentials come in two types, connected and disconnected, indicating their state in reference to the machine upon which the user is attempting to authenticate.
We’ve talked about Google Authenticator as an example of possession-based authentication already, but there are a variety of others. The battle.net authenticator pictured is an example of a connected resource being used to log in to battle.net in a mobile browser on the same device. (For the Horde!)
Inherence factors are physically connected to the user, and typically biometric. Two great examples are the iOS Touch ID system and Coursera’s Honor Code keystroke analyzer.
When you set out to “build authentication” you’re really going to “build user management,” so what are the functions that probably need to be included alongside secure authentication and authorization? Well, generally:
The registration flow is the foundation of any user management system. Self-registration allows potential users to create their own accounts, including login and password details, without assistance or intervention from your Ops or Support teams. Self-registration protocols can be customized to allow for a variety of data capture based on the needs of your organization and your users.
The self-registration process isn’t a set-it-and-forget-it system either. By keeping an eye on engagement levels, conversion rates, and volume of falsified profile data you can optimize your system to reduce friction, increase conversion, and create a positive user experience. Connecting to social networks and optimizing your registration process for mobile customers are other important elements that can be overlooked.
What happens once a new user has completed the registration process? It’s time to send them a verification email! Adding this automated verification step to your registration flow has become a common practice, utilized to ensure these awesome new users you’ve gained are actual humans with working email addresses through which you can continue to communicate. This data is invaluable to database integrity and continued marketing efforts on behalf of your brand.
There aren’t many guarantees in life, but we can guarantee one thing: Your users will forget their passwords. Few elements are more critical to a robust user management system than automated protocols that allow your users to reset their own password, without relying on your help desk. Here’s why:
According to a survey by Norton, 25% of users forget three or more passwords per month. This isn’t shocking when you consider the average person has to regularly remember 19 or more passwords (per the UK’s Daily Mail). The Daily Mail also asserts that forgotten passwords have incited extreme frustration including “crying, screaming, and banging head on desk.”
But wait, there’s more: US media conglomerate Cox Communications has reported that a whopping 20% of its help desk tickets are for password-related issues! (And that’s WITH automated protocols in place!)
So, what do you need to do?
It’s easy, integrate these future requests into your self-registration flow. Gather any credentials you need to verify a user’s identity as part of their initial profile creation. The universal best practice after the “Forgot Password” protocol is triggered is to offer a one-time-use link to a secure webpage from which users can easily re-authenticate and register a new password.
Today’s users have been conditioned by social media to expect a certain level of access to, and control over, their profile data, especially if your web page or application includes community features. Users who are given a greater level of control over the data they share are likely to share more data, and by keeping their own profile up-to-date they increase the overall value and viability of your database.
Pro tip: Don’t neglect to secure this priceless profile information. Consult your local rules and statutes along for protocols that may be relevant to your application (Hello HIPAA!)
Now, let’s get back to authentication. Within the realms of mobile and API development, you can approach authentication in a variety of ways:
As we’ve now seen, customer-facing applications—whether they are aimed at consumers or business users—require a core set of features related to user management and authentication. Applications need to accommodate different levels of access depending on the user. Many engineering leaders strongly believe that homegrown solutions are the way to go, and others remain unaware of third-party solutions like Stormpath.
Most developers can handle core workflows like account creation, login, and password reset, but more advanced features like roles, permissions, single sign-on support, customer data partitioning, token authentication, multi-factor authentication, social login, and LDAP/Active Directory integration, require considerably greater effort (Which makes sense… they’re considerably more complex!). Developers often underestimate the difficulty of building a sophisticated and secure user management, as well as the need for various on-team specialize skills, which causes deadlines to slip and tech debt to grow.
Developers love Stormpath for its advanced, developer-centric service, and also because it makes their lives easier: they can implement Stormpath in minutes. The CTO can rest easy knowing user data and workflows are handled the right way, while users get a seamless, secure experience across applications.
The benefits of user management with Stormpath include:
- Faster speed to market for application development and launch
- Lower cost of application development and maintenance
- Freedom for your development teams to focus on core application features
- Maximum scalability and reliability
- Reduced risk through advanced security measures that safeguard your user’s data
Check out these resources to learn more:
Or, get started right now! Our API can provide you with an instant user database and robust authentication service, in just 15 minutes.