1Vitor de Sousa_Auth0

As Regional Vice President, Vitor de Sousa supports Okta and Auth0's German customers in achieving their Identity and Access Management goals. With more than 20 years of experience in the consumer goods industry, as well as in technology and software sales, he develops strategically smart and creative solutions for the interplay of identity authentication, customer experience, and data protection.

Regional Vice President, Enterprise Sales - Germany

Vitor de Sousa

The pandemic accelerated digitization initiatives, a robust CIAM solution can assist in an iterative migration to the cloud

In the DACH region, trust is everything, and one of the first places you can build consumer trust is your login experience. German consumers say their main frustrations with signing up to a new app or online service are having to fill in long login or sign-up forms (42%) and entering private information (38%), followed by having to create a password that has to meet certain requirements (33%), and a new ID and password for every app or online service (31%). These statistics come from a [global research study](https://info.auth0.com/erwartungen-und-realitat.html) conducted by Auth0 and YouGov, including more than 2,000 consumers and 200 IT/marketing decision-makers in Germany.

One of the challenges organizations encounter when looking to launch new services or feature sets is the fact that many of these features are cloud-based while existing services that could benefit from integration are often legacy and hosted on-premises. Finding an [Identity as a Service (IDaaS)](https://auth0.com/blog/what-is-idaas/) provider who can link those legacy systems and modern cloud-first platforms is an important step towards creating a future-proof service. However, many organizations in the DACH region are still building their own identity solutions. Or they’re misusing tools designed for managing employee identities for customer-facing needs. Both of these scenarios can introduce additional pain points when it comes to joining legacy and modern systems.

## Digitization Projects Are Resource Intensive

IT departments have spent the better part of the last 18 months establishing work-from-home protocols, migrating critical systems to the cloud for better access, and ensuring that everyone’s data stays safe and secure throughout the transition. Despite the acceleration in these digitization projects brought on by the COVID-19 pandemic, many of these systems have to remain housed on legacy on-prem servers due to a lack of alternatives. Bridging the gap between these and the convenient cloud-based tools your customers need access to is a large undertaking, especially for IT teams that are already stretched thin supporting ongoing internal needs.

Your IT and development teams support the organization’s goals by creating and maintaining the best web applications for your customers and by keeping your infrastructure running smoothly. That way, everyone, both inside and outside of the company, has the best experience possible. Partnering with an IDaaS provider like Auth0 will free those teams to continue focusing on their primary goals by taking the task of user authentication off their hands — and putting it in the hands of identity experts. This ensures your users get the CX they’ve come to expect while you maintain control over your data and privacy.

## Legacy Workforce Identity Solutions Are Not Built To Face External Threats

The workforce [Identity and Access Management (IAM)](https://auth0.com/blog/what-is-iam/) tool you’re using today may look like an attractive option for your customer-facing needs. There are several problems with this idea, starting with the simple fact that IAM solutions are not focused on user experience (UX). Their priority is security, keeping your company’s intellectual property safe and secure from bad actors. 

The threats facing customer applications can be vastly different in type and scale. Workforce IAM verifies employee identity in order to approve access to just the tools they need to do their job effectively, from primarily company-owned devices. [Customer Identity and Access Management (CIAM)](https://auth0.com/blog/what-is-ciam/#:~:text=Auth0%20Docs&text=Customer%20Identity%20and%20Access%20Management,%2C%20customer%20experience%2C%20and%20analytics.) solutions, on the other hand, need to integrate protection against brute force attacks, password spraying attacks, along with other outside attack vectors. And they need to do that while maintaining identity verification across potentially millions of end-user devices and networks. Additional hurdles exist as well; for example, many IAM tools are on-prem only and unable to protect your new cloud-first infrastructure. 

## Growing Demand From Consumers for a Low-Friction Customer Experience

The acceleration and growth of online tools have increased consumer expectations for a safe and simple identity experience. They’re no longer willing to wait for slow pages to load or to endure lengthy and complex account creation flows. Your customers demand-responsive, intuitive design, or they’ll take their business elsewhere. In fact, 78% of German consumers say they have [abandoned an app or online service](https://info.auth0.com/erwartungen-und-realitat.html) due to an arduous login experience.

Addressing the systemic issues that need attention to keep up with this demand will put additional stress on your internal teams, pulling their attention away from those core goals we discussed above. You don’t need to sacrifice your user experience in order to create a user-friendly and trusted authentication experience. Auth0 provides a secure platform with a variety of cloud deployment options, including [private cloud deployments on Microsoft Azure](https://auth0.com/blog/auth0-on-microsoft-azure-as-a-private-cloud-deployment-option/) or AWS infrastructure, and public cloud options using AWS facilities in multiple regions, including Frankfurt. Built by and for development teams, Auth0 is easily customizable to create exactly the low-friction experience your customers demand without sacrificing security and extensibility.

## Auth0 Lets You Find the Right Mix of Security, Privacy, and CX

We’ve discussed three pain points organizations in the DACH region are likely to encounter when looking to deploy a new identity and authentication solution across both legacy and cloud-based systems. The Auth0 Identity Platform has a robust feature set designed to address these challenges and any others you may encounter as you embark on your own identity project.

### Extensibility allows you to quickly adapt your digitization project

Auth0’s founders wrote the book on identity management at Microsoft while helping development teams remove barriers to building applications in the cloud. The Auth0 Identity Platform is designed with developers in mind, with multiple [extensibility](https://auth0.com/extensibility) points that allow you to configure the exact authentication flows you want.

### Exhaustive integrations mean you can bridge the legacy/cloud gap easily and iteratively

No matter what systems you have housed on-prem or on legacy infrastructure and what you have already migrated to the cloud, our [Application Programming Interfaces (APIs)](https://auth0.com/docs/api) and [Software Development Kit (SDK) libraries](https://auth0.com/docs/libraries) mean, you can use one CIAM solution to bridge the gap. That allows you the flexibility to continue your deployment iteratively, knowing that your customer experience won’t suffer any negative impacts as you migrate more services to the cloud on your own schedule.

We’re able to integrate with most existing cloud-based SaaS services via our APIs and SDKs but can also integrate with your on-premise environments as long as they’re accessible via API or otherwise. We are also up to date with the [General Data Protection Regulation (GDPR)](https://auth0.com/docs/compliance/gdpr) enacted by the European Union in 2018, so we can help and support our customers in meeting their compliance requirements.

Additionally, [Auth0 Marketplace](https://marketplace.auth0.com/) and [Actions](https://auth0.com/actions) provide access to a wide array of out-of-the-box integrations with most line-of-business software and services. That means you can quickly connect your CMS and ERP to your new web app, and your users won’t see any change in their experience as it’s serverless, so there won’t be any interruption to your services.

### No-, low-, and pro-code options for creating a low-friction user experience

Between the pre-configured integrations in [Auth0 Marketplace](https://marketplace.auth0.com/) and our low-code [Actions](https://auth0.com/actions) capability, your development team can easily customize Auth0 to meet your customers’ expectations for a secure and low-friction authentication experience. For even more control, we still offer pro-code customization, as always, via our JavaScript editor.

The ability to have all your identity needs up and running quickly means your team can focus on serving their primary functions. Your developers can continue delivering top-quality experiences for your customers, and IT support can maintain your internal employees’ work environment, no matter where they’re working from.

## Partnering With Auth0 Ensures a Secure, Customizable CIAM Experience

You can rely on the identity professionals at Auth0 to help:

* focus your development team on innovation
* deliver the identity experience consumers have come to expect
* protect customer data with a deployment option that works for your business

That’s how you deliver an excellent user experience without compromising security or privacy along the way. Read more about our [compliance and certifications](https://auth0.com/docs/compliance), then [reach out to an identity expert](https://auth0.com/contact-us) to continue the conversation about how partnering with Auth0 can help your organization. 




Bridging Legacy Systems and Digital Transformation with CIAM

sambiopic

I'm Director of Developer Relations and a Google Developer Expert for Angular and Web Technologies. I believe anyone who wants to learn to code should be able to learn code and I love teaching. When I'm not coding or writing, you'll find me outside hiking or camping in the beautiful Pacific Northwest.

Director of Developer Relations

Sam Julien

Angular 8 now sends separate bundles to legacy browsers by default.


**TL;DR:** Angular 8 is here! Learn all about one of its coolest new features: differential loading. Differential loading lets you serve up different bundles to different browsers and make your application even faster!

Angular 8 has only been out for about a week at the time I’m writing this, but there’s already been 17,000 “What’s New” articles published. Rather than throw my own take on the pile, I’ll refer you to the [official Angular release announcement](https://blog.angular.io/version-8-of-angular-smaller-bundles-cli-apis-and-alignment-with-the-ecosystem-af0261112a27) but here are the high points:

- No, Ivy isn’t ready yet (it’s an opt-in preview).
- No, [Bazel](https://bazel.build/) isn’t ready yet (it’s an opt-in preview).
- [Builders](https://blog.angular.io/introducing-cli-builders-d012d4489f1b) allow you to extend and customize the CLI. For example, you’re now able to [deploy to Firebase](https://github.com/angular/angularfire2/pull/2046) and other providers from the CLI.
- There’s [improved support for web workers](https://v8.angular.io/guide/web-worker), such as the ability to generate them from the CLI and use them in your application.
- Rather than using the “magic string” syntax specific to Angular to do lazy loading, you’ll be able to use the [standard `import()` syntax](https://next.angular.io/guide/deprecations#loadchildren-string-syntax). You can even perform this automatically for your app with the [`angular-lazy-routes-fix`](https://github.com/phenomnomnominal/angular-lazy-routes-fix) tool.
- The new [unified location service](https://v8.angular.io/guide/upgrade#using-the-unified-angular-location-service) improves migration from the AngularJS `$location` service. 
- The Angular team has created a simplified [Getting Started Guide](https://next.angular.io/getting-started).
- There’s a new [Deprecation Guide](https://v8.angular.io/guide/deprecations) to assist users with updating Angular.
- [Differential loading](https://v8.angular.io/guide/deployment#differential-loading) is turned on in the CLI by default.

In this article, I want to dive into that last one: differential loading. What is that? Why does it matter? What do I need to do about it (if anything)?

<include src="TweetQuote" quoteText="Angular 8 is here! It features differential loading, better support for web workers, and much more."/>

## What is Differential Loading?
Like most buzzwords in tech, the term “differential loading” is completely opaque about what it actually *means*. In a nutshell, differential loading means to send newer, flashier code to newer browsers and stable legacy code to legacy browsers. This generally translates into two things: modern syntax and polyfills. On a newer browser that supports recent syntax changes in JavaScript (such as arrow functions in ES2015 or async functions in ES2017), it’d be great to ship to code as-is with as few polyfills as possible to keep download time low. On legacy browsers, we’ll need both transpiled code and more polyfills to make things work. This way, newer browsers aren’t punished for legacy browsers by having to load a massive bundle, but legacy browsers aren't left in the dust.

Sounds cool, right? How does this work?  Modern browsers have the ability to interpret a `module` type in the `script` HTML tag and to ignore a `nomodule` attribute. It looks like this:

    
    <script src="fancyModernBundle.js" type="module"></script>
    <script src="legacyBundle.js" nomodule></script>
    
    
When a modern browser (like a new version of Chrome) runs across this, it will know to only load `fancyModernBundle`. Likewise, when an older browser sees this, it won’t recognize the `module` type and only load `legacyBundle`.

![Diagram of how differential loading in Angular 8 works](https://images.ctfassets.net/23aumh6u8s0i/23llHk1LLwhZvAU9rFD1aJ/43ae43d1cfa8b4cce88534afa2ae00f2/differential-loading-2)
[Source](https://cdn.auth0.com/blog/blog/ng-conf-2019)


## How You Normally Set Up Differential Loading
You’ve probably surmised by now that, in order to take advantage of differential loading, you’ll need to divide up your JavaScript code based on browser support. “Easy,” you think, “I’ll just plug the transpiled code into the `nomodule` tag and the original into the `module` tag.” Well, it’s not quite that simple. Unfortunately, not all browsers support all the same features of JavaScript.  Beyond that, your users may not use the same browser you do. In fact, if your users are around the world, they may not even use browsers you’ve heard of &mdash; Opera Mini has over [100 million users in Africa](https://blogs.opera.com/news/2016/11/state-of-the-mobile-web-africa-2016/)!

It turns out that splitting up your bundle for differential loading is a combination of art and science. To pull this off, your bundler (like Webpack) and your transpiler or compiler (like Babel or TypeScript) must work together to divide up your code and add the correct polyfills in the right places. Luckily, there’s a configuration tool called [`browserslist`](https://github.com/browserslist/browserslist) that does nearly all of the heavy lifting for you.

Browserslist works with tools like Babel and is essentially a configuration tool that accepts query strings, which it runs against [Can I Use](https://caniuse.com/) data. Tools use Browserslist through either an entry in `package.json`:

```json
// package.json
"browserslist": [
  "last 1 version",
  "> 1%",
  "maintained node versions",
  "not dead"
]
```

Or in a separate config file called `.browserslistrc`:

```text
// .browserslistrc
# Browsers that we support

last 1 version
> 1%
maintained node versions
not dead
```

Both of these formats contain the same query:

- `last one version`: the last version for each browser
- `>1%`: browsers versions selected by global usage statistics
- `maintained node versions`: all Node.js versions, which are [still maintained](https://github.com/nodejs/Release) by Node.js Foundation
- `not dead`: excludes "dead" browsers, which are the same as those from a `last 2 versions` query, but with less than 0.5% in global usage statistics and without official support or updates for 24 months

Browserslist also has a `defaults` query that works for many people. They’ve got [great explanations of the queries on their GitHub repo](https://github.com/browserslist/browserslist#full-list) and there’s even a site called [browserl.ist](https://browserl.ist) that lets you plug in a query and see a visual list of supported browsers.  

![Testing browserslist defaults queries in the browser](https://images.ctfassets.net/23aumh6u8s0i/p8WJI1Fdo0orzJhcc5pSh/a72ff535d93481b8d7cab3a7dd3d7b6d/browserslist)

## Differential Loading in Angular 8
Ordinarily, you’d need to configure your bundler and Babel or TypeScript to use `browserslist` to split up your code into the correct bundles. With version 8 of the Angular CLI, you actually get this set up right out of the gate with nothing for you to do! This is awesome because differential loading saves on average 7-20% in bundle size for Angular applications in modern browsers. In fact, [angular.io](https://angular.io/) saved over 40kB of its initial bundle size for modern browsers when the team enabled differential loading.

Want to check this out for yourself? It’s really easy!

<include src="TweetQuote" quoteText="In Angular 8, differential loading saves on average 7-20% in bundle size in modern browsers!"/>

### Updating to Angular 8
First, make sure you have the latest version of the Angular CLI installed:

```bash
npm install -g @angular/cli
```

If you’d like to try this on an existing project, you can update it to Angular 8 by running:

```bash
ng update @angular/cli @angular/core
```

> Check out the [Angular Update Guide](https://update.angular.io/) if your app requires more heavy lifting to update, like if it’s currently in version 6 or lower.

Otherwise, you can create a new application:

```bash
ng new diff-loading
```

Follow the prompts about routing and styling and then you’re good to go!

### Configuration and building
If you open the new project in your favorite editor, you’ll notice a new file called `browserslist`. It contains the following by default:

```text
// browserslist
> 0.5%
last 2 versions
Firefox ESR
not dead
not IE 9-11 # For IE 9-11 support, remove 'not'.
```

You can adjust this list to match better with your own user demographics.

> **One very important note about this:** See that `not IE 9-11` part? If you need to support those browsers, you can remove the `not`, but it comes at a price. Those versions of Internet Explorer can’t take advantage of differential loading, so it will be disabled.

If you open `tsconfig.json`, you’ll see a particularly big change in the `target` property: it’s set to `es2015` by default instead of `es5`. 

Now that you’ve seen where the configuration lives, build the application with this command:

```bash
ng build --prod
```

After it’s done, open up `dist/index.html` and notice the `script` tags:

    
    <script src=“runtime-es2015.858f8dd898b75fe86926.js” type=“module”></script>
    <script src=“polyfills-es2015.e954256595c973372414.js” type=“module”></script>
    <script src=“runtime-es5.741402d1d47331ce975c.js” nomodule></script>
    <script src=“polyfills-es5.405730e5ac8f727bd7d7.js” nomodule></script>
    <script src=“main-es2015.63808232910db02f6170.js” type=“module”></script>
    <script src=“main-es5.2cc74ace5dd8b3ac2622.js” nomodule></script>
    

See all those `module` and `nomodule` instances? The Angular CLI did all that for you!

### Differential Loading in Angular, in action
Now you just need to see it in action. Install a simple server like `http-server`:

```bash
npm install -g http-server
```

Then, within your project folder, serve up the project inside the `dist` folder:

```bash
http-server dist/diff-loading/
```

Open Chrome or another modern browser and head to the address of the server (on my machine it’s `http://192.168.0.4:8080` but it may be different for you). Open up the network tab of the developer tools and refresh the page. You should see only the scripts that include `es2015` in the name!

![Angular differential loading success in Chrome in dev tools](https://images.ctfassets.net/23aumh6u8s0i/6DlabdkvNyGCaj7E7NH7ZT/d8aefdb68950a3af21681c2b18dab378/diff-loading-chrome2)

### Other settings
One quick note before I end this tutorial. If you change the different configurations, there are four different scenarios you could end up with:

- A single ES5 build (differential loading disabled, `target` is `es5`)
- Single ES5 build with conditional polyfills (differential loading enabled, `target` is `es5`)
- Single ES2015 build (differential loading disabled, `target` is `es2015`)
- Two builds with conditional polyfills (differential loading enabled, `target` is `es2015`)

To read more, check out the [official documentation](https://angular.io/guide/deployment#differential-loading).

## Conclusion
Angular 8 brings lots of great new stuff to Angular, including differential loading. I hope you’ve enjoyed this look into what differential loading is, how it works, and how to use it in Angular 8. See you next time!

<include src="asides/Angular" />


A Guide to Angular 8's Differential Loading

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.<br/><br/> 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

How top teams are updating their legacy systems with more secure and efficient solutions.



You used to pay with cash. Then credit cards. Then EMV cards. Now, we’re moving toward things like [cryptocurrency](https://auth0.com/blog/an-introduction-to-ethereum-and-smart-contracts-part-3/) and [biometric authentication](https://auth0.com/blog/tags/biometric-identity/).

Payments and the technology involved in making them are constantly evolving. For example, payment company Square recently added [_Square Register_](https://techcrunch.com/2017/10/30/square-announces-the-register-a-999-point-of-sale-device-for-larger-businesses/) to its hardware lineup. Unlike most of Square’s other equipment, Square Register targets the needs of larger sellers.

![New Square Register hardware that targets larger sellers](https://images.ctfassets.net/23aumh6u8s0i/3cB517ydiTQ1OrJtW1Xcgp/21b12b0ff377b06d77686c542522fb9f/square-register)

At the same time, Mastercard is [_doing away with signatures_](https://newsroom.mastercard.com/press-releases/signing-off-mastercard-moves-beyond-signatures-worldwide/) on the backs of credit cards, and on receipts themselves, in favor of exploring more advanced technologies for identity verification. 

Even PayPal has jumped on the payment revolution by going beyond ecommerce. PayPal now offers customers the option to use their [_PayPal balances_](https://www.tearsheet.co/payments/how-paypal-is-moving-into-physical-retail) at physical retail shops through Android Pay. 

Needless to say, the [_financial services_](https://auth0.com/financial-services) and payments landscape is ever-changing. And a business that wants to remain competitive within its industry needs to look at [updating its legacy system](https://auth0.com/blog/how-do-i-modernize-my-legacy-system/) (or even ripping and replacing it) in order to be more secure, efficient, and compliant with customers’ financial data.

## What’s Inspiring These Changes?

We live in an age of [seemingly constant innovation and advancement](https://www.teampay.co/insights/how-blockchain-will-change-finance/), so it makes sense that payments are following suit.

But there are a few other factors involved in pushing these advancements in payment technology.

One is the uptick of credit card fraud and, as a result, the increasing consumer concern about their security and protection.

![Advancements and the Future of Payments and Payments Processing in 2019](https://images.ctfassets.net/23aumh6u8s0i/2tbJEM41OF7GvxFNduJbpT/1726b2e1900063ee05eb56c52b9a572f/future-of-payment)

Credit card fraud has steadily been on the rise. In fact, the [_financial industry estimates_](https://www.accenture.com/us-en/insight-banking-future-payments-ten-trends) that we’ll reach $31.3 billion in global credit card losses by the end of 2018. Credit card scammers are getting smarter. Today, these fraudsters are capable of not only [_selling credit card numbers_](https://www.businessinsider.com/credit-card-fraud-scam-what-to-do-2018-8) but also identifying information like zip codes. 

Additionally, new [_payment regulations_](https://home.treasury.gov/sites/default/files/2018-07/A-Financial-System-that-Creates-Economic-Opportunities---Nonbank-Financi....pdf) demand an increasing level of transparency and security. To stay compliant, businesses have no choice but to keep up with the changing technology and rules.

## The Future of Payments: 3 Advancements to Be Aware of in 2019

There’s no shortage of changes happening in the payments space. But trying to stay on top of (or even *ahead* of) all of them is a daunting task.

If you're like most companies, you're primarily focused on what you need to know right now. But to remain competitive, you have to stay ahead of the curve. What will payments look like in the future? Here are three burgeoning areas that you should be aware of as you look at updating your own legacy systems.

### 1. Multi-Factor Authentication Will Gain Even More Importance

As concerns over security continue to grow (for good reason), [multi-factor authentication](https://auth0.com/docs/multifactor-authentication) will be of increasing importance for consumers and businesses. 

Traditionally, you could access various accounts by entering a single identifier (think a username or an email address) and a correct password. 

But multi-factor authentication adds another layer to the identity-verification process by asking you to prove your identity in another way — for example, by entering a code you receive on your cell phone or even scanning a fingerprint.

You can think of it as a second security door. Hackers and thieves who are able to make it through the first will have a much tougher time passing through the second.

Because more and more financial and payment data is linked to our personal accounts (your credit card being stored in your Amazon account is just one example), we’ll see multi-factor authentication become the norm more and more. 

Many regions are actually instituting policies to mandate strong customer authentication—like [_PSD2 in Europe_](https://auth0.com/blog/open-auth-standards-psd2/). 

### 2. Point-of-Sale Analytics Will Become Even More Advanced

While the protection of data is an area of primary focus, so is* leveraging* data.

To make more informed predictions about the future, businesses are hungry for any information about what their customers are purchasing. That means we’ll see [_retail analytics_](https://auth0.com/blog/retail-analytics-past-present-and-future/) continue to expand — with an emphasis on point-of-sale analytics. 

Previously, POS analytics were fairly straightforward — they shared what was purchased, and by whom. But today these analytics are capable of reporting on where the item was stored or where it was shipped from and can provide information about inventory and dead stock and even details about the [_customer's identity_](https://auth0.com/blog/digital-success-through-customer-identity-and-access-management/) and their consumption patterns.

As we move into the future, payments are no longer just a one-time transaction with little to no data attached to them. Instead, this important point of contact will become an informative touchpoint for businesses to learn even more about their consumers. 

### 3. User Experience Will Be Paramount

Convenience and ease of use are main areas of focus for today’s customers. They’re no longer writing out checks or counting out stacks of coins—they want the payment process to be as streamlined as possible.

Just look at something like [_ZAPBuy_](https://www.prnewswire.com/news-releases/omnyway-launches-zapbuy-allowing-shoppers-to-buy-products-from-ads-with-a-snap-300425915.html), which was launched by Omnyway in early 2017. The tool allows users to hold their smartphones over an advertisement on any channel and immediately purchase what’s being promoted to them. 

Consumers have a desire to reduce or eliminate friction in the purchasing process, which is fueling this move toward more [_“invisible” payments_](https://www.tearsheet.co/payments/4-charts-that-show-the-coming-autonomous-payments-wave). Think about Uber as just one of many examples. You don’t think about making a payment when you step foot out of that Toyota Corolla—the transaction happens seamlessly behind the scenes. 

![Uber user interface and simple experience for the future of payments](https://images.ctfassets.net/23aumh6u8s0i/5bRmcm4wRgjkEXsWdYrgJz/24020dd49f3fcabbe8d6c24fcd5b69ab/uber)

When today’s customers see a clunky or cumbersome purchasing process, they immediately head in the other direction. Payments are expected to be fast and easy—and that’s an expectation that will only increase as Generation Z makes up [_40% of consumers_](https://www.accenture.com/t20171012T092426Z__w__/us-en/_acnmedia/PDF-62/Accenture-Driving-the-Future-of-Payments-10-Mega-Trends.pdf#zoom=50) by the year 2020.

## What This Means for You: Updating Legacy Systems in Your Business

Change is here for payments, and it’s going to keep coming.

That means it’s time to start looking at [updating legacy systems](https://auth0.com/blog/how-do-i-modernize-my-legacy-system/) related to payments in your business. While your current systems, tools, and software may work for you right now, they might not have the level of flexibility required to keep up in this ever-evolving industry.

Having the right resources in place will make it much easier to stay on top of—and maybe even ahead of—the constant barrage of changes and advancements in the world of payments. 

Wouldn’t you rather do that than fall behind? We thought so. 

<include src="asides/AboutAuth0" />


The Future of Payments in 2019

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

The risks of legacy authentication and why you should migrate to IAM



Many businesses, especially those that appeared online in the 1990s, invested large amounts of time and money deploying complex identity authorization systems across their business.

A large number of these systems have web access management, or WAM, as their central design metaphor. At one point, WAM was one of the most common ways for large companies to handle identification and resource access inside their businesses.

As time passed, however, these kinds of systems have grown increasingly expensive to maintain, and most are unprepared for the kind of threats and issues that businesses need to worry about today. In other words, legacy WAM solutions leave your business exposed.

<include src="TweetQuote" quoteText="Web access management systems are expensive to maintain and unprepared for the threats of today."/>

## What Is Web Access Management?

Web access management systems are focused on providing security to web-based tools and applications, and they focus on two main identity operations:

* **Authentication**: Ensuring a given user is who they claim to be
* **Authorization**: Ensuring a given user has permission to access a particular web page/area of a web product

First appearing in the 1990s, most WAM products also permitted the use of limited single sign on (SSO)—allowing users to sign in with their credentials on one domain and then use those same credentials to access data on other domains without signing in a second time.

WAM products were generally deployed using one centralized authentication server and as many individual agents as necessary to cover all of a corporation's web servers.

![Web access management](https://images.ctfassets.net/23aumh6u8s0i/4viWMdhEKfHNvATKktZeo6/67741ffba4aff26a6821f85dd6229c18/web-access-management)

In this traditional on-premises setup, requests for access went from users to the agents on individual servers, each of which would call back to an external server to either approve or deny access.

Web access management systems could also be set up using proxy servers (in which all requests would flow through a single proxy server) or tokens (in which users use individual tokens to gain access to the resources they need).

![Proxy server request flow](https://images.ctfassets.net/23aumh6u8s0i/5qY4OYbXcSqgrmxp9k2inR/4fc16ecef828aea7cdfe6649d6d8540a/proxy-server-request-flow)

_How a proxy server works. Requests flow from servers within the library (network) to a proxy server on that local network, and finally out to the external internet._

All of these types of deployments were complicated, expensive (and even more expensive to maintain) and rooted tightly in an “on-premises” model—where the perimeter of your network is limited by the perimeter of your building.

Today, most organizations are moving on and migrating to more integrated identity management (IdM) and identity and access management (IAM) solutions.

## What Is Identity Management (IdM)?

Identity management (IdM) is an umbrella term for all  of the core logic around identity in a corporate environment.That means:

* **Provisioning**: Assigning identities to users
* **Account management**: Maintaining those identities
* **Identity governance**: Assigning them to groups and roles and adjusting permissions as needed

IdM is often used interchangeably with IAM, or identity and access management. IAM, however, is most often used to refer not just to identification but to the whole suite of practices that a corporation needs to manage their users and data, including:

* **Authentication**: Ensuring that a given user is the user they identify as
* **Authorization**: Ensuring the given user has the proper permissions to access a certain piece of data
* **Identity federation**: Ensuring users can use the same identification data to access resources on related domains

In other words, [IAM](https://auth0.com/learn/cloud-identity-access-management/) is the entire set of practices around identity that an organization needs to allow “the right individuals to access the right resources at the right times for the right reasons.”

## The Difference Between Web Access Management and Identity Management

The primary difference between legacy web access management and more modern identity and access management is the comprehensiveness and flexibility of the solutions they offer.

Web access management systems don't generate user identities, provision them or maintain those identities over time. They rely on an identity provider—an IdP—to do that.

![Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/64i4SsBi0aDhSWZzvjmlOZ/daf5e5b93ef9b80af42355f62f170563/auth0-dashboard)

_The Auth0 web management dashboard._

At the same time, because their standards are often a few years behind, legacy WAM providers generally don't allow for the use of technologies like Google Authenticator, multifactor authentication, and Touch ID. And that's just the tip of the iceberg—other shortcomings of WAM solutions include:

* **Slowed development time**: Maintaining interoperability between your IdP and WAM—and maintaining your network architecture requirements more generally—means you'll be slower to push out new applications, both internally and for your customers.
* **Security vulnerabilities**: Because of the maintenance needs of legacy WAM setups, and their general inflexibility to new technologies, they can leave both you and your customers vulnerable to security breaches.
* **Customer engagement**: Modern marketing and analytics tools that can help you leverage customer data in powerful ways to retain and acquire new revenue require modern, integrated identity solutions.

An IAM like Auth0, on the other hand, can serve as an IdP or identity provider (although you can use your own IdP as well, of course), an identity manager (for provisioning/maintaining user identities) and an access manager (for your native, mobile or web applications).

It can connect to a wide variety of social and enterprise identity providers and APIs and applications—and provide single sign on, granular user management, extensibility with JavaScript and the most up-to-date security protocols.

![IAM in the cloud](https://images.ctfassets.net/23aumh6u8s0i/3gOKNMTjm9Z8HhVWMOuk0D/759807fea82ab299abe4d56b83976ec4/iam-in-the-cloud)

The biggest reason why IAM is surpassing the role of WAM in the modern day is the cloud. The traditional on-premises identity management that many enterprises have used for decades served its purpose. Today, however, more and more of the activity in the workplace is not literally in the workplace. It's in the coffee shop, or at a co-working space, or at home, or on the road—and no matter where your employees are, they will most likely need to access some kind of privileged resources every day.

<include src="TweetQuote" quoteText="Identity management is surpassing the role of web access management because of the cloud."/>

The cloud makes identities more complex because it removes the on-prem notion of “perimeter security.” You can no longer protect your company's network by just securing your four walls—your notion of security must extend to all the BYOD devices and public wireless networks that your employees are using to do their work.

## Identity Management in the Cloud

Legacy authentication tools sold themselves to their customers with the promise of airtight, long-term security. But the world those authentication tools must live in has changed.

Auth0 is [SOC 2 Type II certified](https://auth0.com/why-auth0) and offers HIPAA BAA agreements to healthcare companies that must comply with HIPAA regulations as part of their business. Auth0 also conforms to the OpenID Connect protocol and the new EU-U.S. Privacy Shield Framework for data privacy.

Whether you're migrating from a WAM provider, looking to extend your current system of [enterprise federation](https://auth0.com/learn/identity-management-matters-finance-2/), or just looking to learn more about what identity and access management looks like today, [read more about us here](https://auth0.com/learn/).


The Difference Between Web Access Management and Identity Management

Because paying “per user” doesn't factor in activity levels, you could be drastically overpaying



Depending on your industry, the traditional identity and access management (IAM) provider's pricing structure could be costing you millions of dollars every year.

It comes down to how they define a “user.” Most IAMs charge on a direct per-user rate: $2 a user per month, $4 per user per month, and up from there.

What they don't do is distinguish between registered user and **active user**, someone who actually uses your product once a month(or more).

The VC Fred Wilson has observed that for virtually all web and mobile companies, only 30% of those who register/download the product are active on a [monthly basis](http://avc.com/2011/07/301010/).

For companies in some specialized industries, that percentage can dip even lower. In fields like insurance or healthcare, most “users” active once or twice a year, if that.

Despite this, the majority of IAMs still charge them every single month for _every single user_ they have on the books:

![Charges](https://images.ctfassets.net/23aumh6u8s0i/2gat7Vqlu8f4IO19MNOkW1/2b58b3ee103d1b471485cb3c06a4d998/charges)

![Another pricing](https://images.ctfassets.net/23aumh6u8s0i/6M9oumKecPGjdWwrE9oUDo/7e3f0bdc3178ff903c1c53f10576e007/another-charges)

![Centrify App Services](https://images.ctfassets.net/23aumh6u8s0i/5TKis1bZyerxCzl6hJbYGC/3b6b0f5f6d9591a06b383ff77e3032ea/centrifyappservices)

This pricing system can cost businesses millions of dollars a year because while they may have a total of 5 million users signed up with their service, only a given 100,000 use the service with any regularity.

Or, because while hundreds of thousands may need to have accounts in order to protect sensitive information (like healthcare information or financial records), few need to sign in on a monthly basis. Or, some do, but they're mostly other healthcare providers using enterprise connections, not consumers.

For many types of businesses, paying “per user” as if all of these kinds of usage were the same simply doesn't make sense.

### What Gyms and IAMs Have In Common

For many types of businesses, the “per user” identity management pricing model is the worst of the classic seat-based pricing model combined with the psychology of the gym membership.

The business model of many gyms today relies on people [not showing up.](http://www.npr.org/sections/money/2014/12/30/373996649/why-we-sign-up-for-gym-memberships-but-don-t-go-to-the-gym) People sign up for yearly gym memberships, ambitiously. Then, they neglect to actually go. The fact that a majority of gym members do not regularly visit the gym drives prices down for everyone, and so the slackers subsidize everyone else.

While not exactly the same type of business, Americans only visit their doctors [4 times a year](https://www.forbes.com/sites/niallmccarthy/2014/09/04/americans-visit-their-doctor-4-times-a-year-people-in-japan-visit-13-times-a-year-infographic/#56a1f24ee347). Even if you assume that people will interact with their healthcare provider's online dashboard upon each occasion of them visiting, that's still only 4 logins per year. If you're paying your IAM a flat fee per “user” every month, but only a handful of those users use your product every year, you're paying for a lot of services you don't really need.

Avoiding the topic of consumption when talking about pricing is a [common problem](https://hbr.org/2002/09/pricing-and-the-psychology-of-consumption). Companies try to get you to pay upfront for services, knowing you probably won't use them to the fullest extent possible.

![Payments](https://images.ctfassets.net/23aumh6u8s0i/1F5bb4wuN0iU8mKSZUs4J9/3b97b96d4f0c857573fa1d8a59048cd6/payments)

(Source: [HBR](https://hbr.org/2002/09/pricing-and-the-psychology-of-consumption)) _When you pay annually for a service, your usage drops off steadily throughout the year as the financial impact of payment becomes a distant memory._

However, businesses that mask how much you've spent on a service (vs. how much value you've gotten out of it) often wind up “trading off long-term customer retention for short-term increases in sales.”

Sooner or later, in other words, we realize that we've been paying $50 a month for a gym membership we never use, we do the mental math, and we cancel.

### The Low-Active-User Enterprise

There are many industries out there affected by the kind of inefficient pricing model described above, with insurance and healthcare as two of the most prominent.

Americans file auto collision insurance claims about [once every 17.9 years](http://www.foxbusiness.com/features/2011/06/17/heres-how-many-car-accidents-youll-have.html). They file homeowners insurance claims every [9 to 10 years](http://finance.zacks.com/average-homeowner-file-insurance-claims-8387.html). During the 4 visits Americans make to the doctor annually, they don't log in to their [healthcare provider's online dashboard](https://auth0.com/blog/how-identity-can-empower-healthcare/)—they just hand their identifying information over. And yet in these industries, healthcare and insurance, having continuous, [HIPAA—certified](https://auth0.com/learn/why-hipaa-compliance-is-vital-your-business/), secure identity management is a must.

Let's say you're an insurance company and only about 5% of your overall users actually sign into your online portal each month.

We give away Auth0 support for up to 7,000 active users for [free](https://auth0.com/pricing). However, you could support 140,000 _registered _users on that plan if only 5% of your users log in every month.

When you're ready for multifactor authentication, compliance-ready reporting and enterprise connections, you can upgrade to a fuller plan and _still _pay per active user, just $1,025/mo with 7,000 active users and 100 enterprise customers.

![Auth0 Pricing](https://images.ctfassets.net/23aumh6u8s0i/4v7lWiuk5bHsPTFJatFJc8/e6ec5783cdf3a43e9a5d4556fc863f16/pricing)

If you have 140,000 overall users, but only 5% log in every month, you're still going to pay $4 per _every _user every month. That's $560,000 every month.

That's a price point that just doesn't make sense if you're a business with a low overall active user count. When usage of a product varies so greatly across different industries, per seat pricing models should take that into account.

It's not just insurance and healthcare that face these kinds of problems. Government agencies experience them too, as we can see from a FEMA Request for Information drafted while the agency was in search of a new IAM solution:


**Note:** It is a desire of the Agency to obtain a pricing approach that supports the **variable nature of the size of the FEMA user community**. During periods after large disasters and other events, the Agency user-base may substantially increase in size for a period of time. The vendors should provide creative pricing structures, where possible **such that FEMA does not have to pay / pay less for accounts that are infrequently used**, but still active (e.g., FEMA’s Disaster Reserve Workforce needs quick access when they are activated, but may not be active for long periods of time).

(Source: [FCW](https://fcw.com/articles/2009/01/27/fema-seeks-it.aspx))

FEMA doesn't want their IAM to charge them for hundreds of thousands of users when the total number in the Agency's userbase will be far lower the majority of the time. Nor do insurance providers, healthcare companies, or any business with these kinds of variable levels of activity. When they do, they're effectively subsidizing the price paid by B2C and B2B products with much higher activity-to-user ratios.

### Transparency In Pricing

[Value-based pricing](https://en.wikipedia.org/wiki/Value-based_pricing), as opposed to competitor or cost-based pricing, aims to track the price of a product or service to the perceived value that it delivers to its customers.

We believe transparency and [pay-for-what-you-use pricing](https://auth0.com/pricing) help us get our pricing in line with our value.

If you need [secure login](https://auth0.com/lock), [enterprise connections](https://auth0.com/docs/identityproviders#enterprise), and [multifactor authentication](https://auth0.com/multifactor-authentication), but the level of activity among your user base is unevenly distributed or highly variable, we believe you should pay a different amount than a product where 50% of all users are active on a monthly basis.

Not just because it can be a cost savings for you, but because it means that you're paying for the services you're receiving, and no more, not subsidizing all of the social apps and networks of the world. 


Why Your IAM's Definition Of “User” Could Be Costing You Millions

Don't be daunted by how much of your system needs replacing. We'll show you how to get started.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>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>.</strong>
</div>

---

If you're dealing with a legacy system, you might need a complete overhaul. It's likely that many services have become outdated over the last 10 years you've had it, and patches don't really work long-term.

Legacy systems aren't good for business or your engineers' well-being, they keep you from introducing modern features while forcing the team to run around fixing bugs. However, a lot of companies stick with their legacy systems even when they know how badly they [need to modernize](https://auth0.com/blog/the-role-of-identity-in-application-modernization/). A major factor holding teams back is that you can't do an overhaul all at once.

That's ok, you just need to find your pain points, prioritize, and get started with some quick wins. We'll first talk about how legacy systems are damaging, and then lead you through how to locate the places in your system that need the most work, how to prioritize by cost, benefits, and alternatives, and how to update one piece at a time.

## How legacy systems hurt you

Legacy systems are structures that run on outdated technology, but that a company is still heavily reliant on. Using legacy systems can cost you money, time, quality, and trust. These are some of the biggest headaches of legacy systems:

* The old hardware needed to run legacy systems is rare, and thus more expensive (consider pagers, still widely used by hospitals and costing them about [$180,000](https://www.altexsoft.com/whitepapers/legacy-system-modernization-how-to-transform-the-enterprise-for-digital-future/) a year).
* Legacy systems were often built without modularity, meaning they don't include the code-sharing of modern systems and thus require changing many blocks of code, instead of just one, to make an alteration.
* The vendor who sold you your system may no longer support it, or even exist, which makes patching the system much more difficult.
* As staff who implemented the legacy system leave or retire, you need to train newcomers to use the system.


![How legacy systems hurt you](https://images.ctfassets.net/23aumh6u8s0i/2XhloKwu4vbzqUcEGZmrGy/aba30fe8f5ef9a536ac2de71e57445f5/legacy-systems-dilbert)

_[Source](http://dilbert.com/strip/2006-12-08)_

* Legacy systems often have backdoors to databases built in, making you an easy target for hackers.
* As your system accumulates little patches over time, it becomes more complicated and more prone to breakages.
* Legacy systems don't rely on open standards, so integrating with new technology is sometimes impossible.

Despite all these problems, companies are often reluctant to spend the time and money to replace these systems because it can cripple their short-term ability to innovate. They also risk eroding customer confidence in the product if a [customer might experience](https://www.zendesk.com/resources/why-companies-should-invest-in-the-customer-experience/) adverse, if temporary, effects.

For example, a football stats app may not want to make drastic changes which could cause downtime right before the playoffs, the night before the Super Bowl, right before the draft, or when fantasy football starts, leaving them feeling like there might not be any good moment to tackle upgrades.

But the issues with legacy systems will get larger and larger over time—the longer you wait, the more entrenched you'll be, and the less vendor support you'll have during a switch.

![How legacy systems problems get bigger and bigger](https://images.ctfassets.net/23aumh6u8s0i/3q0fFL6UqspTLpi34otcW9/b252be30e856c44cd7a82b7dd7076a37/legacy-system-dilbert-02)
_[source](http://dilbert.com/strip/2017-02-22)_

In addition to all the other problems above, legacy systems can cause you to miss out on new security protocols. In an area near and dear to our hearts, [authentication](https://auth0.com/blog/is-passwordless-authentication-more-secure-than-passwords/), legacy systems using sessions and cookies no longer cut it with modern applications.

You can learn more about how sessions and cookies work [here](https://auth0.com/blog/5-steps-to-add-modern-authentication-to-legacy-apps-using-jwts/), but what you really need to know is that the process requires the server to save the user's authentication state. This state is then referenced whenever the user makes a request. This protocol works fine for traditional apps, but today apps are deployed across many servers, use RESTful APIs, and rely on downstream services. All of this runs slower when using [stateful](https://nordicapis.com/defining-stateful-vs-stateless-web-services/) systems rather than stateless ones, like JSON Web Tokens (JWTs).

Sticking with your legacy systems prevents you from harnessing the full benefits of this new technology.

## Identifying ways to modernize your system

If your system does need an upgrade pretty much everywhere, how do you know where to start? You likely only have the resources to take care of a few issues at any one time.

The first thing you need to do when looking to modernize your system is to [find your pain points](https://www.altexsoft.com/whitepapers/legacy-system-modernization-how-to-transform-the-enterprise-for-digital-future/) by following these three steps:

* Check which parts of your technology stack are no longer supported by their vendors.
* Conduct an architecture audit to determine how each area is performing, and how patched it is already.
* Create a flowchart, using a tool like [Gliffy](https://www.gliffy.com/), of how different parts of your legacy system work together.

The architecture audit is what comes to mind first when looking for pain points, but the other two steps are just as important. Checking for vendor support tells you how easy it will be to get help and updates for parts of your system, and the flowchart will reveal dependencies, one section may only appear weak because it's dependent on another one, which is actually the problem.

After you've created your list of pain points, you can perform a cost-benefit analysis for replacing those individual parts of your system with a new service, or simply patching them up. The short-term costs of replacement will always loom, but when you calculate the long-term saved repair costs, increased efficiency, and customer satisfaction, you may find that this outweighs the negatives.

## Prioritizing improvements

Once you know how much you'll gain (and lose) from replacing the parts of your system that hurt you the most, you need to be able to prioritize.

Distill your cost-benefit analysis of each of your pain points into the answers to three questions:

1. What will the company gain from replacing this portion of our system?
2. How much time/effort will we need to pull off this replacement?
3. How helpful would just patching this part be in the long-run?


This will form the basis of selection for what to work on first.

![Prioritizing Improvements](https://images.ctfassets.net/23aumh6u8s0i/4jOcbba0mNQETjHPt2kYfq/f057874cef16ecb438148e45efaed307/prioritizing-improvements)

Check out our diagram above: You want to take on the problems that will get you the most value quickly. Notice that our chart shows preference for 'minimal time to replace' over 'higher benefit' (compare rows 3+4, or 5+6), that's because every bit that you update and separate from the rest of your legacy system declutters it and frees up your engineers' time.

Taking the time to dissect and prioritize at the beginning will ultimately make your modernization a shorter, easier process. It transforms your daunting update into a feasible plan.

## Updating one section at a time

Now we'll discuss how to get started on those improvements. The two things to focus on are a microservices-based approach and getting yourself some quick wins!

### Moving toward Microservices

You should look to remove pain points from the rest of your stack rather than simply replacing them. Following this process will guide you toward a microservice-based system, in which an application is separated into small sets of services. Once your monolithic legacy system is reconfigured as microservices, each service can further evolve without disrupting the rest of your system.

![Moving toward Microservices](https://images.ctfassets.net/23aumh6u8s0i/2Ye6NV4YgqkhjgVTL68ATc/7c26590bbf10fd7ad42269e6c389c366/moving-toward-microservices)
[*[source](http://soolan.com/microservice-architecture-implementation/)*]

Keeping microservices in mind will help you today and in the future when small parts of your system can be easily updated as needed.  You don't want to keep your system monolithic and end up with the same complicated, entangled mess 5-10 years in the future.

### The quick first step

Every app is going to have a slightly different list of priorities. But three areas that are usually a great place to start for quick and high value are [payments, messaging, and identity](https://auth0.com/blog/getting-a-competitive-edge-with-a-microservices-based-architecture/). These areas all have comprehensive solutions which let you offload critical functionality to a 3rd party SaaS product in a snap.

* **Payments. **Customers have come to expect a seamless online payment system, and there's no point to risking turning them off by relying on your legacy system when platforms like Stripe and Zuora provide fast, well-trusted payment processing.
* **Messaging. **Messaging too has become an essential part of any app as customers no longer only interact with a product through email. But with products like Twilio, your team doesn't have to worry about any of it.
* **Digital identity.** Identity is one of the most complex items a company has to deal with, and one tiny mistake can result in a devastating data breach. Trying to constantly make changes to keep up with security protocols by adding [multifactor identification](https://auth0.com/learn/get-started-with-mfa/) and breached password detection to your legacy system is a disaster waiting to happen. When you work with providers like Auth0, all the facets of identity, [authentication, authorization, user profiles, and security](https://auth0.com/blog/the-role-of-identity-in-application-modernization/) are taken care of by us.

When you get started on modernizing your system, the rest of it will still be problematic. You want your first steps to be handled by experts, far away from your hiccuping legacy system. But once you get those first steps done, you'll already be so far ahead of your old system.

## Upgrade before you get left behind

Modernizing a legacy system can seem impossible, but breaking it down into small pieces will help you get started.

This is a task you cannot procrastinate on, it will just get harder and harder to maintain your legacy system. Switch over now and reap the benefits of a modern system instead of waiting to be forced into a more painful, more expensive switch later on.

Don't be like the [52%](http://www.techradar.com/news/more-than-half-of-businesses-still-rely-on-windows-xp) of businesses that still run instances on the long outdated Windows XP, you're better than that.


How Do I Modernize my Legacy System?

Security measures should augment productivity, not impede it



Your company would never let a random person walk through the front door of the office without authorization, grab a cup of coffee and start going through confidential files. In the digital workplace, this is exactly what is happening, minus the coffee.

Today, work happens in the cloud on multiple devices, which means your company's data and systems are accessible from anywhere.

You have to find new ways to manage your employees' identities and permissions, so the right people have access to the right systems and data. While security is critical, adding too many security measures hampers productivity.

So how do you balance security and productivity within [the modern digital workplace](https://www.interana.com/blog/how-leading-companies-are-tackling-the-challenges-of-digital-transformation/) where employees are using unsanctioned devices, running hundreds of applications and sharing company resources with outside partners?

Start with an identity and access management (IAM) tool that is designed to keep up with the pace of digital transformation.

### Simplify the digital workplace with IAM

Software for businesses is booming. But hundreds of applications running on unsanctioned devices poses a huge security risk and keeps IT professionals up at night.

While the complexities of managing access across so many tools and devices is a huge challenge, the benefits of the digital workplace are ushering in a new era of productivity where employees can work anytime, in any place with anyone around the world. [Digital transformation](https://www.interana.com/blog/curiosity-got-cat-promoted/) is moving fast, and it's your job to stay ahead of the game.

![The complexity of one employee's digital workspace](https://images.ctfassets.net/23aumh6u8s0i/3ILL4BCkM5rTmj9j8Y7aXd/f1114e008ecd6950c0173d3841eb0861/complexity)

[[Source](http://www.zdnet.com/blog/hinchcliffe/)]

That's why cloud IAM tools, like [Auth0](https://auth0.com/b2e-identity-management-for-employees), are growing so quickly. IT departments no longer need to manage access and authorizations in-house, or scramble to keep up with securing every new application and cloud system that employees bring into the corporate environment.

IAM tools simplify the complexity of the digital workplace by managing all of your user identities and access permissions across your internal systems, employee devices and cloud-based technologies. All of your users, both internal and external, are authenticated and authorized based on the roles that you set within one easy-to-use system.

IAM allows you to keep up with the pace of technology, but more importantly, the security features are designed to enhance productivity. Your organization can maintain high-level security measures, while removing the barriers that interrupt a productive workflow.

### Better productivity without a security compromise

Employees expect a quick and seamless experience when accessing all of their tools. When a user can't log in or is locked out, valuable time is lost contacting a help desk. Productivity comes to a screeching halt.

The whole point of [digital integration](https://amplitude.com/blog/2017/05/18/analytics-stack/) is to be more productive by eliminating tedious and repetitive tasks, including logging in to multiple applications every day. So how can you keep security and permissions in place while eliminating individual logins for every single application? Single sign-on.

In the same way your Google sign-on gives you access to several other applications like Google Analytics, Youtube, and Adwords without re-entering your username and password, good identity management will enable your organization to implement a [single sign-on ](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/)for your entire network.

Once users create their single sign-on (SSO) credentials, they'll no longer have to waste time logging in over and over, giving them a seamless work experience regardless of the application, device or domain.

![Single Sign On](https://images.ctfassets.net/23aumh6u8s0i/74KAL716uJ2wcnwhseJXRa/95dad10d4d42fabbd20490467815eb93/singlesignon)

Single sign-on drastically reduces IT help desk tickets and centralizes admin tasks like password resets. When a password is revised, the change automatically updates every app and system connected to the SSO. IT no longer spends all day helping users with access issues, while your employees enjoy a seamless, more productive work experience.

### Added security that provides flexibility

Employees need the flexibility to work on any device or register a new application to conduct business, but the proliferation of 3rd party applications has broadened the security surface area far beyond any internal IT department can manage.

Cyber threats have become an everyday reality for both large and small businesses. The [2016 Cyber Security Intelligence ](http://ibm.biz/2016CyberIndex) found that 60% of data hacks involved an employee's access data. Either a hacker used an employee's credentials or the employee abused their access privileges.

IAM tools that offer [multifactor authentication ](https://auth0.com/multifactor-authentication)(MFA) provide an extra layer of security that allows your team to use any devices and sign up for new applications without the worry of compromising credentials.

MFA is one of the best ways to identify and verify a user. By asking them for several pieces of information through various stages, the user must demonstrate knowledge (E.g. password or pin number) and possession (E.g. mobile phone). For example, a user is prompted to input their password, which triggers an SMS message with a unique code.

![Multifactor](https://images.ctfassets.net/23aumh6u8s0i/1AUVdavXrQLYR1Y5WFA0N0/6f190786a9012296aca348c5474d8887/multifactor)

[[Source](http://it.miami.edu/_assets/images/multifactor1.png)]


When something unusual is detected, such as a sign-in attempt from a new device, MFA requires the user to have two or more types of ID proof before gaining access. If your password is compromised, your account remains safe. Apps like [Auth0 Guardian](https://auth0.com/multifactor-authentication) offer easy setup for MFA security.

Multifactor authentication offers the flexibility for employees to securely access their resources wherever and whenever, enhancing their productivity.

### Automated permissions keeps business moving

The basic idea behind IAM is to grant each user access to their authorized resources using one set of credentials, which helps streamline IT's workload in tracking permissions. But the bigger challenge for IT is in keeping up with each user's ever-changing privileges status.

In a given week, you can have new employees needing access to start working, other people leaving the company who need their access terminated, and a variety of other employees changing roles, who require different levels of access.

Tracking each user's permissions within an organization is nearly impossible. Your IT team shouldn't waste their valuable time trying to keep up with these constant changes.

The right IAM tool centralizes control of identity and access with an interface that helps you manage every aspect of user ID including automating authorizations, creating and provisioning users, password resets and blocking and deleting users.

![Users](https://images.ctfassets.net/23aumh6u8s0i/G9b0mA8dKR8wYPxtlG2g5/abff6316bcae956309520dcb89242cb1/users)

Administrators can stay ahead of the constant changes by defining security protocols for specific applications and granting permissions to users to access resources at different levels from a central control panel. For example, when an employee leaves the company, your human resource system triggers IAM to terminate access for that user.

You can also automate authorizations by setting rules that define user requirements, such as by devices, location or by limiting unsanctioned applications from connecting to your corporate environment.

When an employee's status changes, they can't wait days for access. Automated permissions and centralized user management help you keep up with the daily authorization changes.

### Stay ahead of your company's digital transformation

Your digital workplace is constantly evolving as [technology continues to evolve](https://amplitude.com/blog/2017/04/26/digital-transformation-yellow-pages/). Employees have the tools and access to information to be more productive. The goal is to keep your company's resources secure without hindering this new level of productivity.

The right IAM technology solution should deliver the best-in-class security measures that work to create a flexible and efficient workflow for employees across all of their tools. When users have a great work experience, they probably won't thank you, but they will work faster and smarter, which helps the company succeed.


Enhancing Productivity With Identity and Access Management

DPM, a Microsoft tool, lets you back up various forms of enterprise data in real time.



After the February 1st, 2017 Gitlab incident, in which six hours of production data were accidentally deleted, the importance of making and maintaining adequate system [backups became very clear to the world](https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/).

As we saw in that incident, a lot of companies make backups. What they seem to forget is that backups are just one part of the equation. It's equally important to consider how those backups will be accessed during an outage, whether it will be possible to restore them in a timely fashion, and what tests need to be consistently run to ensure adequate restore.

If you work within a Microsoft ecosystem, then Data Protection Manager (DPM) is a powerful option for creating and managing backups of all of your data.

### How DPM Works

You can configure DPM to back up your folders and volumes, create full system backups, initiate backups of workloads like SQL Server or Exchange, backup entire Hyper-V virtual machines, and more. Information can be backed up to disk, tape, or to the Microsoft Azure cloud:

- **Disk-based:** In DPM's disk-based protection, a copy of your data is generated, stored, and regularly refreshed on the DPM server. Separate copies are made and maintained for different data sources such as database instances or volumes from a server cluster.
- **Tape-based:** DPM also offers tape-based backups, and though it is mainly intended for long-term storage (where it's combined with disk-based backups for the short-term), you can back up your data primarily to tape.
- **Azure-based:** Whether you deploy DPM as a physical server or Azure virtual machine, you can back up your data to an Azure Recovery Services vault as an alternative to long term tape-based protection.

In the event of a disruption, DPM allows you to immediately restore all of that data.

### Best Use Case Scenarios for DPM

If you're a small business with just one office, or you're backing up volumes that are rarely on-premises, then a more simple, scaled-back solution like Azure Backup agent might be [right for you](https://docs.microsoft.com/en-us/azure/backup/backup-introduction-to-azure-backup). Azure Backup supports backups of both files and folders, but it won't back up VMs, applications, or workloads.

The following kinds of data and workloads can be backed up using DPM:

- Files
- Folders
- Volumes
- Hyper-V VM (Windows)
- Hyper-V VM (Linux)
- Microsoft SQL Server
- Microsoft Sharepoint
- Microsoft Exchange

([Source](https://docs.microsoft.com/en-us/azure/backup/backup-introduction-to-azure-backup))


Microsoft has also put out a slightly less scaled-back version of DPM, [called Azure Backup Server](https://4sysops.com/archives/microsoft-azure-backup-server-mabs-vs-data-protection-manager-dpm/). It's a available for free when you download Azure Backup. Azure Backup Server also offers backups of workloads and other data sources, with some key differences:

- Tape-based protection is only offered with DPM
- DPM allows redundant backups—where you can protect one DPM installation with another
- DPM will also perform recovery of Hyper-V replicas—Azure Backup Server will only do the backing up

Your choice of backup system should track with your needs:

- **I just need to backup files and folders**: Azure Backup agent
- **I need to back up more than files and folders:** Azure Backup Server
- **I need all-in-one management, tape-based protection, and better redundancy:** Data Protection Manager

### Aside: How We Do Backups at Auth0

We have designed Auth0 from the bottom-up to ensure that we can keep serving our customers in the event of any disruption or threat:

- **Infrastructure:** We use SaaS tools and hosts that offer redundancy, so an outage at a single data center or a single disk failing won't affect the continuity of our customers' services.
- **Personnel:** Our staff is distributed all around the world, capable of responding to any problem remotely, and all staff is cross-trained to ensure that there's always someone around that can respond to a threat.
- **Data Storage:** All critical data is stored in the cloud where it is subject to redundant backups. A rigorous testing schedule ensures that all of our backup procedures themselves are operating correctly.

The risk of system failure is always with us, which is why we've worked hard to mitigate that risk through these practices.

![How DPM works](https://images.ctfassets.net/23aumh6u8s0i/3ZUjImSskjBdoSUeoMQdrZ/361224d289fc4f80e945140f5db12db3/auth0)


How Data Protection Manager (DPM) Works

Username and password are not enough. So why do most companies still use them?



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>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>.</strong>
</div>

---

There’s a Technology Basics White Paper first published in 2002 entitled *“Username and Password – A Dying Security Model.”* This paper documents the **HIGH** risk level associated with legacy authentication (using username and password) and predicted that secure access methods using *Biometrics*, [*Single Sign On (SSO)*](https://auth0.com/learn/how-to-implement-single-sign-on/), [*One Time Password Tokens* (a.k.a *passwordless*)](https://auth0.com/passwordless) and [*Multi-Factor Authentication*](https://auth0.com/multifactor-authentication), would quickly replace the use of traditional passwords.

Fast forward to a decade and a half later and the majority of companies are still using username and password authentication. We all agree that legacy authentication is not good enough, so why do most companies still use them?


For many, the path to modern authentication seems difficult and expensive, while others worry about the impact on user experience.


Join me and Garrett Bekker (*Principal Security Analyst of 451 Research*) for a webinar where we will explore this paradox and discuss practices for making secure, modern authentication fast and easy for developers and simple and frictionless for users.

![Risks Posed By Legacy Authentication Webinar](https://images.ctfassets.net/23aumh6u8s0i/725zV9pN6ilKOKGJykmkiL/d6d69f5319e0bcfcff169f50c273574f/webinar-banner)

> The Webinar will be live online Jan 18 9:00 am PST or after on demand.

[Register now!](https://www.brighttalk.com/webcast/10363/235469?utm_source=Marketing&utm_medium=brighttalk&utm_campaign=235469)


Risks Posed By Legacy Authentication Webinar

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">
  <i class="icon-budicon-500"></i>
  <strong>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>.</strong>
</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.<br /><br />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.


5 Steps to Add Modern Authentication to Legacy Apps Using JWTs

bb9128fac91692ad4f46a785d772dd39?s=200 avatar

bb9128fac91692ad4f46a785d772dd39?s=200

Data Scientist and Engineer, I love tinkering with data!

Head of Data

Pablo Seibelt

Learn how to leverage Auth0 to have Shiny Authentication for the open source version or another legacy website.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Some content in this post is outdated. Check our <a href="https://auth0.com/blog/adding-authentication-to-shiny-server/">updated guide</a>.</strong>
</div>


[Shiny Server](https://www.rstudio.com/products/shiny/shiny-server/)  is a great solution for BI/analytics reporting. It leverages all the power of the [R language](https://www.r-project.org/), which is the most popular open-source language for statistics, and it has a lot of useful functions for *Data Mining*, *Machine Learning*, *Reporting*, etc.

<include src="TweetQuote" quoteText="Shiny Server is a great solution for BI/analytics reporting."/>

The open-source version of Shiny Server features no Authentication, and if it's open on Internet, it leaves your data exposed. In that case, you likely won't want everyone on the Internet to be able to see your internal analytics, so you'll need to install and configure the authentication yourself.

One of the easiest ways to add authentication to Shiny and, by extension, any unsecured web application, is to use Apache with Auth0 through the **auth_openidc** module.

This is also useful if you have a legacy web app with a username and password everyone shares or if you are hosting a server with static files you want to share.

![Diagram of the Shiny Authentication scheme](https://images.ctfassets.net/23aumh6u8s0i/1X0EfCJlUSk3CSdyrX73W5/be36fbf08b114b587aa265ebc73987a9/pub_w_959_h_638)

So, let's get started with the steps.

## Installing and Configuring Shiny

First, follow the instructions to [install and configure Shiny Server](https://www.rstudio.com/products/shiny/download-server/).

When you have installed and configured Shiny and you're sure it works, modify your config file so it only serves to 127.0.0.1 (the local machine). This ensures that we don't accidentally expose the open server to the entire Internet.

```
[...]
server {
  listen 3838 127.0.0.1;
[...]
```

## Installing Apache and the OpenID Connect Module

We will use Apache as a gateway to our app using [Auth0's tutorial](https://auth0.com/docs/server-platforms/apache). This will enable Apache to serve as a gatekeeper—a reverse proxy that only serves after authentication.

If you don't already have apache2 installed, install it according to your platform and ensure that you have two modules: mod_proxy and mod_auth_openidc.

mod_proxy is pretty standard. It comes with most apache2 installs, but it is often disabled. To enable it, execute the following with root:

```
a2enmod proxy_http
```

mod_auth_openidc is provided in Debian as libapache2-mod-auth-openidc. Binary packages are available at [the releases page](https://github.com/pingidentity/mod_auth_openidc/releases), or you can always [build it from source](https://github.com/pingidentity/mod_auth_openidc/blob/master/INSTALL). When it is installed, enable it with this command:

```
a2enmod auth_openidc
```

## Configure an Auth0 Account

If you don't already have an Auth0 Account, <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">create one here</a> and set up the type of connections you want to allow. The default settings allow anyone to sign up, but you can set up a better scheme. For example, if you use Google Apps, you can just connect that and [allow only those from your domain to access the server](https://manage.auth0.com/#/connections/enterprise). Alternatively, you can use [rules](https://manage.auth0.com/#/rules) to decide which users are allowed access.

You can [browse the docs](https://auth0.com/docs) or [ask for help](https://support.auth0.com) setting up the best scheme for your scenario.

## Configure Apache to Serve Shiny with Auth0

Make sure Shiny is running in the background while Apache tries to serve it. You can ensure that it's always on by [running it as a Daemon](https://rstudio.github.io/shiny-server/latest/#stopping-and-starting).

You will need to follow the steps in [the Apache tutorial](https://auth0.com/docs/server-platforms/apache). Note: when you are logged in to Auth0, the tutorial includes your own variables in the configuration to make it easier for you.

Create a configuration file for your website using the configuration from the tutorial as a starting point. Replace everything from OIDCProviderIssuer to Location with the code in the tutorial.

You will need to personalize your OIDCRedirectURI. I recommend using https://<your_apache_server>/auth. Of course, replace <your_apache_server> with the public address that will be used for your server.

You also need to generate or write some random string on <passwordToEncryptTheSessionInformationOnTheCookie>

You should at least have a [self-signed SSL certificate](https://devcenter.heroku.com/articles/ssl-certificate-self) to test and a real one to deploy.

It should look something like this:

```
<VirtualHost *:443>
  ProxyPass / http://localhost:3838/
  ProxyPassReverse / http://localhost:3838/
  ProxyPreserveHost On

  OIDCProviderIssuer https://<your-tenant>.auth0.com
  OIDCProviderAuthorizationEndpoint https://<your-tenant>.auth0.com/authorize
  OIDCProviderTokenEndpoint https://<your-tenant>.auth0.com/oauth/token
  OIDCProviderTokenEndpointAuth client_secret_post
  OIDCProviderUserInfoEndpoint https://<your-tenant>.auth0.com/userinfo

  OIDCClientID <YourClientID>
  OIDCClientSecret <YourClientSecret>

  OIDCScope "openid profile"
  OIDCRedirectURI https://<your-website>/auth
  OIDCCryptoPassphrase <passwordToEncryptTheSessionInformationOnTheCookie>
  OIDCCookiePath /

  SSLEngine on
  SSLCertificateFile /path/to/server.crt
  SSLCertificateKeyFile /path/to/server.key

  <Location />
     AuthType openid-connect
     Require valid-user
     LogLevel debug
  </Location>

</VirtualHost>
```

You can save it somewhere like ``/etc/apache/sites-available/001-shiny` and then link it to make it active:

```
ln -s /etc/apache/sites-available/001-shiny /etc/apache/sites-enabled/001-shiny
```

As the tutorial states, Auth0's `clientSecret` is by default Base64 encoded, which isn't compatible with this Apache plugin out of the box. We're going to change that in the near future, but in the meantime, you need to call an API to make sure the clientSecret isn't Base64 encoded for your account.

Get an access token by clicking "Try Me!" on the [docs page](https://auth0.com/docs/api/v1#!#post--oauth-token) and execute the code shown in step 3 of the tutorial to change `ACCESS_TOKEN` to the access token you just received.

## Boom.

Now you have a Shiny Server that is secured with Auth0, which you can use to serve reports only to employees of your organization using username and password authentication or [one of the many identity providers supported](https://auth0.com/docs/identityproviders).

This same configuration works well for other cases. For example, suppose you have an old legacy web application for which everyone uses the same password. That scenario is not very safe, is it? You can give it an additional security layer with the above approach without modifying your site.

## Gotchas

Shiny uses websockets for a lot of things. While we haven't explored tunneling, it is theoretically possible with **proxy_wstunnel**. For most users, this will work fine because if the library fails with websockets, it will automatically fall back to XHR.


Adding Authentication to Shiny Open Source Edition

eugenio-pace-new-avatar

Pace co-founded Auth0 in early 2013 with CTO and “brother-in-arms” Matias Woloski while living 7,000 miles apart from each other. Since then, Pace has played an instrumental role in growing Auth0 into a leading identity management company that is loved by developers and trusted by global enterprises. He loves traveling and has visited more than 35 countries for business and pleasure. He currently lives in Redmond, Washington with his wife, two sons, and their labrador retriever. In his spare time, he enjoys the outdoors, rowing, riding bikes, spending time with his family, restoring his 1970 Karmann Ghia, writing his blog, and reading history and philosophy.

CEO and Co-Founder

Eugenio Pace

Auth0 SDKs make it really easy to add SSO to any app, on any platform. But sometimes, apps cannot be modified. What to do then? A very simple solution is to

Auth0 [SDKs](https://docs.auth0.com) make it really easy to add [Single Sign On (SSO)](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog) to any app, on any platform. But sometimes, apps cannot be modified. What to do then?

A very simple solution is to front any web content with a web server that itself is capable of negotiating authentication for users. One web server with the extensibility required for plugging-in any auth is Apache server.

In this post, we'll learn how to install and configure `mod_auth_openidc` to work with Apache and Auth0.



##How it works
Apache has [plugable authentication modules](http://httpd.apache.org/docs/current/mod/mod_auth_basic.html#authbasicprovider) that you can use to protect specific routes. One such module is [mod_auth_openidc](https://github.com/pingidentity/mod_auth_openidc) written by [Hans Zandbelt](http://hanszandbelt.wordpress.com/).

> __mod_auth_openidc__ is an authentication/authorization module for the Apache 2.x HTTP server that allows users to authenticate using an OpenID Connect enabled Identity Provider.

When a user first attempts to access protected content behind Apache, the module will first redirect the user to the configured OpenID Connect identity provider. After the user is authenticated, access is granted to the actual resource:

![image](https://images.ctfassets.net/23aumh6u8s0i/4Tz0lvc5MlWvs8ydbEj319/0d3b9e38b264ced1ed6a2f835ad18176/pub_w_811_amp_h_340)

Since Auth0 supports the OpenID Connect protocol (among [many others](https://docs.auth0.com/protocols)), it is straight forward to configure the module with it:

```
OIDCProviderIssuer https://contoso.auth0.com
OIDCProviderAuthorizationEndpoint https://contoso.auth0.com/authorize
OIDCProviderTokenEndpoint https://contoso.auth0.com/oauth/token
OIDCProviderTokenEndpointAuth client_secret_post
OIDCProviderUserInfoEndpoint https://contoso.auth0.com/userinfo

OIDCClientID 3g6d6c..........mXNxkAE
OIDCClientSecret _8sCbkTNhYk4..........8u3mdvRFWBx

OIDCScope "openid email profile"
OIDCRedirectURI https://your_apache_server/example/redirect_uri/
OIDCCryptoPassphrase <password>
OIDCCookiePath /example/

SSLEngine on
SSLCertificateFile /home/your_cert.crt
SSLCertificateKeyFile /home/your_key.key

<Location /example/>
   AuthType openid-connect
   Require valid-user
   LogLevel debug
</Location>
```

##How to configure it

First, you need to [register a new app](https://app.myauth0.com/#/applications/create) in Auth0. You will get a `clientId` and a `clientSecret`. These two go to the `OIDCClientID` and `OIDCClientSecret` params respectively. Then you need to setup SSL certs and define the protected locations (e.g. `/example` in the config file above).

Of course you will have to replace the Auth0 auth URLs with your actual account (__contoso__ is used in the example above).

Any of [Auth0 supported identity providers](https://docs.auth0.com/identityproviders) would work: __Active Directory__, __LDAP__, __ADFS__, __SAML-P__, __custom databases__ or any of the __30+ social providers__. Auth0 will bridge any protocol implemented by these identity systems with OpenID Connect.

It is also very easy to configure a _specific_ connection in Auth0 if you add the `connection` parameter to the `OIDCProviderAuthorizationEndpoint` parameter:

```
OIDCProviderAuthorizationEndpoint https://contoso.auth0.com/authorize?connection=linkedin
```

Users will be sent directly to LinkedIn for authentication in this case.

That's it!

[Want to learn more about Single Sign-On? Get The Definitive Guide on SSO (74-page free eBook) here.](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog)

"legacy"