Calah Vargas

Calah Vargas is the Associate Manager of Product Led Growth, focusing on nonprofits, startups, and partnerships. She works on product marketing and customer marketing initiatives. Outside work, you can find her cooking, trying new restaurants, and traveling with friends and family.

Associate Manager, PLG

Upgrading made easy: from in-house authentication to modern login flows, flexible user profiles, and the convenience and security of passkey

Imagine you’re working on a monolithic application that includes a home-grown authentication system. Over the years, the authentication function has received upgrades here and there to improve security and to stay reasonably up-to-date in a changing world.

Sooner or later — perhaps triggered by considering different growth paths and how best to make use of developer time — you start to recognize that your in-house Identity stack is a limiting factor:

* Integrating with partners and other technology components requires custom work
* Maintenance obligations are distracting from work on your core app
* Meeting regulatory requirements for privacy is an ongoing challenge 
* Providing different access privileges to different types of end users is becoming more complicated than ever anticipated
* With every breach headline, you’re reminded of the constant need to strengthen security

Shopper Approved found themselves in a similar situation — in 2017, the company’s ambitions were outgrowing the home-grown Customer Identity capabilities of their monolithic PHP app.

With that realization, the search was for a third-party authentication solution.

# Why Shopper Approved chose Auth0 by Okta 

