Understanding Auth Terminology with Examples Part Two

In our first post, we defined some common auth terminology to help clarify the jargon used when discussing ‘auth’. There’s no shortage of terminology, so here’s part two of commonly used words.

Magic Link/Passwordless

Passwordless login is just that—a login without a password. Because most users choose common passwords or repeat them across multiple sites, traditional username and password credentials aren’t as secure as they could be. Instead with passwordless log in, the user will be sent a one-time link usually via email or phone, which is called a magic link.

Magic links won’t make a bunny appear out of a hat but they do provide an easy way for your user to log in. After receiving their magic link, users simply have to click a button or copy the url into their browser and they will be instantly in the app. Not only are dynamic, one-time urls harder to brute-force attack, magic links and passwordless login create a faster and more frictionless experience for your users.

Roles and Role Based Access Control (RBAC)

RBAC is the method where users are assigned different roles and their access to the product is determined by their role. At PropelAuth, our default roles are Owner, Admin, and Member and are hierarchal within each organization. Roles can be called different names, some roles can be hierarchal while others are flat, and some companies may need just two roles and others will need more.

The primary benefit of RBAC is it helps organize your users. For example, it wouldn’t make sense for every employee in a company to have complete access and control over a CMS. Instead, with RBAC, the team leads could be made Owners, so that they can monitor the entire company performance and add/delete employees as needed. On the other side, individual salespeople only need to check their own progress and would only need Member-level permissions. In the middle, regional managers could be listed as Admins as they wouldn’t need as much access as Owners, but would be need to track the salespeople they’re responsible for.

Multi-factor Authentication/ Two-factor Authentication (MFA/2FA)

MFA requires users to verify their identity beyond just supplying their username and password. Most commonly this is through 2FA, where you must supply two different factors: something you know (e.g. password), something you have (e.g. token), or something you are (e.g. fingerprint). One example is entering your account credentials then entering a unique, one-time login code from an authenticator app on your phone.

Both of these methods increase the application’s security as a potential attacker would have to have access to both a user’s login credentials and the user’s secondary factor, like phone or email, in order to falsify entrance.

Identity Provider (IdP) and Service Provider (SP)

IdPs are a service that store and manage digital identities, usually for a workforce. Similar to a directory, IdPs allow administrators to organize their employees and related applications within one point-of-truth system. IdPs enable users to use single sign on to access different service providers. Common IdPs include Google, Okta, Rippling, and JumpCloud.

SPs are the website or application users want to access, such as Salesforce, Google Sheets, or Linear. While SAML is the authentication method that enables SPs to use IdPs as the reference point to authenticate which users have permission to use the app. The benefits of SAML and a deep dive into the role of IdPs and SPs can be found here.

Brute Force Protection

A brute force attack is when a nefarious user attempts to log into an account by submitting different password guesses over and over. Eventually, if they’re allowed enough tries and the true password is weak, the attacker will gain access. Brute force protection is one of the security measures your auth should have to protect your users and sensitive data.

PropelAuth goes a step above standard brute force protection by also preventing dictionary attacks, where common words and phrases are entered repeated across accounts—like ‘password’.

Tenant/Multi-Tenant

In the software world, a tenant is a collection of users that use a product together. This could be as few as a single user or as many as a large enterprise. A single tenant application gets their own dedicated application, database, and infrastructure. In multi-tenant applications, multiple tenants share the underlying resources. An important factor in both cases is to ensure tenants only have access to their own data and not other tenants’. While this is de factor in a single tenant application, multi-tenant applications use authentication and authorization to separate users into their tenants.

JSON Web Token (JWT)

After a user logs in, it can be helpful to issue them a string signifying that they are logged in. Commonly, you’ll find two strategies when creating this string:

• Create a random set of characters and save that to a database. On each request we check the database for this random set of characters.
• Create a JWT which contains tamper-proof metadata that we can verify without hitting the database.

The primary benefit of a JWT is that you can verify that it was not modified without hitting a database. This can help alleviate load on the database, especially as you scale.