Since its launch in 2010, [Shopper Approved](https://www.shopperapproved.com/) has helped over 20,000 eCommerce brands — from mom-and-pop shops to global enterprises — generate more online trust, visibility, and conversions.

> “We knew we wanted to replace our login and authentication mechanism, and we needed a solution that would ‘tango’ with our [Laravel](https://laravel.com/) front-end templating engine,” Christopher Budge, Shopper Approved’s CTO recalled, “but we didn't know which direction we wanted to go in.”

<include src="QuoteCard" body="The Self-Service pricing was really attractive to us. The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While searching online for ideas and options, Budge came across Auth0 — and, in particular, the Self-Service plans.

> “The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application.”

The Self-Service option gave Budge and the wider team plenty of time to perform due diligence. “_We looked for a long time before ultimately deciding upon Auth0,_” he shared. “_The more I dug into it, the better it looked._”

The ability to explore the solution in a hands-on manner, without a commitment, helped the team to make an informed choice. Budge explained that:

<include src="QuoteCard" body="I got together with our technical lead and programming contractor, and they started playing with it — and then they said, 'Yeah, we think this is going to work." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While every organization’s Identity journey is unique, here’s how Shopper Approved implemented Auth0.

## Migrating Users from the Legacy System to Auth0	

No matter how much preparation is done, a migration is always a nervy thing. As it turns out, those nerves were unnecessary — Shopper Approved’s migration from their legacy, home-grown authentication system to Auth0 went off without a hitch.

Budge recalled, “_We weren't sure how well our system would adapt to having its old authentication system ripped out and something new put in its place, but the migration actually exceeded expectations. Within 24 hours, we were able to ingest our entire user database into Auth0 and have them set up as users able to log in._”

However, migrating users was simply the foundation for modernizing the experience for Shopper Approved’s customers, with Budge adding, “_The universal login allows for such a smooth application login and flow. And our marketing team has really appreciated the customization and branding options that allow us to deliver a better customer experience._”

### Letting quickstarts guide the way

One of the first things Budge’s team did was explore Auth0’s step-by-step [quickstart guides](https://auth0.com/docs/quickstarts) to get a feel for the overall migration process.

“The quickstart guides were dead easy. Plus, between your host documentation and the notes in GitHub, it’s really, really easy as a developer to figure out ‘where am I and where do I need to go?’” and ‘What’s next?’”

![quickstarts](https://images.ctfassets.net/23aumh6u8s0i/58lZcrqemW0dCDEIrlLxef/fd17a831afcbbe647abd73d3420e9d95/01-migration.png)

### Leveraging SDKs

SDKs reduce the developer effort required to implement specific use cases, and Budge’s team found exactly what they needed among Auth0’s 40+ SDK libraries.

“Your SDKs are written really well, and your APIs are documented really well. So, code-wise, it’s extremely easy to interact with the platform — you can get going and don’t really have to think hard about it.”

![SDKs](https://images.ctfassets.net/23aumh6u8s0i/1cSZQDXlQ1VDHD7RFG71vu/6922a4a4409f3bab6453b7b48f12541e/02-migration.png)

## Building User Profiles

User data can come from many sources, including your own databases as well as social, legal, and enterprise identity providers. Some examples include Google, Facebook, Active Directory, and SAML.

In Shopper Approved’s case, there was an added complication — practically every user profile that had ever been created in their system still existed, and collectively, many of these profiles had inconsistent and incomplete data. But, perhaps counterintuitively, the upgrade actually presented an opportunity to clean up the user database. Budge’s migration script identified existing user records that were poorly formatted, allowing the team to quickly correct any issues — ultimately improving the overall structure of the company’s user data and laying a strong foundation for efficient scalability.

“The way your user profiles are set up — they’re just really easy to understand, manipulate, and customize. The data structure was easy to map to what we had and what we needed.” Maybe even more importantly, Budge recalled that “It just worked. When we were playing around with it, we saw that it does exactly what [your documentation](https://auth0.com/docs/manage-users/user-accounts/user-profiles) says it does.”

![User Profiles](https://images.ctfassets.net/23aumh6u8s0i/3EfvAVkkj9Ornz9JcTH5CJ/1783bd310eb0cd0722dbbe754aa606c4/03-migration.png)

## Innovating With Identity: Exploring Passkeys

The Identity domain is always evolving, with new specifications, standards, and [regulatory requirements](https://auth0.com/security) frequently appearing.

Unsurprisingly, one of the reasons why Budge was so eager to introduce a leading off-the-shelf solution was that it would allow the company to keep pace with these changes — while at the same time allowing the team to apply their finite resources on their core value proposition. In short, he knew that choosing Auth0 meant that Shopper Approved’s CIAM needs would be met today, tomorrow, and as far into the future as he could imagine.

Like many CTOs, Budge had closely been following [passkeys](https://learnpasskeys.io/) — FIDO credentials that are discoverable by browsers or housed within native applications to enable — and was excited by their potential to provide [a highly secure and very convenient user authentication experience](https://auth0.com/blog/webauthn-and-passkeys-for-developers/).

> “I’ve been watching passkeys for a long time, and — literally the day I got [the announcement that they were available](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/) — I jumped right in. We really enjoyed rolling them out early to our organization, and we’ve had zero issues. And it’s great that we didn’t have to build passkey support ourselves!”
> _Christopher Budge_

![Passkeys](https://images.ctfassets.net/23aumh6u8s0i/3qOGVNCBexcnp5LqxkAcNB/7a0c5eaa7bdb2cd37987795f7a504712/passkeys.png)

## Enjoying Ongoing Value

Budge’s hopes for lower support and maintenance obligations have come to fruition. “We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken.”

Similarly, the upgraded security is evident. 

> “We've had many security researchers and penetration testers try to break in. Every time they run smack-dab into Auth0.”

<include src="QuoteCard" body="We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

### Get started in minutes — for free — with no humans (other than yourself) required!

We’ve always tried to make things less complex for developers, which is why [our Self-Service plans](https://auth0.com/pricing) allow you to create a trial account with nothing more than an email address. During your 22-day trial period, you can create a simple app, configure its look and behavior, and explore the Auth0 solution in detail — giving you plenty of time to really get your hands dirty.

![Get started](https://images.ctfassets.net/23aumh6u8s0i/3s3e2u6XsF3BitzYgE3TpY/1097a71343e41a488444684c12c2c248/identity_journey.png)

Plus, anyone using our products can take advantage of resources including [quickstarts](https://auth0.com/docs/quickstarts), [40+ SDKs](https://auth0.com/docs/libraries), [detailed guides](https://developer.auth0.com/resources/guides/web-app/nextjs/saas-basic-authentication), and [extensive (but easy-to-follow) documentation](https://auth0.com/docs/articles) to help get started and implement a strong Customer Identity function.

In fact, with only a few lines of code, you can have Auth0 integrated into any app, written in any language, and in any framework.

[Try for free](https://auth0.com/signup?utm_source=whitepaper&utm_medium=auth0&utm_campaign=whyauth0) and see for yourself.

A Customer Identity Migration Journey

kaycie-east

As PR Manager, Kaycie supports public relations and global communications efforts for Auth0 in the AMER region. When not promoting the Auth0 brand, Kaycie can be found hiking, traveling, or searching for the next best bite to eat.

PR Manager, AMER Region

Kaycie East

New feature removes the need for passwords and offers unique progressive enrollment features, paving the way for the ultimate user experience.

**BELLEVUE, Wash. – June 15, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the launch of [Auth0 WebAuthn Passwordless](https://auth0.com/passwordless), an authentication feature that enables end-users to seamlessly log in with a biometric identifier — such as facial recognition or a fingerprint — as a convenient and secure alternative to a traditional password. Removing the need for long, complex passwords, Auth0 WebAuthn Passwordless provides a frictionless experience for end-users while reducing the significant password management burden for companies. 

<include src="WebAuthnMeCTA" group="B"/>

Today’s abundance of applications and systems have never had more access points, leaving organizations and their end-users vulnerable to attacks. A reliance on passwords as a primary means of authentication, combined with users’ tendency to re-use passwords across applications, presents a number of security, user experience, and cost issues. According to a [2021 Data Breach Investigations Report by Verizon](https://www.verizon.com/business/resources/reports/dbir/), compromised passwords are responsible for 84% of breaches. Passwordless authentication mitigates these challenges and offers increased security and trust for applications, devices, and services providers; faster and smoother login experiences for their end-users; and cost savings by eliminating the need for password management support. 

“Despite ongoing guidance around proper password creation and repeated warnings against password reuse, consumers crave convenience and continue to use the easiest and most convenient path for application access,” said Shiv Ramji, Chief Product Officer at Auth0. “A passwordless future is largely being driven by two primary forces — security and convenience. Companies want to secure the vulnerabilities that come with passwords, and they also want to offer their users a better digital experience. Auth0 WebAuthn Passwordless is a modern option for organizations looking to attract and retain users.”

With Auth0 WebAuthn Passwordless, users can authenticate with Web Authentication-powered (WebAuthn) biometrics, the official web standard for passwordless authentication as published by [W3C and used by FIDO](https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/), for first-factor authentication. This form of authentication eliminates security weaknesses based on password reuse since passwords are not required. Additionally, Auth0 WebAuthn Passwordless is an ideal option for companies looking to build and provide an authentication experience supporting conversion and retention of users who want more choice and less friction in their login experience.

Auth0 WebAuthn Passwordless eliminates the need for users to enter username and password credentials and enables simpler login with a biometric identifier such as facial recognition like Apple Face ID or a fingerprint scan on a mobile device or laptop. The biometric data remains stored on the device, alleviating privacy and security concerns for end-users. The feature also allows end-users to progressively enroll devices one at a time, as they use them, without needing a centralized portal, giving them the flexibility of having multiple passwordless authentication options — an advanced, unique capability that maximizes end-user adoption and enables a faster transition from passwords to passwordless, benefiting both end-users and organizations.

More detailed information on Auth0 WebAuthn Passwordless can be found here: [7 Things You Need to Know About Passwordless Authentication](https://auth0.com/resources/whitepapers/passwordless-authentication) (whitepaper) and on [Auth0’s blog](https://auth0.com/blog/freedom-from-passwords-with-auth0-webauthn-passwordless). 

[Auth0, recently acquired by Okta](https://auth0.com/blog/okta-acquisition-announcement/), provides a modern identity platform that helps organizations meet the security, privacy, and convenience needs of their users. Please visit [The Auth0 Identity Platform](https://auth0.com/identity-os) to learn more.


<include src="asides/AboutAuth0" />
### Media Contacts
Global Communications 
Auth0 
[press@auth0.com](mailto:press@auth0.com) 

Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 WebAuthn Passwordless Offers New Levels of Ease and Security for Modern Authentication

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

A preview of our new ebook about OIDC, the de facto standard for handling authentication in the modern world.

**TL;DR:** In August 2019, Auth0 published an ebook called [The OpenID Connect Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) to help developers leverage this modern identity layer to provide an easy and secure authentication mechanism to their users. This ebook covers all the main concepts that you must know to integrate your app with OpenID Connect providers. If you are in a hurry and would like to dive right into the content of the ebook, click the link below to get your free copy.

<include src="ebook-ads/OidcHandbook" />

The rest of this article will summarize the content of the ebook so you can take a glimpse of what you will learn about on the ebook.

<include src="TweetQuote" quoteText="The OpenID Connect Handbook teaches you everything you need to handle end-user authentication securely."/>

## The Contents of the OpenID Connect Handbook

As of October 2019, the handbook covers six main areas related to OpenID Connect. Each area has a chapter of its own that is subdivided into other sections to help you understand OpenID Connect, how this identity layer was born, and how to use it to secure your applications:

1. Introduction
2. OpenID Connect Introduction
3. OpenID Connect in Action
4. OpenID Connect and Traditional Web Applications
5. Traditional Web Apps and the Delegated Authorization Flow
6. OpenID Connect and Single-Page Applications

The following sections will cover each one of these chapters separately, so you can learn what to expect on them. Hopefully, if you are looking to learn about a topic in particular, you will be able to download the free ebook and dive right into it.

## Introduction

The Introduction chapter of this handbook disserts about topics that are not part of OpenID Connect per se, but that are important for you to grasp before you start learning about it. In this chapter, you will learn about the terms Entity and Identity and you will learn about how they are interconnected. There, you will learn that an entity has multiple identities and that people, or other entities, perceive entities through their identities.

![Every entity have multiple identities that others use to perceive them.](https://images.ctfassets.net/23aumh6u8s0i/2nKkQmov8tv3VgxNExyjjp/b0898dc4882fc7104241af91feb63850/entity-identity-concepts)

After that, you will learn about the terms Authentication and Authorization. More specifically, you will learn how these terms are related, how one thing can lead to another, and how they differ. Authentication vs. Authorization is an important topic that causes great confusion, even on members of the IT workforce around the world.

![Authentication and authorization are topics that cause confusion and that are often used interchangeably by mistake.](https://images.ctfassets.net/23aumh6u8s0i/olPsGOC0fQLSBHxkP4Ujp/384681fbed0a5587f1646e7becb0e378/end-user-authentication)

## OpenID Connect Introduction

After learning about the conceptual topics that preamble this ebook, you will start learning about OpenID Connect. This chapter will begin by guiding you through a ten-thousand-foot overview of how an OpenID Connect authentication transaction works. After that, you will briefly read about other authentication mechanisms and how the IT community went from simple usernames and passwords, to Kerberos, to SAML, and OpenID Connect.

![A brief illustration that shows how SAML works.](https://images.ctfassets.net/23aumh6u8s0i/2l4JlPlLlYCqLPfYCZILmj/bbbb9ea320109fa04ee89c2344fb666d/an-illustration-of-how-saml-works)

The chapter will then move into more details about the OpenID Connect specification and will talk about OAuth 2.0, the underlying technology that the identity layer builds on top. In the end, you will read about some OpenID Connect use cases so you can learn when this technology can be helpful.

## OpenID Connect in Action

The next chapter on the ebook, called OpenID Connect in Action, will start to teach you the inner workings of the OpenID Connect specification. There, you will set up an OpenID Connect provider that you will use through the hands-on exercises, and you will prepare your local environment to run the samples that you will learn about. As the goal of the ebook is to show, step by step, how you can secure your applications with OpenID Connect, the exercises will use the most popular programming language in the world (i.e., JavaScript) to lower the barrier.

![Creating an OpenID Connect provider to use throughout the handbook exercises](https://images.ctfassets.net/23aumh6u8s0i/3XeqIvJa9337fCbQyqQAtM/a133df9d47c5e2f1f5dcc93a7d56d0a7/creating-an-openid-connect-provider)

## OpenID Connect and Traditional Web Applications

Having created your OpenID Connect provider and prepared your local development environment, the next chapter will be the first hands-on activity of the ebook. However, besides being a hands-on activity, the chapter will also teach about important topics such as [the authentication flows](https://auth0.com/docs/flows). You will find a few other useful resources on the internet that inform you about OpenID Connect. The main problem with them, which this ebook aims at solving, is that they introduce a lot of theory before giving you anything you can use.

In this ebook, you will see that you will learn about the abstract parts of OpenID Connect on the fly. That is, instead of investing time to learn about all the different authentication flows that OpenID Connect supports and about all the abstract terms involved in them, this ebook will briefly teach you about them, then it will use these concepts right away.

For example, after you read about what an authentication flow is, you will jump right into using one. Besides that, you will read and learn how to use Discovery Endpoints, an prominent piece of OpenID Connect providers, right away. You will also learn about other important topics in this chapter like the Authentication Callback and user profiles.

## Traditional Web Apps and the Delegated Authorization Flow

After you learn about how OpenID Connect securely promotes end-user authentication, the ebook will continue by teaching you about one of the most prominent scenarios where OpenID Connect and OAuth 2.0 are used: on delegated authorization. The chapter will show you all you need to know about this kind of authorization but, basically speaking, delegate authorization is when you let an app act on your behalf. The example that you will read about everywhere, including in this ebook, is when a third-party application wants to help you schedule tweets. In this scenario, this third-party app will have to ask you for permission to tweet on your behalf on the date and time you configure it. When this app issues a request to Twitter to create the tweet, the app will be acting on your behalf.

![Delegated authorization sample where the app wants to tweet on behalf of the user.](https://images.ctfassets.net/23aumh6u8s0i/6JNFmYekPxdetLv4IP2E7H/7613f4ab8889cda76b97605430526401/delegated-authorization)

## OpenID Connect and Single-Page Applications

The last chapter of the handbook (so far, because we will publish more chapters soon) talks about how to secure Single-Page Applications with OpenID Connect. In the modern internet, most popular apps (and those that are not popular also) are using this approach to promote a better user experience to their customers. Therefore, it wouldn't make sense to have an ebook that does not cover the most popular paradigm when it comes to web development.

In this chapter, you will learn about terms like PKCE (Proof of Key for Code Exchange) while integrating a single-page app with your OpenID Connect provider. Besides that, you will also take a look at a popular alternative called the Implicit Grant and why this approach is not encouraged anymore. As SPAs are usually hosted as static files in a cloud provider, you will also use delegated authorization in this chapter. That is, you will have an API that contains data that belong to users and you will make the SPA ask users permission to consume this API on their behalf.

![Single-Page Apps can securely authenticate end-users with OpenID Connect providers by using PKCE.](https://images.ctfassets.net/23aumh6u8s0i/338DB6V09xi9ufeUEy5nzS/b76da928c2481cf90500ef5492094b6e/spa-and-the-pkce-flow)

## Conclusion

As you can see, if you are interested in learning about OpenID Connect and how this technology can help you secure your applications, you came to the right place. In this ebook, you will learn everything you need to make your apps behave as OpenID Connect clients and how to make them consume APIs on their users behalf. Another interesting thing that you will learn in this handbook is about how popular and official SDKs (like the ones supported by Auth0) can help you be more efficient. That is, the ebook will show you everything you need to code in any application to make it integrate with an OpenID Connect provider, but it will also show you a more straightforward way to achieve your goals. With this, you will have both the tools to debug any misconfiguration and to be as focused as possible on what makes your app unique.

If you need help with any matter related to the OpenID Connect Handbook or to identity, authentication, and authorization, let us know in the comment box below.

<include src="TweetQuote" quoteText="OpenID Connect is an easy and powerful tool you can use to secure your applications."/>

<include src="asides/AboutAuth0" />

The OpenID Connect Handbook

olususi-oluyemi

Oluyemi is a tech enthusiast with a background in Telecommunication Engineering. He ventured into programming with a keen interest in solving day-to-day problems encountered by users. He has since directed his problem-solving skills towards building software for both the web and mobile platforms. As a full-stack software engineer with a passion for sharing knowledge, Oluyemi has published many technical articles and content on several blogs worldwide. As s tech-savvy person, his hobbies include trying out new programming languages and frameworks.

Software Engineer / Technical Content Creator

Olususi Oluyemi

Learn how to create modern and secure applications with two mainstream technologies: React and Symfony. Also, secure the frontend/backend of the app by adding authentication.

Developing Modern Apps with Symfony and React

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Learn how to leave usernames and passwords behind with social and passwordless authentication.



**TL;DR:** Learn how to leave usernames and passwords behind with social and [passwordless authentication](https://auth0.com/passwordless) with Auth0's [Identity and Access Management solution](https://auth0.com/user-management).

---

After months and months of developing your new app, it's finally ready to launch. You feel confident that you've got all the features and functionality you need. But with all of that work, you've let your login fall by the wayside. A simple a username and a password will do the trick, right?

Wrong. In the age of modern authentication, you need to go beyond usernames and passwords to protect customer information and give users frictionless logins that they trust. Embracing login as identity management rather than as a simple gate to access is imperative.

Here's what you need to know.

## Implement Easy Login Options for Users

Between the growing number of passwords users have to remember and the multiple steps needed to reset a forgotten password, users are demanding easier login options.

Making it as easy as possible for them to visit your site means they'll [stick around longer](https://blog.fullstory.com/the-best-products-will-win-7ec43a93186#.onq2r8lau). By removing the friction usually associated with activating a new account or simply signing in, you'll reduce your abandon rate.

Using modern authentication practices, [Auth0](https://auth0.com) has built a system that can be quickly integrated into your site to give users the easy access they've been asking for. [Social login](https://auth0.com/learn/social-login/) and [passwordless authentication](https://auth0.com/passwordless) are two options that provide freedom from usernames and passwords.

With social login, users confirm their identity by using a third party site that has already vetted their authenticity.

![Social authentication](https://images.ctfassets.net/23aumh6u8s0i/1OFiTKkAcgA3DECIVuNOKL/05681fd900210170f791822e35124c2c/social-login)
[Source](http://tradablebits.com/social-login)

It takes less time for users to set up an account and profile since their personal information is automatically filtered into the new site. Almost everyone has at least one social media profile, so it's perfect for users who want one fewer password.

With passwordless authentication, users are sent timed codes via SMS or email to access their account.

They only need to have immediate access to their phone or email to quickly access their account. Again, this saves them time and effort while their account remains accessible and secure.

## Provide Enterprises with Centralized Oversight

Enterprise customers need to maintain control of their many employees' login access. They want a secure, central place to manage user identity, and often want the benefits of [Single Sign-On (SSO)](https://auth0.com/learn/how-to-implement-single-sign-on/) as well.

They also need you to be able to comply with whatever their given enterprise connection is, whether that's AD, LDAP, ADFS, SAML, Ping, or Google Apps. These connections can be difficult and time-consuming to implement, and that's _without_ looking at getting everything up to specific industry standards.

If identity isn't part of your core business, scaling up to support enterprise authentication only serves to take attention away from what you do best.

In this case, enterprise federation is the best approach for enterprises. Scaling up to an enterprise platform is quick and easy to set up with an [IAM (Identity and Access Management) solution like Auth0](https://auth0.com). Once up and running, it's easy to choose who will manage and monitor access based on identity, add and remove users, manage login requirements, and run any necessary analytics.

From the Auth0 dashboard, go to Connections > Enterprise to view available connections or to create new ones.

![Auth0 enterprise connections dashboard](https://images.ctfassets.net/23aumh6u8s0i/7EuJvrcgzvbIjrFpZCtWfj/af08c4fa5429eb1ea34cdb5e5fee87b1/auth0-enterprise)

With this platform, enterprises can monitor user accounts from one central dashboard.

## Make Security a Top Priority

Both users and enterprises want secure logins. Users expect a certain level of protection from the sites they access and enterprises want to secure their internal data. Unfortunately, simply relying on the username and password approach might not get you very far.

Just look at companies like [LinkedIn](http://fortune.com/2016/05/18/linkedin-data-breach-email-password/) and [Yahoo](https://auth0.com/blog/yahoo-confirms-data-breach-of-half-a-billion-user-accounts/). They are some of the largest companies out there, but were still susceptible to data breaches. User data was easily accessed by hackers due to inadequate security parameters.

That's why modern authentication is so important. Instead of building a system from scratch, you can access ready-made platforms that provide encryption, brute force protection, constant monitoring for attacks, and the ability to promptly notify users.

With Auth0's approach to modern authentication, we take away the need for in-house custom builds that don't meet compliance standards.

For example, as part of a suite of [security features](https://auth0.com/security), Auth0 offers anomaly detection to fight against brute force attacks. If suspicious activity is detected, users are notified immediately. All of Auth0's automated blocking features are built with resilience in mind.

Another important security feature is credential and user login monitoring.

![Auth0 log tracking](https://images.ctfassets.net/23aumh6u8s0i/6rogIjpng0uNPfQHJ8rILE/16474d490bddf002418e9d26660af093/auth0-logs)

From the dashboard, you can easily track logs and be confident in knowing that security compliance and regulations are automatically taken into consideration and deployed across your site.

## Moving Forward with Modern Authentication

Now more than ever, authentication involves more than just supporting usernames and passwords. Modern authentication puts the emphasis on creating and protecting identity for users, whether they're an individual using an app or enterprise employees.

Usernames and passwords aren't going to disappear, but authentication is complex, and it's only going to get harder to manage.

There's no need to struggle to keep up using in-house solutions when you can rely on experts that live and breathe identity management. Your IAM solution can support everything you want to offer your users, while letting you focus on the product that got users to sign up in the first place.

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can improve your product's security with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication).

[We offer a generous **free tier**](https://auth0.com/pricing) so you can get started with modern authentication.


Go Beyond Username/Password with Modern Authentication

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing. Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Auth0 makes it simple and easy to add authentication and authorization to any app. By localizing our marketing website, we hope to make it easier for developers and companies to implement and see the benefits of modern identity management.

**BELLEVUE, WA - Konnichiwa!** We are pleased to announce that the Auth0 marketing website has been localized for the Japanese market. Auth0 makes it simple and easy to add authentication and authorization to any app with its powerful API and SDK’s for most languages and frameworks. 

Auth0 has always championed and embraced open-source software and we hope that by localizing our vast knowledge of security best practices we can make it easier for developers and companies, regardless of industry, location, or *language*, to make the web a safer and more secure place for everyone.

![Auth0 Japan](https://images.ctfassets.net/23aumh6u8s0i/7iYJ6F6NCYo6rYEaMi42b7/a7e02e6cc8b91a632cbd34e9a3a3486a/auth0-jp)

If you are visiting the Auth0 website from a Japanese locale, you will automatically see the website presented in Japanese. If you wish to view the Japanese version of the website but are outside of the Japanese locale, you can view it by visiting [https://auth0.com/jp](https://auth0.com/jp).

<include src="asides/AboutAuth0" />

The Auth0 Marketing Website Has Been Localized for the Japanese Market

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Former Auth0 Employee

Ado Kukic

Legacy username and password authentication is not enough. Learn about modern authentication and how Auth0 can help you implement it for your clients.

<div class="alert alert-info alert-icon">
 
 Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.
</div>

---

**TL;DR** Whether you're a small consultancy working with a few clients or have been around for some time, the authentication needs of your customers are likely similar. Legacy authentication via username and password is not enough. Your customers are demanding multifactor authentication, single sign-on, and greater security. Building these features in-house is complex, but with Auth0 it doesn't have to be.

---

Being a consultant or systems integrator means wearing many hats. To be successful you must be knowledgeable about various technologies, methodologies, and best practices as well as know how to put them all together to meet your clients' goals. The technological landscape is constantly changing and keeping up can be a challenge.

When it comes to authentication and security, usernames and passwords are simply not enough. Modern authentication focuses on:

* [Managing user identity](https://auth0.com/docs/user-profile)
* [Top tier security and availability](https://auth0.com/security)
* [Multiple authentication strategies](https://auth0.com/docs/identityproviders)
* [Multifactor authentication](https://auth0.com/docs/multifactor-authentication)
* [Single sign-on](https://auth0.com/docs/sso)
* [Passwordless authentication](https://auth0.com/passwordless)
* and more...

*Keeping up* with modern authentication and security best practices would be challenging on its own, but *implementing* it alone would require a herculean level of effort. At Auth0, we can provide your consulting organization with the tools and support to implement modern authentication for your clients.

<include src="TweetQuote" quoteText="Building modern authentication is difficult, but with Auth0 it doesn't have to be."/>

## Auth0 for Systems Integrators

Whether you're a small consultancy working with a few clients or have been around for some time, the authentication requirements from your customers are likely similar. Auth0 can provide a comprehensive authentication platform that your clients will love. Your organization will benefit from being able to provide modern authentication in record time. Let's take a look at some of the features.

### Modern Authentication

Authentication starts at the login screen. The [Lock](https://auth0.com/lock) widget provides a modern login widget that supports traditional username and password, social, and enterprise authentication. This cross-platform widget can be implemented in as little as ten lines of code but supports various branding and configuration options to truly make it your own. If you prefer to implement your own unique UI instead, our RESTful API provides the same functionality so you can have full control.

### Enterprise Federation and Single Sign-On

Enterprises require governance over their users and will demand [single sign-on](https://auth0.com/docs/sso). Implementing and maintaining integrations with the various [enterprise federation providers](https://auth0.com/docs/identityproviders#enterprise) would be a very challenging task. Auth0 has built integrations with leading platforms like [Active Directory](https://auth0.com/docs/connections/enterprise/active-directory), [Ping](https://auth0.com/docs/protocols/saml/identity-providers/ping7), [ADFS](https://auth0.com/docs/connections/enterprise/adfs), [LDAP](https://auth0.com/docs/connections/enterprise/active-directory), [SAML](https://auth0.com/docs/protocols/saml/saml-configuration) and more so all you have to do is provide the configuration details and we'll take care of the rest.

### Social Connections

Allowing users to log in with their existing social accounts can increase conversion rates and improve the user experience. Auth0 supports [over thirty social connection](https://auth0.com/docs/identityproviders) providers including [Facebook](https://facebook.com), [LinkedIn](https://linkedin.com), [Twitter](https://twitter.com), and [Google](https://google.com). Auth0 can additionally be integrated into any provider that supports [OAuth 2](https://auth0.com/docs/extensions/custom-social-extensions).

### Traditional Authentication with Enhanced Security Features

If [username and password](https://auth0.com/docs/connections/database) authentication is a requirement, Auth0 has you covered. Traditional **username and password** or **email and password** authentication is provided with enhanced security features. [**Multifactor authentication**](https://auth0.com/docs/multifactor-authentication) greatly enhances the security of this type of authentication and can be added with the flip of a switch. Anomaly detection, which prevents brute force attacks, as well as [breached password detection](https://auth0.com/breached-passwords) go a step further to provide greater security for your users.

### Passwordless Authentication

[Passwordless authentication](https://auth0.com/passwordless) allows your users to log in without having to enter or remember a password. Instead, when the user wants to log in, they provide their email address or phone number and receive a one time passcode that they use to authenticate instead. Auth0 provides various options for passwordless authentication including SMS and Email. 

## Auth0 Partners Program

Auth0 solves authentication, identity, and security challenges for organizations by providing a complete platform for managing modern identity. Our goal is to make identity simple and easy, so you can spend less time worrying about authentication and focus on your clients and their needs. [Contact us](https://auth0.com/partners#become-a-partner) today to learn more about becoming an [Auth0 Technology Partner](https://auth0.com/partners).

Modern Authentication for Your Clients Made Easy

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges. Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Conventional authentication is challenging for today's web applications. Learn about the reasons and how to use JSON Web Tokens (JWT) for modern authentication.

---

**TL;DR:** Traditional session-based authentication with cookies presents difficulties, especially for modern web applications. We can instead use JSON Web Tokens (JWT), which make our apps stateless. Migrating a legacy app over to JWT authentication can be done piece by piece, and if we need to, we can use cookies to handle JWTs. To see how this is done, take a look at the [repo](https://github.com/auth0/cookie-jwt-auth) for this tutorial.

---
Authentication for web applications has historically been fairly straightforward and followed a common pattern, but this has been changing significantly in recent years. There are several reasons for these changes, and the prominent ones are related to the way in which modern applications are built and distributed. In this article, we'll see how things have changed and also some ways we can adapt legacy applications to modern day practices.

## Traditional Web Applications

In a general sense, traditional websites and applications typically implement user authentication using **sessions** and **cookies**. When users log in to a site, their username and password are matched against database entries. If the login is successful, the server saves the user's authentication state in memory and sends a cookie back in the response that contains some data, which in most cases includes the user's ID. Browsers will save the cookie for the domain from which it came and then automatically send it back when subsequent requests are made. For example, if a cookie is saved with a domain of auth0.com, it will be sent back on any future request to auth0.com as long as it is valid. This works great for traditional web apps.

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/2E0gj0N91SqR18iJcYX0pS/2843825e62cc48a85c287ffad235efc9/legacy-app-auth-1)

Even though we've labeled the process described above as being "traditional", it should be noted that *most* of the web still operates this way. While this approach is still perfectly valid for a lot of use cases, we're going to explore some of the reasons why relying on it has become challenging for modern web applications.

## Authentication Challenges for Modern Web Apps

Modern web applications present a few challenges for authentication that are difficult to solve using conventional methods. The reasons for this have to do with how applications are crafted and the environment in which applications reside.

### 1. Apps are distributed across many servers

Many of today's applications aren't deployed the same way they were in the past. It is now very common--and often necessary--for apps to be distributed across many servers so that up-time is increased and latency issues are mitigated. With this comes the side effect that, when a user accesses an application, it is no longer guaranteed that they are always accessing the same server.

Since traditional authentication relies on the server to keep the user's authentication state in memory, things break down when the app is accessed from different servers. The user might be logged in on one server but not on the others that the application is distributed across.

We can get around this by using methods like [**sticky sessions**](http://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions). A sticky session will essentially route the user to the server instance from which they logged in so that the authentication state can be presevered. This type of workaround will do the job, but as we'll see, stateful servers in general don't play that well with modern applications.

### 2. Apps use APIs for data

A common pattern for modern applications, especially single-page apps, is to retrieve and consume JSON data from a [RESTful API](http://www.restapitutorial.com/). Serving data from an API has several distinct advantages, one of them being the ability for data to be used in more than just one application. For example, an organization might start with the intent to build an internally facing application, but may soon realize that some of its functionality could be used in a public-facing app. Down the road, the organization might also decide that some of its data should be accessible by other application developers to build third-party apps with. This can all be made possible with an API.

Using APIs in this fashion is great, but things can become challenging when it comes to authentication. The traditional approach of using sessions and cookies for the user's identity doesn't work so well in these cases because their use introduces **state** to the application. One of the tenets of a RESTful API is that it should be **stateless**, meaning that, when a request is made, a response within certain parameters can always be anticipated without side effects. A user's authentication state introduces such a side effect, which breaks this principle. Keeping the API stateless and therefore without side effect means that maintainability and debugging are made much easier.

<include src="TweetQuote" quoteText="Keeping the API stateless means that maintainability and debugging are made much easier."/>

Another challenge here is that it is quite common for an API to be served from one server and for the actual application to consume it from another. To make this happen, we need to enable [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS). Since cookies can only be used for the domain from which they originated, they aren't much help for APIs on different domains than the application.

### 3. Apps rely on downstream services

Another common pattern seen with modern web applications is that they often rely on downstream services. For example, a call to the main application server might make a request to a downstream server before the original request is resolved. The issue here is that cookies don't "flow" easily to the downstream servers and can't tell those servers about the user's authentication state. Since each server has its own scheme for cookies, there is a lot of resistance to flow, and connecting to them is difficult.

## A Modern Alternative: The JSON Web Token (JWT)

To combat the issues detailed above, we can take a token-based approach by using JSON Web Tokens (JWTs) for authentication. A JWT contains three parts:

**1. Header**

The header tells us about the algorithm and token type. It is Base64URL encoded.

**2. Payload**

The payload contains any arbitrary information in the form of claims that we as developers find useful for our applications. The user's ID must be sent as a `sub` claim, but we can also send other useful information, such as the username, email, and more. The payload is also Base64URL encoded.

**3. Signature**

The signature is used to verify the authenticity of the JWT. There are several different algorithms that can be used for the signature. Some algorithms implement a shared secret (HMAC), and others use public-private key secrets (RSA).

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/1sS3oSviChEPzlXMAYHHLQ/b58c9c25c3ecb38505a5e77e5965e981/legacy-app-auth-5)

From the user's perspective, logging in to an application that uses JWTs looks much like traditional authentication. Users enter their credentials as usual, but instead of the server creating a session and returning a cookie, it will respond with a JSON object that contains a JWT. The JWT then needs to be saved locally, which is normally done with local storage. However, as we'll see in the next section, it is possible to save the JWT in a cookie.

The JWT must be sent to the server to access protected routes, and it is typically sent as an `Authorization` header. The scheme used for this header is `Bearer`, so the full header looks like this:

```js
Authorization: Bearer <token>
```

Middleware on the protected API routes will check for a valid JWT, and if there is one, it will let the request through and return the data being requested. Since the user's information is contained within the JWT itself, there is no need to look the user up in a database, so there is less latency in the application.

It should be reiterated that the user's state is never saved in memory on the server, meaning that the user isn't "logged in" in the conventional sense. However, a valid JWT gives the user the keys to access data each time a request is made, and in this way, a stateless authentication mechanism is in place.

![](https://images.ctfassets.net/23aumh6u8s0i/1f37fJAPR7UgfFW8oYYeKs/5f00a4413b04510ad6bd6801f04a2fed/legacy-app-auth-2)

Using a JWT for authentication helps to solve the challenges noted above. We can fully rely on data APIs that are stateless and even make requests to downstream services. Since JWT is a specification [implemented nearly everywhere](http://jwt.io), connecting to downstream services built on a stack other than our own is easy. It also doesn't matter which domain is serving our API, nor does it matter which specific server a request goes to if the app is deployed across many.


## Bridging the Gap: Using JWTs in Cookies

Modernizing legacy applications by implementing token-based authentication can lead to many gains. If it isn't feasible for an organization to totally throw away cookies, there are still ways to make token authentication viable. Let's take a look at how this can be done with NodeJS and the **express-jwt** package.

### Step 1: Set Up a Back End

To follow along, you can download Auth0's [NodeJS seed project](https://auth0.com/docs/node-auth0/master/create-package?path=examples/nodejs-api&filePath=&type=server) from the [docs page](https://auth0.com/docs/quickstart/backend/nodejs/). Even though we're using an Auth0 seed project here, doing cookie-based authentication in this way will work with any service.

### Step 2: Install Cookie Parser

Once the dependencies for the seed project are installed by following the [installation steps](https://github.com/auth0/node-auth0/tree/master/examples/nodejs-api), we'll need to add one more package: **cookie-parser**. This package will allow us to read JWTs from cookies that are sent to the server.

```bash
npm install cookie-parser --save
```

With **cookie-parser** installed, we now need to require and use it in `server.js`.

```js
// server.js

...

var cookieParser = require('cookie-parser');

...

app.configure(function() {

 app.use(cookieParser());

 ...

});
```

### Step 3: Save the JWT as a Cookie

We'll need to retrieve a JWT for a user and save it locally as a cookie. If you're using Auth0 for this tutorial, you can find out more about retrieving JWTs for users in your Auth0 account by reading the [API documentation](https://auth0.com/docs/api/v2). We'll use jQuery in this example to make the AJAX calls easy.

Lets make a call to Auth0 to get a JWT.

```js
// app.js

$('.btn-login').click(function() {
 $.ajax({
 type: 'POST',
 url: 'https://{your-auth0-account}.auth0.com/oauth/ro',
 data: {
 client_id: '{your-client-id}',
 username: document.querySelector('#username').value,
 password: document.querySelector('#password').value,
 grant_type: 'password',
 scope: 'openid',
 connection:'Username-Password-Authentication'
 },
 success: function(data) {
 getJwtCookie(data.id_token);
 },
 error: function(error) {
 console.log('There was an error: ' + error)
 }

 });
});
```

In the success handler, we're calling a function called `getJwtCookie` and passing in the token that was received from Auth0. We need to create an endpoint on our application server that can validate the JWT that was received from Auth0 and send it back to us as a cookie, and we can do that in the `getJwtCookie` function.

```js
// app.js

function getJwtCookie(token) {
 $.ajax({
 type: 'POST',
 url: 'http://localhost:3001/secured/authorize-cookie',
 data: {
 token: token
 },
 headers: {
 'Authorization' : 'Bearer ' + token
 },
 success: function() {
 console.log('Cookie received!');
 },
 error: function() {
 console.log('Problem with cookie');
 }
 });
}

```
Next, lets set up the `authorize-cookie` endpoint to handle this call.

```js
// server.js

app.post('/secured/authorize-cookie', authenticate, function(req, res) {
 res.cookie('id_token', req.body.token, {
 expires: new Date(Date.now() + 36000),
 httpOnly: true
 });
 res.send(200, { message: 'Cookie set!' });
});
```

In the next step, we'll set up our **express-jwt** middleware, but we're making use of it already in the `authorize-cookie` route by passing it in as the second argument, `authenticate`. The middleware secures the endpoint and a valid JWT will be needed to access it. If the JWT is valid, we simply reflect it back as a cookie and set the `httpOnly` flag to `true` so that the cookie can only be accessed by the server. This route accomplishes the steps of validating the JWT that was received from Auth0, as well as the step of setting a cookie with the JWT.

**Note:** We are using an `Authorization` header to accomplish our cookie JWT in this example. This is the only place we would need to make a request using this header--the rest of the application will handle JWTs with cookies.

### Step 4: Set Up Middleware to Check for the Cookie
Normally, the **express-jwt** middleware will look for the presence of a header and retrieve the JWT from there. However, we can also create a custom function to define how the token should be retrieved.

```js
// server.js

...

var authenticate = jwt({
 secret: new Buffer(process.env.AUTH0_CLIENT_SECRET, 'base64'),
 audience: process.env.AUTH0_CLIENT_ID,
 // Custom function to retrieve the JWT
 // We first look for the JWT in a header and if it isn't there,
 // we look for it in a cookie
 getToken: function fromHeaderOrCookie(req) {
 if(req.headers.authorization && req.headers.authorization.split(' ')[0] === 'Bearer') {
 return req.headers.authorization.split(' ')[1];
 } else if(req.cookies && req.cookies.id_token) {
 return req.cookies.id_token;
 }
 return null;
 }
});

...
```

We've added the `getToken` function as an option on the object that is passed into `jwt`. Our implementation here says that we want to first look for the presence of a JWT as an `Authorization` header, and if there isn't anything there, we want to check whether there is a cookie with the name `id_token`.

### Step 5: Test the Secured Route

With the `id_token` cookie in place, we can see that requests to the `secured/ping` endpoint go through just fine.

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/4j5ZnQitsiwgVbLtwupT71/104a61fb2584f11a192c1fb36e476f92/legacy-app-auth-3)

<include src="asides/Jwt" />

## Wrapping Up

As we've seen, modern web applications are crafted and deployed in ways that make conventional user authentication challenging. JWT authentication is an excellent way to get around these challenges and allows us to keep our application server stateless. If we need to lean on old practices, such as using cookies, we can do so and still support JWT authentication with a little tweaking on the server.

"modern authentication"