samantha-murphy

Samantha Murphy is a Principal Product Marketing Manager for Okta. She leads the Customer Identity Security portfolio, driving go-to-market strategy, messaging, launches, and strategic growth initiatives. Before Okta, Sam spent over six years in product management roles in Identity and Access Management.

She holds a Bachelor of Commerce degree from Queen’s Smith School of Business and is from Ottawa, Canada.

In her free time, Sam makes the most of winter by playing an awesome ice skating sport called ringette.

Principal Product Marketing Manager, Customer Identity

Samantha Murphy

Innovative companies are reshaping CX with instant gratification, consistency, and hyper-personalization, raising consumer expectations and market standards.

Innovative companies like streaming services and digital marketplaces are setting bold new Customer Experience (CX) standards, redefining consumer expectations around speed, convenience, and personalization. To accelerate and cement their market dominance, these CX powerhouses have raised the bar (and customer expectations) in three key ways:

- **Instant gratification** &mdash; in the form of instant access and seamless experiences such as one-click checkouts
- **Consistency** &mdash; interactions continue seamlessly across channels, devices, products and services
- **Hyper-personalization** &mdash; individualized experiences and recommendations based on preferences and behaviors

## Better Experiences = Better Business

These new CX standards aren’t merely nice-to-haves that customers prefer––they are table-stakes requirements for any business hoping to build and maintain a competitive advantage. Today’s customers *expect* engaging experiences, convenient journeys, and secure digital platforms. Before they give you their business, they need to know that you’re able to cater to their unique needs, provide ease of use across multiple channels, and protect their data and sensitive information.

![Better Experiences = Better Business](https://images.ctfassets.net/23aumh6u8s0i/4uL4F3yqACDm61n5aMiRT1/dfc4ef40b3b83c4ee68705c8ca7e801d/OKTA1067_Auth0_Relaunch_Blog_Image_1_Stats.jpg)

## It All Starts With Identity

Meeting these customer expectations begins with getting Customer Identity right. 

Why? Because Identity orchestration is the backbone of everything — from security to a best-in-class CX.

> **Identity Orchestration** &mdash; is the process of managing and integrating Identity-related functions such as authentication, authorization, security, privacy, and personalization across systems and channels.

**Identity Orchestration** supports every critical aspect of the modern customer journey, from login to omnichannel navigation and continuous threat protection. **Modern Customer Identity** can strengthen security and fraud prevention while simultaneously creating seamless cross-channel continuity and personalized journeys that delight your customers. It also drives privacy by helping protect customer-sensitive data and enabling companies to progressively build customer profiles with consent. This in turn supports key marketing functions like loyalty activation and tracking, driving business growth.

> **In short: Getting the customer experience right begins with getting Customer Identity right**. But this is easier said than done.

## Upgrade Identity, Unlock Customer Loyalty

Here’s the ugly truth: Homegrown and legacy Identity solutions simply cannot support the modern CX and security standards that today’s customers demand.

For example, solely relying on legacy Identity methods like complex passwords, captchas, and rigid multifactor authentication (MFA) policies creates friction that undermines conversion. Identity-powered data-collection tools that burden customers with a million questions at sign-up have the same revenue-tanking effect.

To support customer loyalty and long-term growth, your business needs a modern Identity platform that streamlines experiences, enables personalized interactions, and strengthens security (without adding excessive friction).

Compromising on any one of these points isn’t an option. Today’s competitive landscape requires an approach to Customer Identity that can hit every mark––quickly, efficiently, and continuously.

## Auth0 Is the Answer

Auth0 helps businesses of all types and sizes deliver convenient, trustworthy experiences that customers have come to expect. Designed for both simplicity and scalability, Auth0 empowers companies like yours to adopt a modern, developer-first approach to Customer Identity. In doing so, Auth0 enables your teams to leverage the full power of Identity across every aspect of the customer journey and deliver outcomes that support growth.

![Auth0 Is the Answer](https://images.ctfassets.net/23aumh6u8s0i/396zh0bFmWePy5f5dRY1e0/9529f63ac52dd9fb6523570ad04c9788/Three-speaker_Podcast_Templates__Auth0_Platform__-_1200x628.png)

## Layer 1: Secure Experiences

![Secure Experiences](https://images.ctfassets.net/23aumh6u8s0i/3Ojc09oomw7ENwTB0BWhbF/7dcabdb076f87e0a6538ae764c0c3d2a/OKTA1067_Auth0_Relaunch_Blog_Image_2_Layer_1.jpg)

Auth0 helps secure customer experiences across their entire journey &mdash; before, at, and after login. To keep experiences streamlined, Auth0 leverages context to add additional layers of security when needed and reduce them when not needed. This enables the ideal combination of security and seamlessness.

### Before Login

Spotlight solutions:

* **Bot Detection** &mdash; Continuous, AI-powered monitoring for Identity threats that responds to bad bots in real time 
* **Breached Password Detection** &mdash; Detect compromised credentials and block and notify users in real time to keep threat actors out
* **SCIM** &mdash; Streamlined user management that automates the provisioning and de-provisioning of user access for B2B SaaS applications

![jersey-mikes](https://images.ctfassets.net/23aumh6u8s0i/1BMaeu8xs2ppTl8VaTMdml/543750478b37ce860cd458d0962376b6/OKTA1067_Auth0_Relaunch_Blog_Image_3_Jersey_Mikes.jpg)
Read more about this story [here](https://www.okta.com/customers/jersey-mikes/).

### At Login

Spotlight solutions:

* **Universal Login** &mdash; A customizable toolkit for building robust, branded authentication flows from a variety of login methods
* **Passwordless** &mdash; Convenient, secure sign-in using options including passkeys, email magic links, biometrics and One-Time-Passwords (OTPs).
* **Attack Protection** &mdash; helps prevent account takeover attacks with Brute Force Protection and Suspicious IP Throttling.
* **Token Management** &mdash; A secure framework for issuing, validating, and renewing JSON Web Tokens (JWTs) that streamline API access while protecting sensitive data during transmission
* **Progressive Profiling** &mdash; An easy way to gather customer data over time as they engage with your brand (as opposed to flooding them with questions at sign-up or login and scaring them away)
* **Organizations** &mdash; Enterprise-grade, secure, scalable, branded multi-tenant authentication for your B2B SaaS applications

![moneyfarm](https://images.ctfassets.net/23aumh6u8s0i/1aVC0XqsaxBT0txqkrnVzt/dc401cbe0ecd9d3fa5c7cf348c7b2f13/OKTA1067_Auth0_Relaunch_Blog_Image_4_Moneyfarm.jpg)
Read more about this story [here](https://www.okta.com/customers/moneyfarm/).

![cinepolis](https://images.ctfassets.net/23aumh6u8s0i/2Sh98UZEppi086rLYJTlCr/c1c9a8619ffbffac82187c823035b814/OKTA1067_Auth0_Relaunch_Blog_Image_5_Cinepolis.jpg)
Read more about this story [here](https://www.okta.com/customers/cinepolis/).

### After Login

Spotlight solutions:

* **Auth0 Fine-Grained Authorization** &mdash; A simpler way to programmatically define authorization and access at scale across applications
* **Highly Regulated Identity** &mdash; Powerful protections for highly sensitive information that trigger Strong Customer Authentication (SCA) when necessary
* **Client Initiated Backchannel Authentication** &mdash; Secure and streamlined user authentication for call center, in-person, and online interactions
* **Continuous Session Protection** &mdash; A unified way to monitor and manage user sessions, including the prevention of session hijacking and the revocation of suspicious sessions
* **Universal Logout** &mdash; Terminate users’ sessions when integrated threat monitoring tools identify a change in risk

![cribl](https://images.ctfassets.net/23aumh6u8s0i/2G1znaaE8I8iRjXYSaC9Ib/e99f1efba55465981b4e9e5237c8d81b/OKTA1067_Auth0_Relaunch_Blog_Image_6_Cribl.jpg)
Read more about this story [here](https://www.okta.com/customers/cribl/).

## Layer 2: Orchestration

![Orchestration](https://images.ctfassets.net/23aumh6u8s0i/4Xyqph6V36HBEck0EvCxre/7f8e763c47a09df044bc9ae52d1c492e/Copy_of_OKTA1067_Auth0_Relaunch_Blog_Image_7_Layer_2.jpg)

Your business is one of a kind, and this is evident in the uniqueness of your security needs and CX strategy. 

Auth0 puts customization at the core of your company’s security and CX with a range of offerings that your development teams can leverage to build better products––faster. Low- and no-code tools help developers build and optimize authentication flows faster, while pro-code options enable last-mile customizations tailored to your business’s unique needs. 

### Developer Tooling

Spotlight solutions:

* **SDKs and Quickstarts** &mdash; With a few lines of code, your teams can easily integrate Auth0 with any app written in any language and any framework 
* **Automated deployment** &mdash; Manage Auth0 tenant configuration integrated with your existing CI/CD pipeline using Auth0 Deploy CLI or Terraform provider

![signify](https://images.ctfassets.net/23aumh6u8s0i/4Un8sWHBAdmaQyqGVDtDR5/77c947a4b255b71037e7287de12d0a6d/OKTA1067_Auth0_Relaunch_Blog_Image_8_Signify.jpg)
Read more about this story [here](https://www.okta.com/customers/signify/).

### Custom authentication flows

Spotlight solutions:

* **Actions** &mdash; Empower developers with a drag-and-drop interface and flexible code environment that enables them to customize and extend Identity experiences—no-code for speed, pro-code for precision
* **Forms** &mdash; A no-code visual editor for orchestrating, customizing, and securing sign-up and login flows

![submittable](https://images.ctfassets.net/23aumh6u8s0i/5OavujxBJu2IrT7iCSeCon/2e390cc4ff3bc92730ba0d0e94a760bb/OKTA1067_Auth0_Relaunch_Blog_Image_9_Submittable.jpg)
Read more about this story [here](https://www.okta.com/customers/submittable/).

### Security operations

Spotlight solutions:

* **Security Center** &mdash; helps organizations detect and respond to attacks faster and fine-tune their security posture with intelligent insights and custom threshold alerting for Identity-related events, anomalies, and general efficacy.
* **Log Streaming** &mdash; further supports faster event response by allowing the streaming of relevant Auth0 activity to third-party SIEM tooling.

![Splunk](https://images.ctfassets.net/23aumh6u8s0i/4LgnDhyuTSTFmvIphsmxKt/6ff774c7ddb324f55be62440d10f6c37/OKTA1067_Auth0_Relaunch_Blog_Image_10_Splunk.jpg)

## Layer 3: Extensibility

![Extensibility](https://images.ctfassets.net/23aumh6u8s0i/1FXD0NT7qsqMAxYWIBszDQ/c743dda19d466dc00a6550181785d0d5/OKTA1067_Auth0_Relaunch_Blog_Image_11_Layer_3.jpg)

As your business evolves, your identity solution should seamlessly connect with your changing tech and security stack—it's crucial for long-term success. 

Auth0 is built on the principle of extensibility. By connecting every part of your technology and security ecosystem, Auth0 enables continuous strength of security while also supporting changing customer experience  functions across all channels.

### Marketplace Integrations

Quickly find and add low-maintenance, no-code integrations with applications and APIs. Using an intuitive drag-and-drop interface, it easily addresses a variety of Identity use cases such as Identity verification/proofing, fraud prevention, log streaming, data platforms, and consent management.

![Marketplace Integrations](https://images.ctfassets.net/23aumh6u8s0i/1MMEK4OhC8WgiGHWT9eijc/d50c0e020631562833bdc614ef87cc7a/OKTA1067_Auth0_Relaunch_Blog_Image_12_CLEAR.jpg)

## The Auth0 Difference

Best-in-class businesses adopt modern, developer-first Customer Identity. With Auth0, your development teams get pre-built tools—SDKs, APIs, customizable UI components, and security integrations—that can be activated instantly and extended as needed. This approach enables businesses to:

* Secure every step of the customer journey without adding friction
* Automate and orchestrate Identity flows to accelerate time to market
* Empower developers to integrate Identity their way, providing scalability and future-proofing

That’s exactly what the Auth0 Platform delivers to thousands of businesses worldwide—powering **10+ billion** authentications every month. Yes, that’s** billion with a B! **

Ready to build seamless, secure identity experiences? [Let’s talk](https://auth0.com/contact-us). Want to learn more about why companies like yours choose Auth0? Check out our [ebook](https://auth0.com/resources/ebooks/why-auth0-by-okta).


Designing Apps for Growth: How a Layered Identity Solution Helps You Win

abhi

Abhishek Ambastha is a Group Product Manager with over 18 years of experience in security and identity solutions. At Okta CIC, he drives innovations to counter identity threats and enhance user security with seamless experiences.

Group Product Manager

Abhishek Ambastha

carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby, Python, and Elixir.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Senior Developer Advocate

Carla Urrea Stabile

There are so many resources out there about passkeys and each vendor has its own implementation of the standard. Let’s answer some of your frequently asked questions about passkeys at Auth0!

There are so many resources for passkeys, and each vendor has its implementation of the standard. 

If you still need to familiarize yourself with passkeys, I recommend you look at this [blog post](https://auth0.com/blog/webauthn-and-passkeys-for-developers/).

Now, let's answer some of your frequently asked questions about passkeys at Auth0!

## Can I Use Passkeys With The Free Tier?

Starting with the elephant in the room, let's leave this clear here and now: **Passkeys are included in ALL PLANS**, yes, including the Free Tier, at no additional cost. We really, really are aiming for a passwordless future, and this is part of our commitment to it. 

## Migrating from Passwords to Passkeys

The industry is moving towards a passwordless future, and at Auth0, we are committed to the same goal. 

<include src= "LearnPasskeysCTA"/>

### Is Auth0 getting Rid of Passwords Entirely?

Not yet. For now, we introduced passkeys as an additional authentication option alongside passwords. Users can choose between a passkey and a password based on what works best.

### Can your Users Only Use a Passkey for Login?

Yes, absolutely. End users can sign up and log in using only passkeys, providing a completely passwordless experience. Passkeys serve as a robust first and primary factor for account authentication, designed to enhance security and offer a more user-friendly experience. The goal is eventually to replace passwords.

### Can your Users Continue to Use Passwords for Signup & Login?

Yes. If passkeys are enabled in the configuration, end users will be prompted to continue with a passkey or a password.

<img src="https://images.ctfassets.net/23aumh6u8s0i/AbdRxr97bTLiR7ciHSFMs/9d8d9592d5b26a9b7dfa80271831c07c/passkeysprompt.png" alt="passkeys prompt" width="300"/>

### What About the Existing Users with Passwords?

When you enable progressive enrollment in the Auth0 Dashboard, existing users with passwords will be prompted to add a passkey so that they can use it in subsequent logins.

### Does Auth0 Support a Passkey-Only Flow (a flow where there is no password involved anywhere)?

Not at the moment. We are keeping the option of using passwords alongside passkeys; there are still some challenges regarding compatibility issues with older devices or browsers that need passkey support. In such cases, passwords will remain a viable method of authentication. 

In other words, **disabling password is not yet supported in the Database connection.**

![Username-Password DB Connection on passkeys config page](https://images.ctfassets.net/23aumh6u8s0i/3e3aJQhXISfjet2Pb3qvT2/6218e3ad3cdca472faafb23f06a7c06b/passkeys-db.png)

### Which Device and Browser are Compatible with Passkeys?

Passkeys are compatible with different operational systems and browsers at differing levels. Please refer [to `passkeys.dev` Device Support](https://passkeys.dev/device-support/) (maintained by [W3C WebAuthn Community Adoption Group](https://www.w3.org/community/webauthn-adoption/) and members of the [FIDO Alliance](https://fidoalliance.org/)) which provides latest information on device/browser support on passkeys.

> You can [learn more about passkeys and see them in action](https://youtu.be/v-KTu8W\_irM?feature=shared) in this excellent session from Oktane 2023. 

## Enabling Passkeys in Your Auth0 Tenant

You can enable passkeys by switching a toggle, and you can always refer to [the documentation](https://auth0.com/docs/authenticate/database-connections/passkeys) to understand how the signup and login flow with passkeys work at Auth0, but let's answer some more specific questions about enabling passkeys:

### How Can You Enable Passkeys for Your Users?

Passkeys are available in the Database connection section in the Auth0 Dashboard. You could enable passkeys by logging in to your Auth0 Dashboard and navigating to [Authentication -> Database](https://manage.auth0.com/\#/connections/database) -> Connection -> Authentication Methods -> Passkey as shown in the below screenshot.

![Username-password db connection page](https://images.ctfassets.net/23aumh6u8s0i/6ApYxla0hbMtXy6gEVwEpV/a2328b46620c5d74ad44d5b7b4294783/passkeys-rb-1.png)

For more details on enabling passkeys, follow the steps [in this blog post.](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/) 

### Are there any prerequisites to enable passkeys?

Yes, passkeys come with specific prerequisites:

1. Enable New Universal Login: we encourage you to switch to New Universal Login, where new features like passkeys are being introduced.

2. Deactivate Custom Login Page: Enabling the Custom Login Page reverts the New Universal Login to the Classic experience, which connects to the first requirement.

3. Activate Identifier First Login: This facilitates a seamless user journey, beginning with the Identifier. Users can then decide whether to proceed with passkey or password authentication.

4. Deactivate Requires username: For connections that have not activated attributes for flexible identifiers, the username is not supported. To use passkeys with usernames, you will need to  [activate attributes for flexible identifiers](https://auth0.com/docs/authenticate/database-connections/activate-and-configure-attributes-for-flexible-identifiers) on the connection.

5. Disable Use my own database: Finally, "Use my own database" must be disabled unless Import Users to Auth0 is enabled as it implies passkeys created in the system will remain separate from user credentials stored in external custom databases (unless Lazy migration is ON).

If you are missing any of the prerequisites above, we will show a checklist similar to the image below when you try to enable passkeys for your users.

![passkeys pre-requisites](https://images.ctfassets.net/23aumh6u8s0i/2n9HEqIK9TN3Fep2VEaSpA/80016c1e19d9c713ecc6c20a034cdb51/passkeys-prereq.png)

### Is there any other important consideration for enabling passkeys?

An important point to note is **the [relying party](https://auth0.com/docs/glossary\#relying-party) domain should not change after passkeys are enrolled**, because changing the domain will invalidate all existing passkeys. As such, passkeys are created for a specific RP domain.

### Are there different options for logging in with passkeys?

Yes. You could choose how the passkey options are rendered in their end user prompts. This will control how the challenge is triggered. 

Two options are available for logging in with passkeys: **Passkey Button and Autofill.** By default, both options are enabled when passkeys are configured.

> As per [FIDO UX guidelines](https://fidoalliance.org/UX-guidelines/), FIDO research explored participants' success and satisfaction with dedicated passkey buttons and autofill. FIDO testing indicates that autofill ensured the highest success for people to sign in with a passkey.

However, it is essential to note that autofill does not work in all scenarios. For example, when autofill is disabled in the browser, the Passkey Button provides the fallback UX.

## Passkeys Configuration at Auth0

### What is Local Enrollment?

When you enable local enrollment and authenticate through the cross-device flow (using a QR code) across ecosystems, Auth0 will prompt the user to create a passkey on their second device. Local enrollment ensures secure and effortless logins, as the passkeys from the second device become accessible for subsequent logins. It also eliminates the need for the user to repeatedly use a QR code to log on to the second device; instead, they can simply utilize the local passkey for all subsequent logins.

### What is Progressive Enrollment?

Progressive enrollment allows Auth0 to prompt existing users with passwords to add passkeys so they can use them for their next login. 

### Why is Auth0 Skipping Captcha Verification When Passkeys are Selected?

Passkeys already offer a phishing-resistant authentication method. To achieve a faster, seamless, and secure login experience, adding additional friction during login steps like Captcha is not optimal. Hence, Captcha verification is presented, but users can skip this step when they select log in with a passkey. They still have to solve a Captcha if they're presented with one and choose to continue with the password.

### Does Auth0 have any limit on the number of passkeys per user?

Yes. For now, we've implemented a **limit of 20 passkeys per user.** A user could have multiple passkeys. For example, a user could create a passkey on Apple and Google devices when they authenticate via cross-device authentication using a QR code.

## Security & Attack Protection with Passkeys

### What if An Attacker Tries to Abuse a QR Code?

FIDO cross-device authentication incorporates an inherent verification mechanism utilizing Bluetooth technology to ensure the proximity of the two devices. While this process remains seamless for the user, potential attackers who acquire a QR code and attempt remote logins will be thwarted, as the cross-device authentication does not operate over remote connections. We're limiting the attack surface to a few meters of physical proximity instead of anywhere in the world, as with passwords.

### Is Bluetooth a Requirement for Cross-Device Authentication? How does it Impact the Overall User Experience?

Yes. The Bluetooth-based proximity verification for cross-device authentication happens seamlessly for the end user. If they have deactivated Bluetooth, a user-friendly prompt will guide them to enable Bluetooth when they scan a QR code for cross-device authentication.

### Are Attack Protection Features Applicable to Passkeys?

Yes. Certain attack protection features, such as Suspicious IP throttling, will be applicable for passkeys. Credential Guard is skipped when utilizing a passkey due to the absence of a password. While Bot Detection will operate during the pre-login assessment phase, the Captcha verification step is bypassed when opting for passkey-based logins.

### What if MFA is Enabled in the Flow?

The MFA policy will continue to apply for login with passkeys. This implies that users will be prompted with a second factor depending on their MFA configuration. If you choose to bypass a second factor, you could implement custom logic when a passkey is used as an authentication method.

### Can I use Passkeys as a Second Factor?

Not for now. Passkeys are the first and primary factor for account authentication, designed to enhance security and offer a more user-friendly experience. The goal is to eventually replace passwords.

## Managing and Handling Passkeys

### How can you debug passkeys in your tenant logs?

Passkeys are an additional authentication method. Therefore, we're repurposing existing event codes outlined in [Log Event Type Codes](https://auth0.com/docs/deploy-monitor/logs/log-event-type-codes). However, to enhance clarity regarding the employed authentication method, we've incorporated the following elements:

* Signup: The event with type `ss` will include a field `details.authentication_method` set to either `password` or `passkey` based on the method used during signup.

* Login: For passkey-based logins, `"performed_amr": ["phr"]` is included. During login, the event with type `s` indicates if a passkey is used to authenticate. The `details.prompts` array contains the set of prompts that the end-user navigated through, and the `"performed_amr": ["phr"]` will be present on the element if passkey authentication was used (`phr` stands for "phishing-resistant" and is the standard amr (Authentication Method Reference) claim value for passkeys).

* Progressive & local enrollment: Successful enrollment will be captured with `gd_enrollment_complete`, while failed enrollment attempts will be recorded as `gd_webauthn_enrollment_failed`.

### Can you Use Passkeys with the Management API?

Yes, you can list and revoke passkeys using the Auth0 Management API. You can learn more about [managing passkeys with this blog post.](https://auth0.com/blog/passkeys-management/) 

### Can you Use Passkeys with Actions?

Yes. You can, for example, detect whether a user authenticates with a passkey within the [Post-Login trigger](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow).

In the event object, the `authentication.methods` array contains elements describing the methods used to authenticate for the current session. The elements' names are set to `pwd` for regular password-based authentication and `passkey` for passkey-based authentication.

## Account Recovery

### How can users recover their passkeys?

Auth0 stores a record of public information about your passkey (such as the public key) that you can use for authentication. As passkeys are stored within their respective ecosystems (like Apple or Google) and not shared with the relying party (such as Auth0), end users must retrieve passkeys directly from these ecosystems when needed. 

### How could users recover an account?

The existing account recovery process remains unchanged. Users will still need to verify their email by clicking the link in their inbox. Following successful verification, they'll have the option to set up a new password.
 

We hope this passkeys FAQ helps you leave passwords behind and enable passkeys for your users today. If you have other questions, make sure to post them in the comments, and our team will be happy to help! 

All You Need To Know About Passkeys at Auth0!

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Staff Developer Advocate

Juan Cruz Martinez

bruno-krebs

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

R&D Content Architect

Bruno Krebs

Learn how to secure your Electron applications using standards like OpenID Connect and OAuth 2.0.

Securing Electron Applications with OpenID Connect and OAuth 2.0

ryan cobb

As a patent attorney, I thoroughly enjoy providing counsel relating to the intersection between technology and law. In my current role as the IP counsel for Okta, I advise the company on a all IP matters (including supporting various roles including product, employment, M&A, Okta Ventures, and commercial legal) and help create and manage policies and workflows to enable the business and engineering teams to succeed in the marketplace.

Director, IP Counsel

Ryan Cobb

Developers contributing to Auth0 and Okta projects are provided with a simple way to complete our industry-standard agreement in just a few clicks

We’re going to soon be implementing a Contributor License Agreement (CLA for short) on our open source projects to allow us to continue providing as many open source offerings as we can. 

What’s a CLA, you may be asking? Well, in short, it provides licenses to us and the rest of the community to use the Intellectual Property (IP) you create when you contribute to one or more of our open source projects. But more on the nuts and bolts of that later… 

Why are we doing a CLA now? As we grow, we increasingly see a need to protect our open-source projects at Auth0 and Okta so that we can freely accept contributions and our projects can grow. Additionally, the CLA process at Okta was cumbersome, and we wanted to relax that, so we decided to use CLA Assistant to streamline the signing process for our fantastic community of contributors. 

To create our CLA, we looked around the industry and based our CLA on similar language found in those from the [Apache Foundation](https://www.apache.org/licenses/icla.pdf), [.NET Foundation](https://github.com/dotnet-foundation/foundation/blob/master/guidance/net-foundation-contribution-license-agreement.pdf), [CNCF](https://github.com/cncf/cla/blob/master/individual-cla.pdf), [Google](https://cla.developers.google.com/about/google-individual?csw=1), the [Eclipse Foundation](https://eclipse.org/legal/ECA.php), and [Salesforce](https://cla.salesforce.com/sign-cla), to name a few. You can check out the text of our CLA [here](https://cdn.auth0.com/blog/okta_cla.pdf). If you’ve signed a CLA with Okta in the past, we’re going to ask you to sign a new one via the CLA Assistant (don’t worry… you don’t need to print anything out… you just sign right in Github!). This way, we have all the agreements in the same place and organized by your Github handle. It’s just a few clicks! 

If you want to contribute to one or more of our Open Source projects, what it means to you is: 

* License grant - you grant a copyright and patent license to your contribution so that others using the open-source project can use it without fear of infringement issues. 
* We ask that you represent that the contributions are yours to be made, and you can grant the associated rights to those contributions. 
* We don’t expect you to provide any support for your work unless you want to. 
* The agreement is retroactive to cover your past contributions to ensure we have the most up-to-date protections. 
* Suppose you’ve made contributions in the past but don’t want to sign our CLA, no problem. You don’t need to sign it for any of your past work. But, if you want to make contributions from now on, we will ask you to sign the CLA so that we can make sure we continue offering our best to the community. 

We hope these changes will make the experience of contributing to our Open Source projects better, more straightforward, and safer for everyone. If you have any questions or concerns on this, please reach out to our developer forum, where we will do our best to get you the answers and address your needs. Thank you for your past and future contributions! We appreciate them and look forward to continuing building together!

<include src="asides/AboutAuth0" />

Scaling Our Open Source Projects: Implementing a Contributor License Agreement

idee

Software Engineer building with Kotlin and Flutter.

Software Engineer at Busha

Idorenyin Obong

We will take a look at some standard practices we should apply when building Android applications.

Best Practices in Android Development

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

A first-person account of how modern open identity standards are made

From Idea to Standard: How the JWT Profile for OAuth 2.0 Access Tokens Became RFC9068

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

A guide for understanding the differences between .NET, .NET Core, .NET Framework, .NET Standard, etc. by exploring the history of the platform.


If you are confused in front of the different facets of .NET, or if you are not clear on the differences between .NET, .NET Core, .NET Framework, .NET Standard, and similar, well, this article is for you.

## What .NET Means Today

Say you are a new developer that wants to approach .NET. Caught up in the excitement, you navigate to [Microsoft's website](https://dotnet.microsoft.com/) and find the following definition:

![.NET: Free. Cross-platform. Open source. A developer platform for building all your apps (web, mobile, desktop, game, IoT).](https://images.ctfassets.net/23aumh6u8s0i/2yLTpLYPjn9DUjXgqHkN0f/03d54d78d435bc55ea6885a912cc9945/dotnet-platform.gif)

Cool! This platform looks great! You can build any kind of application by using C# or [any other .NET compatible programming language](https://en.wikipedia.org/wiki/List_of_CLI_languages).

However, there are issues are around the corner...

Maybe you find an awesome library on [NuGet](https://www.nuget.org/), but learn that it is for the .NET Framework and cannot use it in your project unless you target your project to .NET Standard 2.0. In that case, your application will also run on .NET Core.

What? Isn't .NET Framework just .NET? And what are .NET Standard and .NET Core?

Welcome to the .NET maze! If you don't want to get lost in it, you need [Ariadne's thread](https://en.wikipedia.org/wiki/Ariadne).

I understand that not everyone likes history, especially in the IT field. Many people prefer to know what and how to do things *today*. But, as it happens in everyday life, the past has a great influence on the present and also on the future. To understand today's and future .NET, you need to take a step back and trace its history, at least in broad strokes.

## In the Beginning Was the .NET Framework

In 2002, Microsoft promised one framework to build applications with any programming language: C# (born for that occasion), Visual Basic, and [many other languages](https://en.wikipedia.org/wiki/List_of_CLI_languages). The framework granted a common API set, language independence, interoperability with the underlying operating system and other non-.NET applications, portability (at least in perspective, at the time), and many interesting features.

Although the long-term idea was to make .NET a cross-platform framework, **the .NET Framework only ran on Windows**.

Don't get me wrong. Even if I'm speaking in the past tense, the .NET Framework is still alive and operative. Its [current version is 4.8](https://devblogs.microsoft.com/dotnet/announcing-the-net-framework-4-8/), and it is the last version of the framework, as you will learn later. But a huge amount of code runs on it, so you cannot consider it a dead framework yet.

## Mono on the Stage

One interesting thing is that Microsoft published the specifications of the [*Common Language Infrastructure* (CLI)](https://en.wikipedia.org/wiki/Common_Language_Infrastructure), that is, the .NET Framework runtime, and the C# language. Even better, they set them as open standards: [ECMA-335](https://www.ecma-international.org/publications-and-standards/standards/ecma-335/) and [ECMA-334](https://www.ecma-international.org/publications-and-standards/standards/ecma-334/). So pretty much anyone could implement the .NET runtime and the C# programming language.

In 2007, this paved the way for a project to port .NET to Linux: [the Mono Project](https://www.mono-project.com/). Other attempts to port .NET on Linux were made: [DotGNU](https://www.gnu.org/software/dotgnu/pnet.html) and [CrossNet](https://archive.codeplex.com/?p=crossnet), among others. However, only the Mono Project attracted significant interest and generated a production-ready framework.

However, not everything in the .NET Framework could be ported to Mono due to some strict dependencies on Windows. In addition, the state of Mono development was usually not so aligned with the current state of the .NET Framework. This actually created some friction with the real portability of .NET applications to Linux.

## .NET Everywhere

The open specifications of the .NET fundamental components were the first step towards the quick spread of the framework. Microsoft on one side and other independent developers on the other side brought the .NET Framework to different platforms.

When the .NET Framework was born, Microsoft also released the [.NET Compact Framework](https://en.wikipedia.org/wiki/.NET_Compact_Framework). It was a reduced version of the framework designed to run on devices with limited computing capacity, such as PDAs, mobile phones, set-top boxes, etc.
In 2007, the [.NET Micro Framework](https://netmf.github.io/) was launched: a more efficient version of the .NET Compact Framework that could also run directly on the hardware.

The same year, [Silverlight](https://en.wikipedia.org/wiki/Microsoft_Silverlight) brought .NET to the browser, providing developers with a framework for building rich Internet applications similar to Adobe Flash.

In 2009, the [MonoTouch](https://en.wikipedia.org/wiki/Mono_(software%29#MonoTouch) project started. It was the first attempt to port the Mono framework (that is, the Linux implementation of the .NET Framework) to iOS and Android. In a few years, the MonoTouch project became the foundation for [Xamarin](https://dotnet.microsoft.com/apps/xamarin), the framework for building Android and iOS apps with C# (2013).

So, as early as 2013, .NET allowed you to build applications for Windows and Linux machines, for embedded devices, for the browser, and for iOS and Android devices.

You may think that it was amazing! However, the proliferation of different environments led to a fragmentation of the framework itself. That wasn't much of a problem for those who were developing applications. Applications are usually platform-specific. This fragmentation was a big problem for library developers. In fact, a .NET assembly could theoretically be loaded in any .NET runtime. Unfortunately, it could break at any point if it calls an API that wasn’t supported by the platform it is running on.

The cross-platform dream had not yet come true.

<include src="TweetQuote" quoteText="As early as 2013, .NET allowed you to build applications for Windows and Linux machines, for embedded devices, for the browser, and for iOS and Android devices."/>

## The Rise of .NET Core

In 2014, to pursue the goal of an actual cross-platform development framework, Microsoft started writing .[NET Core](https://github.com/dotnet/core) from scratch. The first release was ready in 2016. The new framework was a complete redesign of the .NET specifications with cross-platform support in mind. In fact, its runtime ran on Windows, Linux, and macOS.

This new framework didn't have the backward-compatibility constraints that the .NET Framework had. Its modular architecture provided smaller versions of the framework's core components, letting the developer download the additional components from the NuGet repository. This refactoring enabled simplified deployment and portability.

## The Need for a Standard

While .NET Core was a step in the right direction for cross-platform support, it brought yet another implementation in the already entangled .NET ecosystem. In other words, a library developer has another potential pain point for the portability of their library.

Microsoft tried to put order into this chaos by [introducing the .NET Standard](https://devblogs.microsoft.com/dotnet/introducing-net-standard/). This is not just another framework implementation, but a formal specification of .NET APIs that multiple .NET platforms have to implement. Different .NET Standard versions define different .NET API sets. This way, a .NET implementation declares which .NET Standard version it supports. The library developer needs to target that specific .NET Standard version.

For example, if you want your library to run on .NET Framework 4.5, .NET Core 2.1, and Mono 4.6, you should target your project to [.NET Standard 1.1](https://github.com/dotnet/standard/blob/master/docs/versions/netstandard1.1.md). See the [official documentation to take a closer look at the .NET Standard](https://docs.microsoft.com/en-us/dotnet/standard/net-standard).

Targeting a .NET Standard is a matter of specify the [Target Framework Moniker (TFM)](https://docs.microsoft.com/en-us/dotnet/standard/frameworks) in the .NET project file. It is something like the following in your .NET project file:

``` xml 
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard2.0</TargetFrameworks>
  </PropertyGroup>
  ...
</Project>
```

## Only .NET from Now On

Finally, in November 2020, [.NET 5 was released](https://auth0.com/blog/dotnet-5-whats-new/). This new version of the framework aims to be the unified .NET platform from now on. No more need for different implementations: .NET 5 is the common set of APIs that runs on Windows, Linux, Mac, iOS, and Android. So, if your project targets .NET 5, your code will run on all those platforms.

![.NET 5 platform](https://images.ctfassets.net/23aumh6u8s0i/62ADaRg2zm1S8J9gpKX6Kv/a062f9c576330a811fb155da37104beb/dotnet5_platform)
<p align="center"><i><a href="https://devblogs.microsoft.com/dotnet/introducing-net-5/">[Source: Microsoft]</a></i></p>

If you need a given platform's APIs, you should use a specific TFM. For example, if you want to use [Windows.Forms](https://docs.microsoft.com/en-us/dotnet/desktop/winforms/?view=netdesktop-5.0) for your desktop application, you need to specify the `net5.0-windows` TFM, since this feature is supported on the Windows operating system. Of course, in this case, you know that your code will run only on that specific platform.

.NET 5 removes the need for .NET Standard. Actually, you may think of .NET 5 as the evolution of .NET Standard. However, .NET 5 is not a formal specification but an actual implementation. Also, the release of .NET 5 marks the end of .NET Framework.

At this point, you might ask: .NET 5 is the subsequent version of .NET Core 3.1. What happened to .NET 4?

The answer is pretty simple: there is no .NET 4! Microsoft decided to skip this version to avoid confusion with .NET Framework 4.x. So, from now on, .NET will have no more Framework, Core, Compact, or Micro.  The future of .NET will have no other qualifier than just its version.

<include src="asides/DotNetCore" />


.NET Core vs .NET Framework vs .NET Standard: A Guided Tour

brandon-roberts

Brandon is a Developer Advocate at Nrwl, focused on community engagement, content creation, and collaboration around Nx, the open-source build framework. He enjoys learning new things, helping other developers build web applications, sharing knowledge, collaborating with others, and contributing to open source. Brandon is a Google Developer Expert in Angular, a technical writer, and also a maintainer of the NgRx project building libraries for reactive Angular applications.

Developer Advocate

Brandon Roberts

Whether you have a single application or a suite of applications, code reuse, standards around structure, process, and feature development help to ensure your codebase remains healthy in the long term.

[Nx is a build framework for monorepos](https://nx.dev) with first-class React support. It helps accelerate the adoption of proven development practices across projects of many sizes and scopes. Nx provides additional tooling for React projects to help scale and develop features at a faster pace. 

This guide walks through some of the tooling provided by Nx, the creation, and structure of an Nx workspace, with an example to follow along with.

<AmpContent>
<amp-youtube
    data-videoid="IMWk0P6EeRc"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/IMWk0P6EeRc' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## What are Monorepos

A monorepo is a single collection of all your source code that spans multiple applications, libraries, and languages. Everything in the monorepo is not deployed at the same time but is all located in a central repository. Many companies use monorepos for different organizations and projects. Some even use a single monorepo to house all the source code for projects across their entire company.

Here are some of the benefits of a monorepo:

* **Shared code** &mdash; Promotes reuse of validation code, UI components, and types across the code base, including code between the backend and the frontend.
* **Atomic changes** &mdash; Make changes to a server API and modify the clients that consume that API in the same commit. No more coordinating commits across different repositories.
* **Developer mobility** &mdash; Provides consistency between building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe.
* **A single set of dependencies** &mdash; Use a single version of third-party dependencies for all your apps. Less frequently used applications don’t get left behind with a 3-year-old version of a framework library or an old version of a build tool. 

There are also a few common misconceptions with monorepos:

* Strictly co-locating your code just by placing all your code in the same repository.
* Running all the builds, tests, and quality checks on all applications for each PR or commit.
* Deploying every application on every commit to the main branch.
* Setting up multiple scripts across applications to handle common tasks.

Just because you have all your code in a monorepo, that does not mean you have run all the tests and checks on your monorepo for every single commit. This doesn't scale well and leads to bottlenecks in your development and Continuous Integration (CI) and Continuous Deployment (CD) pipelines. Nx provides integrated tooling to intelligently determine what needs to be run through code analysis, affected commands, and computation caching. 

### Affected commands

Nx uses code analysis to build a dependency graph of all projects in the workspace. It then uses the dependency graph to determine what projects are impacted based on your changes between your Git branches and the main branch. [Nx’s Affected Commands](https://nx.dev/latest/react/core-concepts/mental-model#affected-commands) use this code analysis to perform the minimum set of tasks based on what's changed. Let’s look at two applications that depend on a library as an example.

![](https://images.ctfassets.net/23aumh6u8s0i/3Msqcbm3M7zreqA7s3Yga/fa9a14ab5dd0970d45ff8603494a2530/Uploaded_from_Streamlining_a_React_Monorepo)

To see what applications are affected, use the **[nx affected:apps command](https://nx.dev/latest/angular/cli/affected-apps)**. Nx analyzes the nature of the changes and determines which projects, including applications and libraries, are impacted. In the example above, changing app1 doesn’t cause app2 to be impacted, so you don’t need to run all the pre-merge steps for app2. Alternatively, changing the lib, or packages that both apps depend on does impact both applications.

### Computation caching

Nx is smart in that it also knows the context in which you ran particular commands, the current hash of the files, and other environmental information. 

![](https://images.ctfassets.net/23aumh6u8s0i/1gsO5lGTZaluzgHVc3H3xr/f931ae116060c2def80962a764b4888b/Uploaded_from_Streamlining_a_React_Monorepo)

The image above displays an example of the information collected to build a unique hash used to identify the computation. With this information, Nx caches and stores these computations and can replay them if it seems the same computation is being run again.

This isn’t done through rebuilding source code. Only the artifacts produced from a given command are stored and replayed when possible. If Nx doesn’t find this computation, Nx runs the task, and after it completes, it takes the outputs and the terminal output and stores it locally (and if configured remotely). All of this happens transparently, so you don’t have to worry about it.

## Creating an Nx Workspace Using a React Preset

Now that you know how Nx works, let’s try it out by building a small application that lists Star Wars characters.

Start with creating the Nx workspace with a React application using the `react` preset. 

```sh
npx create-nx-workspace sw-org --preset react --appName myapp
```

After running this command, you’ll be asked to select a stylesheet format. You can choose the default for this demo. You also have the option to connect your workspace to [Nx Cloud](https://nx.app/) if you’d like.

After you make your selections, this command does the following:

- Generates a new Nx workspace
- Scaffolds out a new React application with modern tooling, including [Jest for unit tests](https://jestjs.io/), and [Cypress for E2E tests](https://www.cypress.io/).

There are other presets available, such as `next` for [Next.js](https://nextjs.org/) projects, and `react-express` for a workspace with React and Express pre-configured.

Every Nx workspace has a file structure similar to this:

```treeview
myorg/
├── apps/
├── libs/
├── tools/
├── workspace.json
├── nx.json
├── package.json
└── tsconfig.base.json
```

* `/apps/` contains the application projects. This is the main entry point for each runnable application.
* `/libs/` contains the library projects. Each library defines its external API so that boundaries between libraries remain clear. 
* `/tools/` contains scripts that act on your codebase.
* `/workspace.json` contains the configuration for each project in your workspace.
* `/nx.json` adds extra information about projects, including implicit dependencies and tags that can be used to restrict the ways projects are allowed to depend on each other.
* `/tsconfig.base.json` sets up the global TypeScript settings and aliases.

To serve up the application, enter into the `sw-org` directory and run the `serve` command using the Nx CLI:

```sh
nx serve
```

> Note: If you don't want to install Nx globally, you can use `npx nx serve` instead.

The initial application page is displayed.

![](https://images.ctfassets.net/23aumh6u8s0i/2EUaKnrpRkLehJempAp06f/a99c92b3282e79e42b16877c98cac1c9/Uploaded_from_Streamlining_a_React_Monorepo)

## Generating a Feature Library

[Generating libraries](https://nx.dev/latest/react/structure/library-types#feature-libraries) in an Nx workspace is done by using the `generate` command with the Nx CLI. Feature libraries are used to display UI to the user, which could including routing information, and could use other libraries such as shared components.

Create one now by running:

```sh
nx generate lib people
```

**NOTE** [Nx Console](https://nx.dev/latest/angular/getting-started/console) also provides a full l GUI to run Nx CLI commands in your editor with native VSCode and WebStorm support.

## Generating a Data Access Library

A "data access" library is where functionality for fetching and storing data for a feature exists. So any services necessary to manage the quotes are placed in this library. Throughout building applications, there will be data access libraries across multiple features.

Create the data access library by running:

```sh
nx generate lib data-access
```

**NOTE** You can also create your custom generators similar to the `library` generator inside an Nx workspace. This provides more flexibility to create more standards around your development processes and guidelines. Read more about workspace generators in our [Workspace Generators](https://nx.dev/latest/angular/generators/workspace-generators) guide.

Update the data-access library to fetch the characters from the Star Wars API.

Open up `data-access.tsx` and replace it with the following:

```js
import { useEffect, useState } from "react";

export interface IPerson {
 birth_year: string;
 eye_color: string;
 films: string[];
 gender: string;
 hair_color: string;
 height: string;
 homeworld: string;
 mass: string;
 name: string;
 skin_color: string;
 created: Date;
 edited: Date;
 species: string[];
 starships: string[];
 url: string;
 vehicles: string[];
}

export interface Response<T> {
 count: number;
 next: null | string;
 previous: null | string;
 results: T[];
}

export function usePeople(page: number) {
 const [people, setPeople] = useState<IPerson[]>([]);

 useEffect(() => {
   fetch(`https://swapi.dev/api/people/?page=${page}`).then((r) =>
   r.json().then(data => data.results)
 ).then(data => {
     setPeople(data);
   });
 }, []);

 return people;
}
```

Now update the people feature at `people.tsx` to list out the characters:

```js
import { usePeople } from '@sw-org/data-access';
import './people.module.css';

export function People() {
 const people = usePeople(1);
  return (
   <div>
     <h1>Star Wars People</h1>

     <ul>
       {
         people.map(person => (
           <li key={person.name}>
             {person.name}
           </li>
         ))
       }
     </ul>
   </div>
 );
}

export default People;
```

Replace the `App` template with the `People` component

```js
import styles from './app.module.css';

import { People } from '@sw-org/people';

export function App() {
 return (
   <div className={styles.app}>
     <People/>
   </div>
 );
}

export default App;
```

Refreshing the application shows a list of characters.

![](https://images.ctfassets.net/23aumh6u8s0i/3wmVIH8Sqz1ejavorzIzsI/99c44e96e4e44149da2e72e5e328baad/Uploaded_from_Streamlining_a_React_Monorepo)

The list of characters is simple. The business and data logic is kept in libraries. As your applications grow, the number of libraries grows along with it, but the applications remain relatively small and are only used for integrating core functionality for the app to run.

## Dependency Graph

Nx knows the dependencies between projects in your workspace and can generate your dependency graph visually at any point in time. 

Run the **nx dep-graph** command to see the current state of the workspace.

```sh
nx dep-graph
```

This displays the application, E2E project, and the two libraries. 

![](https://images.ctfassets.net/23aumh6u8s0i/4oiIpWdF5wIpz6y5qJkGA4/9a8802092e0de9c1a0e5c9e25d9828d7/Uploaded_from_Streamlining_a_React_Monorepo)

**NOTE**: You can also have the dependency graph auto-refresh with the `--watch` flag.

You can also see what projects are impacted by a given change. Make a change to the App.tsx, such as removing the `className`, save, and run the **nx affected:dep-graph** command.

```sh
nx affected:dep-graph
```

This displays the **myapp** and **myapp-e2e** highlighted in red as affected projects.

![](https://images.ctfassets.net/23aumh6u8s0i/2S5DueXJUNdbbguneKUjGJ/cc397167e5dc78a1835ab2db57b6dacb/Uploaded_from_Streamlining_a_React_Monorepo)


**NOTE:** The **myapp-e2e** application is directly tied to mapp, but is implicitly linked through the **nx.json** file. Read more about Nx configuration here.

### Using Affected Commands

Nx provides affected commands to run certain tasks against affected projects. For example, make a change to the `data-access` library, and run **nx affected:build**. 

```sh
nx affected:build
```

Nx finds the affected applications impacted by changing the **data-access **library and runs the **build** target for each one of them. That way, **only** the affected projects are built for the given change, and not every project in the monorepo. The same commands work for **test**, **lint**, and **e2e**, and others.

There is also the **nx affected** command that works with any defined target. The alias for **nx affected:build** is:

```sh
nx affected --target=build
```

This allows you to run any target based on the affected projects.

### Using Computation Caching

Along with affected commands, Nx supports[ computation caching](https://nx.dev/latest/angular/core-extended/computation-caching) to never execute the same computation twice. This computation cache is pluggable and can be distributed. Taking `**myapp`** as an example, run the build for `myapp` twice.

```sh
nx build myapp
```

When running the same command the second time without changes, you immediately get the cached results from the previous computation. The computation cache is done locally, but can also be distributed and extended to the rest of your team and organization. 

[Nx Cloud](https://nx.app) is one such option to distribute your computation cache. It includes a free tier with 5 hours of saved time per month, enterprise options, and is free for open-source projects.

## Summary

Nx provides modern tooling including code analysis, code generation, code analysis, affected commands, and computation caching to scale your application development using a monorepo.

What did we cover?

- Monorepos and why you should use one
- Nx workspace structure and standardization
- Smarter tooling with code analysis, affected commands, dependency visualization, and computation caching.

Find out more with the following resources:

* Documentation at [https://nx.dev](https://nx.dev)
* Free [Egghead course](https://egghead.io/playlists/scale-react-development-with-nx-4038) on Scaling React Development

Streamlining a React Monorepo

Lucy McGrath

Lucy is VP, Privacy at Auth0. She's a lawyer and global data privacy expert with diverse experience working with some of the world's leading media and technology companies. As Auth0’s VP, Privacy, she leads global data privacy strategy and is driven by a passion for further embedding privacy-by-design and continuing to shape our culture of privacy that starts with finding the humans that we impact every day.

VP, Privacy

Enabling Auth0 customers to comply with dynamic privacy requirements

At Auth0, our continuing mission is to secure the world’s identities so innovators can innovate. The core to delivering this mission is trust, including Auth0’s commitment to security and privacy.

Following our post in June, we are pleased to announce we have updated our Data Processing Agreement (DPA) to include the new [Standard Contractual Clauses](https://auth0.com/blog/auth0-statement-on-new-standard-contractual-clauses-issued-by-european-commission/) (“new SCCs”) to support our customers with European users. We’ve also made changes to our Subscription Agreement, including adding a direct reference to our updated DPA, and clarifying some of the language related to our personal data processing.

The new clauses and information about the changes can be found here [auth0.com/legal](http://auth0.com/legal).

All new customers can take advantage of these new terms immediately.

For existing customers – your Tenant Administrators will receive a notification about how you can transition to the updated DPA and new SCCs. If you have any questions or have not received this notification, please contact your account manager, or if you are a self service customer, reach out to the Self Service Team at [selfserviceteam@auth0.com](mailto:selfserviceteam@auth0.com).

At Auth0, we know that privacy regulation is complex and changing rapidly. We are working to help our customers respond to this dynamic and fast-paced environment by continuously improving the resources and information we make available.

Auth0 Publishes Documentation to Help with New Standard Contractual Clauses

Auth0 is preparing new documentation for its customers with European users.

At Auth0, our continuing mission is to secure the world’s identities so innovators can innovate. The core to delivering this mission is trust, including Auth0’s commitment to security and privacy.  

Auth0 welcomes the new Standard Contractual Clauses (“new SCCs”) issued by the European Commission, and is happy to see that they reflect a broader set of transfer scenarios and the European Court of Justice’s (ECJ) decision in the Schrems II case last year. 

As required by the European Commission’s decision, Auth0 will begin using the new SCCs for new customers on or before September 27, 2021 (with a goal of late July / early August). Once we have a generally available version of a new Data Processing Addendum (DPA) that incorporates the new SCCs, we will also be able to make this available to existing customers.

Once we have had an opportunity to consider final guidance on the new SCCs to be provided by the European Data Protection Board, we will update this post to summarize the transition program, including issues such as:

* Whether we anticipate making changes to our form of Subscription Agreement
* What changes we will be making to our DPA (“new DPA”)
* How existing customers will be able to transition to the new DPA and new SCCs 

During this transition period, we will continue to adhere to existing contractual obligations set out in the existing Standard Contractual Clauses (“old SCCs”) that are available [here](https://auth0.com/legal).

Lucy McGrath
VP, Privacy, and Data Protection Officer
Auth0, Inc 

Auth0 Statement on New Standard Contractual Clauses issued by European Commission

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

Nearly zero downtime now standard for Enterprise customers



**BELLEVUE, Wash. – March 3, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced its 99.99% availability service level agreement (SLA) guarantee for authentication services across all [Auth0 cloud](https://auth0.com/cloud) deployments&mdash;shared and dedicated environments. With private cloud deployments already supporting ‘four 9s’ availability, this SLA now extends to Auth0 public cloud deployments, making 99.99% a reality for all enterprise customers. 

Auth0 authenticates and authorizes more than four billion logins per month, demonstrating the scale at which its global customers operate. Whether authenticating consumers, business partners, or employees, reliability and uptime are crucial for every application&mdash;even more so for those with a continuously high volume of traffic. Any kind of downtime in high-demand applications can severely impact revenue, productivity, and brand perception. 

“We deeply understand how critical Auth0’s identity management platform is for the success of our customers’ businesses,” said Shiv Ramji, Chief Product Officer. “The 99.99% availability guarantee across all cloud deployments gives current, and future customers added reassurance of superior reliability and security, and an optimal end-user experience for all of their applications.” 

Auth0 continues to invest in improving the resilience of its platform and the reliability of its application services. While 99.99% is now a guarantee for customers on Auth0’s enterprise plan, platform uptime across Auth0’s U.S. public cloud environments in the past 12 months has been 99.999%+, or five 9s, as seen here: [https://status.auth0.com/](https://status.auth0.com/). 

More information about this reliability standard and Auth0’s cloud deployment options can be found here: [https://auth0.com/cloud](https://auth0.com/cloud). 

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

Matter for Auth0<br />
[auth0@matternow.com](mailto:auth0@matternow.com)<br />


Auth0 Guarantees 99.99% Availability on Public Cloud

adam-nunn

I'm a security and compliance professional with a passion for emerging cloud technologies. I specialize in risk, privacy regulations, and industry-standard security frameworks.

Sr. Director of Governance, Risk, and Compliance

Adam Nunn

The gold standard for data security has something to teach every business.



ISO 27001:2013 is an international security standard that lays out best practices for how organizations should manage their data. It outlines how companies should manage information security risk by creating an information security management system (ISMS). This approach demands executive leadership while embedding data security at all organizational levels. The standard is voluntary, but organizations that follow its guidelines can seek ISO 27001 certification.

ISO 27001 was developed in tandem by the [International Organization for Standardization](https://www.iso.org/standard/71670.html) (ISO) and the [International Electrotechnical Commission](https://www.iec.ch/homepage) (IEC). It was originally released in 2005 and revised in 2013, thus its full title: ISO/IEC 27001:2013.

For companies that earn ISO 27001 certification, it’s a sign of their commitment to data security. But even companies not seeking certification should pay attention to ISO 27001’s lessons.

## What Is ISO 27001?

Essentially, all the guidelines in ISO 27001 add up to one thing: a guide for creating an ISMS. An ISMS describes the structures an organization has in place to manage data, including technology, physical security, personnel policies, and organizational hierarchy that delegates responsibility for these issues.

## Why ISO/IEC 27001:2013 Matters

ISO 27001:2013 certification is an important thing to look for in any cybersecurity partner because it indicates an organization-wide commitment to security. Working with such a partner can benefit your own organization’s security. As Clause 6 states, sometimes the most effective way to deal with data security risk is to either eliminate it or outsource it to a third-party.

For example, by choosing an [identity and access management (IAM)](https://auth0.com/blog/what-is-iam/) partner to manage your user passwords, you offload some risk by not storing sensitive data on your own servers. And using an ISO 27001-certified IAM provider ([as Auth0 has done since 2018](https://auth0.com/blog/auth0-achieves-iso-27001-certification/)) sends a message to your own users and partners that your data is secure.

ISO 27001 is also the cornerstone of a growing international consensus about data security best practices. [Australia based its federal Digital Security Policy](https://blog.itgovernance.asia/blog/iso-27001-growth-in-australia-stems-from-government-initiatives) on ISO 27001. Likewise, ISO 27001 can provide guidance on how to meet the standards of other data privacy laws, [such as the GDPR](https://www.itgovernance.co.uk/gdpr-and-iso-27001), which often direct companies to it as an example of universal best practices. So if you abide by ISO 27001’s recommendations, you’re on the right track for legal compliance, not to mention improved data security.

### ISO 27001 certification

The bar for ISO 27001 certification is high. It requires intensive documentation, including a detailed risk assessment, records of internal training, audits, managerial review, and documentation of the relevant controls from Annex A. In addition, organizations that want to be certified must have their ISMS audited by an accredited body, a process that must be repeated annually.

Because ISO 27001 certification is so demanding, few companies actually undertake the certification process. Despite that, businesses of all sizes and industries should be aware of ISO 27001. It’s valuable both as a source of guidance for their own data management policies and as a way to judge potential data security partners.

![ISO 27001:2013](https://images.ctfassets.net/23aumh6u8s0i/5XIcDqEoGCzGiiAbjpf0rt/e971529afb8482b999c097c1a33aed65/iso-27001-separator-1)

## An Overview of ISO 27001:2013

ISO 27001 is divided into two sections: clauses and controls. The clauses largely serve as an introduction to the key terms and concepts, especially ISO 27001’s emphasis on information security leadership from the highest levels of an organization.

Anyone who wants to read the ISO 27001:2013 standard in full must [purchase a copy](https://www.iso.org/standard/54534.html), but here we’ll provide an overview of what the standard contains.

### ISO 27001 Clause 6: Risk Assessment

Clause 6 is especially important because it outlines how organizations should conduct a risk assessment to identify and analyze potential threats to their data security.

The fundamental questions in a risk assessment are:

* What data does the organization maintain?
* What are the potential consequences if that data was compromised, breached, tampered with, or lost?
* What are the information security risks, and what is the likelihood of them materializing?
* Who in the organization is responsible for managing these risks?

[_ISO Consultant Kuwait_](https://isoconsultantkuwait.com/2019/08/02/iso-270012013-clause-6-planning/) emphasizes how important it is to be as specific as possible when identifying risk scenarios and to identify the potential event, its effects, and its cause. They give the example of a hacker gaining access to internal systems via a brute-force attack (event), which was possible because the company doesn’t require strong passwords or use [brute-force protection](https://auth0.com/docs/attack-protection/brute-force-protection) (cause). The attacks lead to a governmental investigation and damage the company’s reputation (effect).

Once an organization has answered these questions, they can choose from several “risk treatment” options:

* Eliminate the risk (either by eliminating the data or the behavior that is putting data at risk).
* Share the risk by outsourcing to a third-party or through insurance
* Accept the risk after concluding that the threat is highly unlikely, the consequences would be minimal, or the costs of changes outweigh the potential benefits
* Control the risk to reduce the likelihood of bad outcomes

### ISO 27001 Controls

Annex A forms the bulk of ISO 27001, and it deals with the risk controls organizations can implement, based on the results of their risk assessment. ISO 27001:2013 lists 114 controls, divided into 14 categories.

#### Annex A.5: Information Security Policies
[This annex mandates](https://www.isms.online/iso-27001/annex-a-5-information-security-policies/) the creation of a written set of information security policies, published with the approval of management. These policies will collect the controls established through the rest of the annex. They must be reviewed at regular intervals or in the event of an internal or external change that would impact information security.

#### Annex A.6 Organization of Information Security
The first part of Annex A.6 concerns assigning responsibility for information security to all relevant stakeholders.
Part two specifically concerns maintaining data security on mobile devices and with remote workers.

#### Annex A.7: Human Resource Security
This section concerns ensuring that employees and contractors understand and are capable of fulfilling their obligations to data security, starting from before they are hired and ending with the off-boarding procedure.

#### Annex A.8: Asset Management
As the name indicates, this annex identifies information assets and classifies them according to the level of protection they require.

#### Annex A.9: Access Control
[Annex 9](https://www.isms.online/iso-27001/annex-a-9-access-control/) concerns a crucial element of any ISMS: controlling access to information. It’s divided into four sections, which outline the responsibilities of organizations to provision and deprovision users and implement secure login procedures, as well as the responsibility of individuals to respect IT security policies for authentication.

#### Annex A.10: Cryptography
This section concerns the proper use of encryption and how to protect cryptographic keys.

#### Annex A.11: Physical and Environmental Security
This is the longest section, with 15 individual controls, all of which deal with policies that protect an organization’s physical premises and the equipment in which it stores information.

#### Annex A.12: Operations Security
Annex A.12 includes best practices for ensuring data protection and integrity, from conducting data backups to malware prevention to maintaining internal logs.

#### Annex A.13: Communications Security
There are two sections to this annex. The first deals with maintaining internal network security, while the second addresses the security of information that leaves the organization.

#### Annex A.14: System Acquisition, Development, and Maintenance
This section mandates that information systems be analyzed with regard to their impact on security throughout their existence. It deals with the development, testing, implementation, and updates of information systems.

#### Annex A.15: Supplier Relationships
Unsurprisingly, this section concerns maintaining data security with third-party suppliers and maintaining an agreed-upon level of security.

#### Annex A.16: Information Security Incident Management
In this annex, organizations determine how they will deal with security incidents. This includes designating employees to take responsibilities for different types of events, including reporting them to authorities.

#### Annex A.17: Information Security Aspects of Business Management
Annex A.17 illustrates a bedrock principle of ISO 27001: that information security be directly tied to business outcomes at all levels. This section is devoted to minimizing business disruption by including information security in a business continuity management system.

#### Annex A.18: Compliance
Here, organizations must identify their legal and regulatory obligations to incorporate them into their ISMS.

![ISO 27001:13](https://images.ctfassets.net/23aumh6u8s0i/4hAaoLhTCKrPFSFwecyGhE/b3af0bb7fd4f0469a8ca38d69aa3820d/iso-27001-separator-2)

## ISO 27001:13 Creates Trust for Businesses and Their Partners

In a world in which data security is crucial, it can be hard to know where to begin getting your business’s house in order and equally hard to know whom to trust with your organization’s data. ISO 27001 simplifies this process by providing guidance anyone can follow, as well as a standard few can reach. For more information, [please reach out to the team at Auth0](https://auth0.com/en/contact-us).

<include src="asides/AboutAuth0" />


What Is ISO 27001:2013? A Guide for Businesses

Pamela Dingle joins the show to discuss how standard organizations operate, and how the industry is evolving.



## The Overview

In this episode of Identity, Unlocked, host Vittorio Bertocci, principal architect at Auth0, is joined by Pamela Dingle, Director of Identity Standards at Microsoft and a founding member of Women in Identity. Pamela has been working with identity standards and related organizations for a long time: in this episode, she sheds light on the fundamental value proposition of open standards, how standard organizations operate, and how the industry is evolving. 

Standards are the main mechanism through which we harness collective intelligence and avoid continuously reinventing the wheel, as Pamela masterfully states before launching in a historical review of how the world of identity standards evolved. Starting with cornerstone standards such as LDAP and SAML, and associated standard bodies such as the Liberty Alliance, Pamela and Vittorio reminisce about a time in which only large companies had a say on industry standard’s direction. The discussion quickly branches out, moving toward organizations such as IETF and the OpenID Foundation responsible for the main modern standards (such as the OAuth 2.0 and OpenID Connect families of specs) we work with today. Throughout the chat, Pamela provides her perspective on concrete aspects of working on standards such as driving consensus while being inclusive of diverse perspectives, the fine balance between extensibility and strict guidance every standard strives towards, and more.

As the episode ends, Pamela discusses Women in Identity, where she serves as a director. Women in Identity is a non-profit organization creating identity solutions for and built by everyone. They’re working to drive a more diverse workforce in the digital identity industry. Their membership is open to women and their allies. 

## Highlights 

**[3:55]** - What are identity standards? 

The cast of characters mentioned here includes Anthony Nadalin ([@drsecure](https://twitter.com/drsecure)), Dale Olds ([@daleolds](https://twitter.com/daleolds)), and Mark Wahl ([@markwahl](https://twitter.com/markwahl)).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0308906d&embed=true"></iframe> 


**[6:12]** - How did identity standards come into practice? 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=73d0ab82&embed=true"></iframe> 


**[7:37]** - What is LDAP?

You can find more details about LDAP [here](https://tools.ietf.org/html/rfc4510), but nowadays, chances are you won’t run into any situation requiring you to know so much about it.
<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0147dbc8&embed=true"></iframe> 


**[16:05]** - What is IETF? 

The IETF site, at [https://www.ietf.org/](https://www.ietf.org/), reflects the incredible breadth of the organization’s scope, which concerns itself with all things internet hence goes well beyond Identity. All the OAuth related activity (specs, smiling list traffic, etc.) can be found at [https://datatracker.ietf.org/wg/oauth/about/](https://datatracker.ietf.org/wg/oauth/about/).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0cd38fe6&embed=true"></iframe> 


**[20:37]** What is the OpenID foundation?

The OpenID foundation can be found at [https://openid.net/foundation/](https://openid.net/foundation/). If you want to go straight to the specs, you’ll find them on [https://openid.net/developers/specs/](https://openid.net/developers/specs/).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/2475502a"></iframe> 


**[32:50]** - What is Women in Identity? 

Women in Identity’s home page is on [https://womeninidentity.org/](https://womeninidentity.org/) - you can follow them on twitter at [https://twitter.com/WomeninID](https://twitter.com/WomeninID).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/527e6dfc?clip=0cd38fe6&embed=true"></iframe> 

## Links/Resources

Learn more about [Pamela Dingle](https://www.linkedin.com/in/pameladingle/)<br />
Learn more about [Women in Identity](https://womeninidentity.org/)<br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
Vittorio Bertocci on [Twitter](https://twitter.com/vibronet)<br />

Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)<br />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked... Explained | Episode 3

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



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

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

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

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

## The Contents of the OpenID Connect Handbook

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

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

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

## Introduction

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

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

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

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

## OpenID Connect Introduction

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

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

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

## OpenID Connect in Action

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

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

## OpenID Connect and Traditional Web Applications

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

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

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

## Traditional Web Apps and the Delegated Authorization Flow

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

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

## OpenID Connect and Single-Page Applications

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

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

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

## Conclusion

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

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

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

<include src="asides/AboutAuth0" />


The OpenID Connect Handbook

auziros:mckenzie-mayer

Customer Identity (CIAM) Product Comms lead, driving collective storytelling across Okta and Auth0. Making technology accessible for everyone.

Customer Identity Product Comms Lead at Okta

McKenzie Mayer

Auth0 provides global community of 30 million developers, educators, and businesses with simple, secure identity management


**LONDON - July 29, 2019 -** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced it has been selected as the identity management platform of choice for Arduino®, the world's leading open-source hardware and software ecosystem. With a global community of 30 million "makers", [Arduino](https://www.arduino.cc/) will use Auth0 to replace its own Single Sign On solution for all of its public facing web properties, including Arduino Create and community apps.

Arduino is on a mission to enable anyone to innovate by making complex technology simple to use. Its simple and accessible electronic boards, open-source software, and user community have powered thousands of projects, [from everyday objects to complex scientific instruments](https://create.arduino.cc/projecthub). Educational institutions around the world also use Arduino as a resource for STEAM programmes &ndash; integrating Science, Technology, Engineering, Arts, and Math.

Arduino discovered its homegrown authentication solution would not scale to meet the rapidly developing needs of its growing global community, and reached out to Auth0. In addition to Single Sign On, Arduino will take advantage of Auth0's new [Universal Login](https://auth0.com/docs/universal-login), which enables developers to completely customise their branded authentication experiences quickly, and [Device Flow](https://auth0.com/device-flow/) for browserless or input-constrained devices.

"We wanted a robust platform to replace our SSO solution but also give us the flexibility to do cool, new things in the device authentication space. Auth0 is a brand we admire, and their API-based approach makes it easy to migrate our login data in a way that's completely transparent for the customer," said Gianluca Varisco, CISO at Arduino. "We are excited to welcome them to our global community."

Auth0 and Arduino plan to leverage the combined power of their communities and events, and explore a technical partnership in the IoT domain. Auth0 currently secures more than 2.5 billion logins per month for 21 million users.

"I have been using Arduino for years as the brain for my personal projects, so working with them in a business capacity is really rewarding," said Eugenio Pace, CEO and co-founder of Auth0. "When you empower the developer with simple, powerful tools, the whole business benefits. We are excited by the reach of the Arduino community and aligned in our mission to help the developer in their journey to innovate."

<include src="asides/AboutAuth0" />

### Media Contacts:

Mark Fowler<br/>
Racepoint Global for Auth0, EMEA<br/>
[auth0@racepointglobal.com](mailto:auth0@racepointglobal.com)<br/>
+44 (0) 77 1124 4113


Arduino Selects Auth0 as Standardized Login for Open-Source Ecosystem

4 hours of video classes on identity, architecture, and standards.


**TL;DR**: Every new technical hire at Auth0 goes through two days of technical onboarding. Today we are making the lecture portion of that training available to everyone, for free.

<include src="TweetQuote" quoteText="Take a guided deep dive into the complexity of identity with Auth0 Principal Architect @vibronet. 4 hours of our technical onboarding lectures — for free!"/>

## Understanding Identity: The Journey of New Auziros

Identity is complex. When you identify the job to be done, the particular task you want to accomplish, providers such as Auth0 can make it possible for you to add authentication and other identity-related functionality at the flip of a switch: you no longer experience the complexity, but the complexity never disappears. It has now transferred to the provider, who must thoroughly analyze the task you want to accomplish and make sound decisions about what's the most appropriate protocol flow to use, what reasonable defaults should be selected, what values should be hidden from view and what controls should be surfaced as configurable, what security measures are warranted... and many, many other design, planning and implementation aspects. Our customers don't need to sweat the details, but we do... and as a general rule, [the easier the experience you enjoy](https://auth0.com/blog/the-developer-first-identity-platform-auth0-story-and-future/), the more work has been poured into it behind the scenes.

One inescapable implication of the aforementioned situation is that the Auth0 personnel must have identity competence (what I often call the "identity IQ") that goes wide and deep: on fundamentals, traditional aspects (to know how to integrate with existing systems) and modern approaches. That's a kind of competence that isn't common on the market, especially if you compound it with the robust orientation toward developers of our offering and culture.

And yet, grow we must... Auth0 has been growing at a significant pace, [continuing to double in growth and revenue year-over-year](https://auth0.com/blog/auth0-closes-103m-in-funding-passes-1b-valuation/), and to sustain that growth we need to acquire talent that, while meeting our high bar (did I mention we are hiring? Take a look [here](https://auth0.com/careers)), doesn't always bring as dowry the deep identity IQ we need to develop and operate our service. Faced with this conundrum, we didn't have much choice but to devise ways to teach identity to our new hires.

## Why We Are Making Our Technical Onboarding Available

If you've been working in this space for a while, you know that this can be real tricky. Identity IQ isn't just learning by rote the name of the protocol artifacts and what knobs to turn in dashboards and SDKs to achieve a certain effect. True competence is mostly demonstrated when making decisions. Every day, Auth0 employees must make sound decisions on how to model specific scenarios, how to represent real world entities in the protocol artifacts with the most fitting characteristics, what attack surface will come with a particular architecture, and so on. Those decisions must withstand the test of time, must gel with prior art, must gracefully scale when necessary, and all the other good properties one expects from solid engineering practices. 

With all of that in mind, we examined the available literature on identity and development. **Although there is a lot of good content out there, most of it was either too protocol centric** (describing the protocol as a thing in itself, rather than a tool for solving real life problems), too scenario specific (not explicitly connecting the dots between development practices and protocol choices) or quite outdated. Given the strategic importance of keeping our identity IQ high, we decided to bite the bullet and... develop the content ourselves.

Every new Auziro (our nickname for Auth0 employees) begins his or her journey with few days of in-person training in our Bellevue headquarters. We started running classes once a month, experimenting with different formats and content &mdash; and eventually converged in the current course: a two days full-immersion class of heavily interactive lectures, punctuated by hands on labs designed to give attendees first hand experience of the theory learned up to that point.

![A photo of the Auth0 Technical Employee Onboarding ran by Vittorio Berttoci](https://images.ctfassets.net/23aumh6u8s0i/7AX2WwJamW3XgdceZ6rXAB/cd8830b5d3475a209c9f6c9d1040f966/technical-onboarding-auth0-vittorio-bertocci-2)

The feedback has been consistently positive, and the course proved to be very effective in equipping people not just with essential knowledge, but with the right command of the terminology and fundamentals necessary to understand the literature out there and contextualize new knowledge. This is now established practice and a staple of starting one's journey with Auth0. And for the cases where logistic doesn't work and a trip to Bellevue isn't feasible, we pre-recorded all lectures in professional videos for a self paced experience. Hold this thought, as I will come back to it shortly.

After few months of successes, someone had the idea to experimenting with delivering the class to customers and partners. I have to admit that at first I was skeptical &mdash; isn't Auth0 job to take on the burden of complexity, why should I bother the customer with the reasons behind the use of Nonce or why PKCE is necessary when using the system browser? Would they even care?

As it turns out, I was dead wrong &mdash; they cared A LOT. We delivered classes in London and Bellevue, Copenhagen and Oslo. In all cases, we filled the room with CTOs, architects, star developers and in general people whose responsibilities include making medium and long term strategy decisions for their company. They all gave glowing feedback, with some of them admitting that the class finally helped them to fully understand some aspects of the protocols and practices that they never managed to crack before. Some other shared that they've been looking for similar content for a long time, but they weren't able to get quite what they needed- until now.

"Some of the information I received today contradicts with our assumptions within the team about OAuth standards. Most of the information received will help me and the team make better decisions about auth flows." &ndash; Architecture Lead, Global Travel Aggregator

"Very useful. I work with a lot of businesses where identity is always a key part and not only has it given me more confidence and knowledge of Auth0 but in identity as a topic as well." &ndash; Partner, Cloud Architecture consultancy

"We had a great discussion. It's not every day that I get to talk so geekily in-depth with an acknowledged thought-leader in identity." &ndash; Distinguished Architect, B2B software multinational

Which brings us to today. Given the positive feedback we received, we decided to open up access to our classes to anyone. If you navigate to [https://auth0.com/docs/videos/learn-identity/](https://auth0.com/docs/videos/learn-identity/), you'll find the complete collection of identity lectures we recorded for our technical onboarding &mdash; available to you **for free**.

## The Identity Course

The lectures you find at <https://auth0.com/docs/videos/learn-identity/> are meant to help the viewer gain deep understanding of OAuth2 and OpenID Connect, down to the use specific parameters in particular messages of a given grant. Unlike a lot of the protocol content you might have consumed in the past, however, the course refers to scenarios and problems to be solved as highest order bit. Instead of hitting you with the laundry list of all the artifacts described in the specifications, the course introduces the concepts required to solve a specific problem only when the scenario requires it. This helps with understanding the whys behind each choice, and positions each artifact in the right context &mdash; providing obvious explanations for otherwise baffling things that neophytes are usually forced to swallow as articles of faith, such as why one goes to authenticate to the authorization endpoint, or why a web site is called a client even when it's clearly the resource we are gating access to.

The other side of the coin is that every explanation builds on the concepts already covered, hence to get the most from the class the content should be consumed sequentially and without skipping any part.

![An image of Auth0 Docs Learn Identity homepage](https://images.ctfassets.net/23aumh6u8s0i/PdtPHtKHxiudV6PLeXyic/e40723969ec9b0bd62d1ab0a8cfb4a61/learn-identity-homepage)

The content is really designed to be interactive, for classes under 20 people &mdash; where it's not uncommon to have 15 mins detours to dig in some specific scenario that happens to be of interest for a particular cohort; that is also the reason for which the slides supporting the narration are all designed to be rearranged on the fly, by dragging clipart around and scribbling on screen whatever impromptu explanation the discussion requires.

We clearly cannot offer the same dynamic in pre-recorded videos; however we compensate for that by providing very granular bookmarks. Each concept and subtopic has been indexed and surfaced in form of link below the video, allowing you to form an idea at a glance of the specific points being discussed, and to jump directly to the right time in the narration. We observed this to be particularly useful when reviewing the material and looking for a quick refresher. In fact, we made sure to make every bookmark available as an absolute URL &mdash; we envision using those as references during discussions, posts on forums, tweets and any context requiring a bite size explanation of specific identity concepts.

![An image of a Learn identity video's table of contents](https://images.ctfassets.net/23aumh6u8s0i/WyeKuRsWLvONjIXkk0YCm/c884377cb1ad30d17c7c179a91ee33b6/auth0-learn-identity-video-and-bookmarks)

As of today, we cover the following topics:

-   [An intro to the history of protocols &mdash; how the modern protocols came to be, what problems they were meant to originally solve, and how they emerged in response of the main challenges of each era](https://auth0.com/docs/videos/learn-identity/01-introduction-to-identity)

-   [A 20,000 ft meta-view of OAuth2 and OpenID Connect](https://auth0.com/docs/videos/learn-identity/02-oidc-and-oauth)

-   [Using OpenID Connect for implementing web sign on in a traditional web app](https://auth0.com/docs/videos/learn-identity/03-web-sign-in)

-   [Using OAuth2 for gaining delegated access to an API from a traditional web app](https://auth0.com/docs/videos/learn-identity/04-calling-an-api)

-   [Using OAuth2 and OpenID Connect to invoke API from native clients (mobile, desktop, etc)](https://auth0.com/docs/videos/learn-identity/05-desktop-and-mobile-apps)

-   [Using OAuth2 and OpenID Connect to invoke API from SPAs (including a discussion of the implicit vs code+PKCE)](https://auth0.com/docs/videos/learn-identity/06-single-page-apps)

The discussion starts extremely high level, but quickly dives deep - grants are picked for their ability to solve an abstract scenario, but are examined down to the network traces level. No concept is ever presented in isolation, but always annotated with the whys behind it and the implications of choosing one approach vs another. The highest order bit remains equipping the viewer to make good decisions.

<include src="TweetQuote" quoteText="Free access to Auth0 technical onboarding lectures with Principal Architect @vibronet!"/>


## What's Next

Where to go from here? 

The next step is to upload the hands on labs, so that you can taste the complete onboarding experience. We don't have an ETA to offer at this point, but it's something we'd like to do very soon.

Another likely evolution is that we might publish the course on its own web site. Today it's embedded in our documentation, a solution that allowed us to make the videos available to you quickly, however depending on your feedback we might repackage them (or updated versions) in their own space. Leave your feedback in the comments!

Finally. The fact that we published the video doesn't mean that we will not do more in-person workshops. There is a lot of value in discussing those topics in person and dig in specific areas as needed by each specific group of participants, so we'll still occasionally do pop up in-person classes around the world. If you are interested in one of those events, let us know by reaching out to an [Auth0 Resource](mailto: sales@auth0.com).

In the meanwhile, please enjoy the videos. We hope they'll help you to catch the identity bug and get passionate about identity as much as we all are here at Auth0!

[Learn Identity](https://auth0.com/docs/videos/learn-identity/)


Introducing Learn Identity!

Auth0 announces its compliance with the Payment Card Industry (PCI) Data Security Standard (DSS). Learn more about what this means and the PCI Data Security Standard requirements.


**BELLEVUE, Wash. -- March 14, 2019 --** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), is pleased to announce that it has validated compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) version 3.2.1 as a "Level 1" service provider for its identity and access management services. Auth0 is one of the first identity providers in the industry to successfully undergo a third-party Level 1 PCI assessment.

The PCI DSS is a comprehensive set of standards that require merchants and service providers that store, process, or transmit customer payment card data to adhere to strict information security controls and processes. It was created by the founding brands of the PCI Security Standards Council, which includes American Express, Discover Financial, JCB International, MasterCard Worldwide, and Visa Inc. The standard includes twelve requirements that include the following information security topics:

- Security management
- Policies and procedures
- Physical security
- Network architecture
- User access management
- Network and systems monitoring
- Software development

The PCI Data Security Standard requires that any merchant that outsources the transmission, processing, or storage of payment card data to a third-party provider verify that the provider adheres to the standard. As a leading provider of identity and access management to merchants, Auth0 has proactively met this obligation to its customers.

"Modernization within the payments industry is creating exciting innovation in application development," said Joan Pepin, CISO and VP of Operations at Auth0. "With this modernization comes an even more critical need to protect sensitive payment card information. We are excited to achieve PCI Compliance and provide this added security assurance to our global customers."

The assessment was performed by Schellman & Company, LLC ([www.schellmanco.com](http://www.schellmanco.com/)), a globally accredited Qualified Security Assessor (QSA) firm that provides assurance and compliance services to global companies. The scope of the assessment included the applicable requirements of version 3.2 of the PCI Data Security Standard for validation of "Level 1" service providers. Following the completion of the assessment, a Report on Compliance was issued to reflect Auth0's full compliance with the PCI Data Security Standard.

For more information about the PCI Data Security Standard, please visit the PCI Security Standards Council website located at[  www.pcisecuritystandards.org](http://www.pcisecuritystandards.org).

<include src="asides/AboutAuth0" />

### **Media Contacts:**

Kasia Hall<br/>
Matter for Auth0<br/>
[khall@matternow.com](mailto:khall@matternow.com)<br/>
971-246-7898


Auth0 Successfully Completes PCI Data Security Standard Validation for Identity and Access Management

ramiro

I am an internet guy who loves reading and asking questions—those are the two things that helped me the most as an autodidact 🤓. If I am not learning about the latest trends in digital marketing or listening to house music, you can probably find me watching a tennis tournament. And also, I manage Social Media at Auth0 ✌️

Manager, Social Media

Ramiro Nunez Dosio

Our 10 most-popular identity posts in 2018 ranging from auth standards to web authentication.



Time flies when you are having fun. It's December already and we are getting ready to wrap up this year. 2018 was a prolific year for the Auth0 blog: we published more than 200 posts (😱) where we tackled a diverse amount of topics: frontend and backend technologies, data breaches, GDPR, Cybersecurity, Company Culture, and of course, Identity.

We believe looking back is key to look ahead. That is why this week, we are going to take a look back at the best and most impactful posts we have published in 2018.

One article wouldn't be enough to review this amazing year, that's why we have decided to split this year in review into 3 parts: [Developer Posts](https://auth0.com/blog/10-most-popular-developer-posts-in-2018/), [Security Posts](https://auth0.com/blog/10-most-popular-security-posts-in-2018/), and Identity Posts.

Without much further ado, here's the roundup of our 10 most-popular Identity posts this year!

![Auth0's 10 Most-Popular Identity Posts](https://images.ctfassets.net/23aumh6u8s0i/2PZojrBsthRTB6sKxDI0nw/cf5db7303eafa89f7ef46b4bc5f05e81/identity-posts)

## Auth0's 10 Most-Popular Identity Posts in 2018

> The following posts are not listed in any particular order.

1. <a href="#an-overview-of-open-standards" target="_self">An Overview of Open Standards</a>
2. <a href="#3-iam-examples-to-support-digital-transformation" target="_self">3 IAM Examples to Support Digital Transformation</a>
3. <a href="#a-look-at-the-draft-for-jwt-best-current-practices" target="_self">A Look at The Draft for JWT Best Current Practices</a>
4. <a href="#introduction-to-web-authentication-the-new-w3c-spec" target="_self">Introduction to Web Authentication: The New W3C Spec</a>
5. <a href="#how-to-have-a-successful-idm-project" target="_self">How To Have a Successful IDM Project</a>
6. <a href="#how-to-have-a-successful-idm-project-part-2" target="_self">How To Have a Successful IDM Project (Part 2)</a>
7. <a href="#on-the-nature-of-oauth2s-scopes" target="_self">On The Nature of OAuth2’s Scopes</a>
8. <a href="#hashing-passwords-one-way-road-to-security" target="_self">Hashing Passwords: One-Way Road to Security</a>
9. <a href="#adding-salt-to-hashing-a-better-way-to-store-passwords" target="_self">Adding Salt to Hashing: A Better Way to Store Passwords</a>
10. <a href="#how-utilities-can-use-ciam-to-avoid-3-common-problems" target="_self">How Utilities Can Use CIAM to Avoid 3 Common Problems</a>

## <a name="an-overview-of-open-standards"></a>1. [An Overview of Open Standards](https://auth0.com/blog/an-overview-of-open-standards/)

In this overview, we will go over what open standards are and why they matter. We will also go over the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML. Open standards are important to understand but one can easily get overwhelmed by the technical specifications.

<include src="ClickImg" externalUrl="https://auth0.com/blog/an-overview-of-open-standards/" imgUrl="https://cdn.auth0.com/blog/10-most-popular-identity-posts-in-2018/open-certificationpng.png" altText="Open Certification" imgWidth="560" imgHeight="560"/>

## <a name="3-iam-examples-to-support-digital-transformation"></a>2. [3 IAM Examples to Support Digital Transformation](https://auth0.com/blog/3-iam-examples-to-support-digital-transformation/)

From basic website authentication to implementing an OpenID Connect server and API authentication: This article covers 3 IAM examples to support your Digital Transformation.

<include src="ClickImg" externalUrl="https://auth0.com/blog/3-iam-examples-to-support-digital-transformation/" imgUrl="https://cdn.auth0.com/blog/iam-digital-transform/sso-data-model.png" altText="SSO Data Model" imgWidth="714" imgHeight="559"/>

## <a name="a-look-at-the-draft-for-jwt-best-current-practices"></a>3. [A Look at The Draft for JWT Best Current Practices](https://auth0.com/blog/a-look-at-the-latest-draft-for-jwt-bcp/)

In this post, we will take a look at the draft for the JWT Best Current Practices document. This document describes common pitfalls and attacks related to the use of JWTs, and how to implement mitigations against them. Read on!

<include src="ClickImg" externalUrl="https://auth0.com/blog/a-look-at-the-latest-draft-for-jwt-bcp/" imgUrl="https://cdn.auth0.com/blog/jwt-bcp/Substitution-Attack-Different-Recipient.png" altText="Different Recipient JWT Substitution Attack" imgWidth="590" imgHeight="492"/>

## <a name="introduction-to-web-authentication-the-new-w3c-spec"></a>4. [Introduction to Web Authentication: The New W3C Spec](https://auth0.com/blog/introduction-to-web-authentication/)

Web Authentication brings a stronger authentication mechanism to the masses by defining an API that both authenticators and web browsers can implement. Learn why Google, Paypal, Mozilla, and others back it up.

<include src="ClickImg" externalUrl="https://auth0.com/blog/introduction-to-web-authentication/" imgUrl="https://cdn.auth0.com/blog/webauthn/1-Web-Authentication-Entities.png" altText="Web Authentication Entities" imgWidth="617" imgHeight="409"/>

## <a name="how-to-have-a-successful-idm-project"></a>5. [How To Have a Successful IDM Project](https://auth0.com/blog/how-to-have-a-successful-idm-project/)

Learn how to create a realistic project plan to have a good Identity Management project deployment.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-to-have-a-successful-idm-project/" imgUrl="https://cdn.auth0.com/blog/good-idm-project/enabling-mfa.png" altText="Eanbling Multi-factor Authentication (MFA) from Auth0" imgWidth="617" imgHeight="361"/>

## <a name="how-to-have-a-successful-idm-project-part-2"></a>6. [How To Have a Successful IDM Project (Part 2)](https://auth0.com/blog/how-to-have-a-successful-idm-project-part-2/)

Learn how to plan for failures and changes in your identity project.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-to-have-a-successful-idm-project-part-2/" imgUrl="https://cdn.auth0.com/blog/how-to-have-a-successful-idm-project-part-2/resetting-a-users-multi-factor-account-with-auth0.png" altText="Resetting a user's multi-factor account" imgWidth="617" imgHeight="439"/>

## <a name="on-the-nature-of-oauth2s-scopes"></a>7. [On The Nature of OAuth2’s Scopes](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/)

Auth0 Principal Architect and Identity expert Vittorio Bertocci on why using OAuth2 scopes in every authorization scenario is not a good idea.

<include src="ClickImg" externalUrl="https://auth0.com/blog/on-the-nature-of-oauth2-scopes/" imgUrl="https://cdn.auth0.com/blog/on-the-nature-of-oauth2-scopes/oauth2-scopes-mail-api.png" altText="OAuth2 Scopes Mail API exmaple" imgWidth="617" imgHeight="280"/>

## <a name="hashing-passwords-one-way-road-to-security"></a>8. [Hashing Passwords: One-Way Road to Security](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/)

A strong password storage strategy is critical to mitigating data breaches that put the reputation of any organization in danger. Hashing is the foundation of secure password storage.

<include src="ClickImg" externalUrl="https://auth0.com/blog/hashing-passwords-one-way-road-to-security/" imgUrl="https://cdn.auth0.com/blog/hashing-one-way-road-to-security/hash-flow.png" altText="Hashing algorithm flow example - one-way" imgWidth="617" imgHeight="340"/>

## <a name="adding-salt-to-hashing-a-better-way-to-store-passwords"></a>9. [Adding Salt to Hashing: A Better Way to Store Passwords](https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/)

A salt is added to the hashing process to force their uniqueness, increase their complexity without increasing user requirements, and to mitigate password attacks like rainbow tables

<include src="ClickImg" externalUrl="https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/" imgUrl="https://cdn.auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/password-salt-example.png" altText="Example showing how using a salt with hashing produces unique hashes." imgWidth="617" imgHeight="277"/>

## <a name="how-utilities-can-use-ciam-to-avoid-3-common-problems"></a>10. [How Utilities Can Use CIAM to Avoid 3 Common Problems](https://auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/)

Customer identity and management technology helps utilities reshape how they interact with users, improve their services, and tighten security.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/" imgUrl="https://cdn.auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/progressive-profiling-flow.png" altText="Utility customer progressive profiling flow" imgWidth="617" imgHeight="303"/>

## What's Next?

We are already preparing our content pipeline for 2019. Identity and digital transformation are key areas that will keep businesses evolving to tackle challenges around privacy, usability, growth, and sociopolitical policies. We are committed to keep our content relevant to these changes and offer effective solutions through our products and services.

We'd like to take this opportunity to thank all of our readers for their consistent support and feedback. Is there anything that you'd like us to cover in 2019? Any particular identity topic or trend? Please let us know in the comments below or through social media ([Twitter](https://twitter.com/auth0), [LinkedIn](https://www.linkedin.com/company/auth0)). As always, you can subscribe to our newsletter to receive a weekly digest of our blog content.

Happy Holiday Season!

<include src="asides/AboutAuth0" />


10 Most-Popular Identity Posts in 2018

kapehe-jorgenson

Kapehe is an R&D Content Engineer for Auth0 with a passion for learning and teaching. With her primary focus on ReactJS and JavaScript, she is impressed with what code can create for the web. Technology and web development are constantly evolving and naturally bring that need for continual learning. She enjoys writing tutorials, hosting local meetups, and learning with others to expand coding knowledge.

R&D Content Engineer

Kapehe Jorgenson

A brief overview of the top identity open standards used today.



**TL;DR:** In this overview, we will go over what open standards are and why they matter. We will also go over the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML. Open standards are important to understand but one can easily get overwhelmed by the technical specifications.

<include src="TweetQuote" quoteText="An overview of the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML."/>

## What is an Open Standard?
Identity, and the infrastructure that goes behind making identity **secure**, **lightweight**, and **reliable**, can be a challenge, one that can take up a lot of your team’s time to get just right. One way to reduce the overhead is to utilize open standards, rather than reinventing the wheel.

Open standards are community and industry-driven specifications that can define roles for an app, whether that role is the user, the identity provider, or the service provider, and how those roles talk to each other. Standards also define how apps are able to communicate with each other and to service providers. This can all happen without compromising key details or code.

Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits. 

The formation of open standards has created a uniform way of expressing the fundamental keys of identity across the industry, while still allowing flexibility around the specific path of implementation.

<include src="TweetQuote" quoteText="Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits."/>

### Open Standards You May Know

Modern web development relies on a range of well-known open standards that you may already be familiar with. They cover many facets of web development, from **JSON** (JavaScript Object Notation), used to structure data in a readable format, to **HTML** (HyperText Markup Language), used for creating web pages, all the way to **SAML** (Security Assertion Markup Language),  which is used for enterprise identities as described below.

## Four Common Open Standards for Authentication and Authorization

### OAuth 2
OAuth 2 is the latest version of the OAuth protocol, allowing for **better authorization flow across many devices and applications**. Users can grant a third-party website limited access to their information on another website without exposing their credentials. 

OAuth 2 is one of the most widely used open standards for delegating access, one that you as a user probably see implemented often. For example, when you log in to a website that wants access to information from your Google account (i.e., contacts), you grant authorization via OAuth 2. You can find the official docs for [OAuth 2 here](https://tools.ietf.org/html/rfc6749) and view [Auth0's thorough overview of OAuth 2](https://auth0.com/blog/oauth2-the-complete-guide/).

### OIDC (OpenID Connect)
OpenID Connect is an extra identity layer built on top of OAuth 2 that specifies a process for checking a user’s identity by ensuring they are who they say they are.

> OIDC is able to retrieve the user’s basic profile information from the identity provider. 

For example, when a user visits a website and can log-in via Google or Facebook, that application will then go to Google or Facebook and get those user's credentials. The application then does not have to store the user's basic profile and can utilize Google or Facebook and their storage of the user's information to grant access and verify their identity.

OpenID Connect is _API-friendly_ and can be used across mobile applications, web-based applications, all JavaScript clients, and many other types of clients. OIDC also requires the use of JSON Web Tokens which we will get into next. You can find the official docs for [OpenID Connect here](https://openid.net/connect/).

### JWT (JSON Web Tokens) 
Sending information, such as user data, across many different applications can be done using **JSON Web Tokens**. JSON web tokens hash information into a long, encoded string of characters that can be broken into three parts:

* The header that declares the hashing algorithm and the token type. 
* The payload or data where you could have the name of the user or other relevant information like the token expiration time or the subject. 
* The verifying signature made up of the header, payload, and a secret all hashed together. 

The JWT can get long, but this open standard provides a straightforward way to transfer information. If you visit [jwt.io](https://jwt.io/), there is a tool there where you can put in any encoded JWT and it will decode it for you as follows:

**JWT - encoded:**

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```

**JWT - decoded:**

Header:

```json
{
  "alg": "HS256",
  "typ": "JWT"
}
```

Payload:

```json
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
```

Verify Signature:

```
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
) secret base64 encoded
```

JWTs can be verified and trusted because they have a **digital signature**. That digital signature verifies that nothing was changed while the JWT was being passed. You can find more information on [JWTs here](https://auth0.com/learn/json-web-tokens/).

### SAML (Security Assertion Markup Language)
An XML-based open standard, SAML ensures that there is a secure communication of identities between organizations. This is a great tool for businesses when they want to communicate user authentication and authorization information to other organizations that their employee may need access to. Some benefits include:

* Increased security through a single point of authentication
* Improved user experience by utilizing a single sign-on access point.
* A centralized user access control allowing for a one-stop authentication point

SAML utilizes a _SSO (single sign-on) format_. Digitally signed XML documents are passed between the business and multiple third-party entities they have partnered up with. You can find [more information on SAML here](https://auth0.com/blog/how-saml-authentication-works/).

---

## Summary

As we have learned, the flexibility of open standards allows for the identity industry to be on the same page, reduce overhead, and create a uniform way of expressing the **fundamental keys of identity**. When everyone implements a standard way of doing things, then the _flow_ over different languages, projects, and teams can go as planned with authentication and authorization.

At Auth0 we use open standards so that we can connect our product to users and clients alike in a **standard and secure** way. Identity can be tricky, but here at Auth0 you can rest assured that your users are backed by industry-defined open standards. We use open standards to provide you with a secure solution that can be implemented in a matter of minutes. We have you covered, open standards and all.

Want to continue learning about these open standards? Visit the Auth0 docs for the above mentioned open standards: 

* [OAuth 2](https://auth0.com/docs/protocols/oauth2)
* [OpenID Connect](https://auth0.com/docs/protocols/oidc)
* [JWTs](https://auth0.com/docs/jwt)
* [SAML](https://auth0.com/docs/protocols/saml/saml-configuration)

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for a free Auth0 account here</a>


An Overview of Open Standards

...or at least, they won’t as often or as thoroughly as advertised.




Open standards in identity are a good thing. An excellent thing. They’re one of the few aces in the sleeve we have in our industry for keeping complexity under control. When it comes to selecting an open source SDK, assessing whether two or more solutions can collaborate, decomposing problems and requirements into well-known patterns and units of meaning that act as a common language the industry can use to communicate and make progress — open standards are the social norm that enables all that and more.



But it’s time for industry vendors to stop bragging about their support for open standards.


For one, ***open standards are now table stakes***: Do you hear wearables suppliers brag about their support for Bluetooth, or refrigerator manufacturers boast that they can plug in your country’s power grid without adapters? *Of course* they support Bluetooth and come with standard power cord — that barely deserves a mention on the package — the battle for winning your favor is fought on completely different features. Positioning support for bleeding edge standards like token binding or [WebAuthn as a differentiating factor](https://webauthn.me/) is indeed informative, but in the year 2018 support for SAML, OAuth2, and OpenID Connect should be a given.

<include src="TweetQuote" quoteText="Use of core identity open standards should be considered table stakes, says @auth0’s @vibronet."/>


But there’s a subtler point, an epiphany I myself had only recently. Contrary to what’s commonly boasted by providers, in the general case ***open standards in identity won’t prevent vendor lock-in***.

Can open standards help to decouple you from vendor-specific considerations? You bet they can — but only for the most basic entry points in their ecosystem. When considering solving the problem of identity and access management, it’s tempting to focus on the mechanics of authentication — and once that phase is solved, consider the matter closed. If you can get a JWT from vendor A using an OpenId Connect OSS SDK, you just proved to yourself that you can likely use the same SDK to repeat the process to get a token from vendor B — hence you feel locked to neither. Think about it for a moment longer, tho. Once the demo is done and all the hands have been shaken, your developers will start working with the vendor of choice and the tokens they’ll request won’t be for proving a point —they’ll be for invoking API, which in turn represents programmatic access to data and functionality. If you look at the reality of the industry today, you’ll see that very often the vendor supplying you with support for OpenId Connect & Co is also the owner of the API you are using to access data and functionality (documents, storage, calendars, inboxes and the like, plus any hosting/serverless capabilities).


Imagine your team fully embracing those API for say a couple of years, going for the deep integration that Mr. Bezos describes [here](https://www-geekwire-com.cdn.ampproject.org/c/s/www.geekwire.com/2018/jeff-bezos-amazon-web-services-lock-never-want-customers-trapped/amp/), then deciding to switch to a new vendor. Sure, the use of OpenId Connect means that adapting your clients to requests tokens from a different source should amount to a simple string update; that’s vastly better than if you’d have to switch between proprietary systems … which incidentally, is exactly what you’ll have to do to migrate all the assets you created using the data and functionality API which are downstream from the token acquisition, use, and validation phases. Which migration task do you think will bring the highest costs and complexity, hence creating those inhibitors traditionally associated to vendor lock-in?


To be clear, I am not saying that there’s anything wrong with the above; in fact, most vendors go out of their way to make your data exportable and help with transitioning it elsewhere if you so choose. The only thing I take exception with is the statement that a vendor using identity open standards will avoid vendor lock-in, as per the aforementioned argument identity is only a fraction of the things that you’ll most likely take a dependence on from a vendor’s offering.

<include src="TweetQuote" quoteText="Find out why @auth0’s @vibronet says open standards alone in identity won’t prevent vendor lock-in."/>

Now, with all that said. There is a notable exception in which the use of open identity standards won’t lead to vendor lock-in, and it occurs in the special case in which the vendor being considered only focuses on the identity aspects of the development of your solution. In that case, there is no upsell agenda! You already know where I am going with this: Auth0 falls exactly into that category of “pure breed” providers. If a vendor only focuses on helping you to easily implement standard-based authentication flows, if that’s the only thing you are paying that vendor for, then by definition, it will be easy to use the very same standards to point your applications to a different supplier. That’s not to say that the scenario prevents the solution from *also* taking dependencies on specific features — not every aspect coming into play in identity solutions is codified in form of standard —however, it is safe to say that “pure breed” identity vendors such as Auth0 come much closer to fulfilling the promise of sparing you from hard vendor lock-in.


Open standards in identity are an excellent thing. So good, in fact, that I propose that by now use of core identity open standards should be considered table stakes, a commodity offered by everyone rather than something to brag about —along the lines of what Carr discussed in his seminal article [IT doesn’t matter](https://hbr.org/2003/05/it-doesnt-matter). Moreover, vendors should articulate the advantages of open standards without hyperbole — they carry enough advantages on their own without having to attribute them magical properties such as the ability of single-handedly avoiding vendor lock-in, without specifying the special conditions (pure identity vendor) where that boast is almost true.

Learn more and [try a WebAuthn demo crafted by Auth0, here](https://webauthn.me/).

<include src="asides/AboutAuth0" />


Open standards won’t save you from vendor lock-in

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

Learn about WebAuthn, a new standard for secure authentication on the web.


[News](https://www.engadget.com/2018/05/09/mozilla-firefox-passwords-web-authentication-support/) about [Web Authentication](https://webauthn.me/introduction), or WebAuthn for short, reaching maturity and being enabled by default in web browsers hit the headlines recently. Web Authentication is a fairly recent W3C standard backed by major players like Google, Paypal, Mozilla, Microsoft, and Qualcomm. It aims at defining a web-browser API for the creation and use of strong authentication credentials based on public key cryptography. The driving force behind the proposal is to increase security for the authentication process by removing or complementing password-based authentication while remaining convenient for end-users. Although implementations are still in their early days, and the standard has not been finalized, the strong push from major players, and the fact that both Firefox and Chrome are enabling their implementations by default, are strong indicators that this may cause a significant impact in the authentication space. Let's check it out!

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

---

## Introduction
The traditional username/password scheme for user authentication has been in use for decades. Even in the face of modern approaches like social logins and [Face ID](https://en.wikipedia.org/wiki/Face_ID), username and passwords remain the most popular and widely used mechanism for authentication. Stronger authentication mechanisms such as certificates and hardware tokens have been supported for a long time for specific applications and use cases, but they remain unusual for end users.

Most of the authentication flows performed by end users are done through web browsers. In a sense, web browsers have become the nexus between credentials and applications on the two major platforms: desktop and mobile. It is natural, then, that changes to authentication flows require support from browsers. The web, however, is built on consensus. This means that changes to the platform need to be implemented by several players. For this reason, the W3C WebAuthn Working Group was formed: to produce a new specification that can be implemented by all parties and that remains interoperable.

The draft specification says:

> This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.

<include src="TweetQuote" quoteText="Web Authentication defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users."/>

To better understand Web Authentication, let's go through a quick overview.

## Web Authentication In a Nutshell
Let's take a look at the entities involved in WebAuthn:

![Web Authentication (WebAuthn) Entities](https://images.ctfassets.net/23aumh6u8s0i/5c7KKyElhmYWEPB4R8TQje/d46dec602523f6af3cb4d68b03e15232/1-Web-Authentication-Entities.png)

These entities work together in two separate use cases: **registration** and **authentication**. All communications between the different entities in the diagram are handled by the user agent (usually a web browser).

Registration makes the authenticator create a new set of public-key credentials that can be used to sign a challenge generated by the relying party. The public part of these new credentials, along with the signed challenge, can be sent back to the relying party for storage. The relying party can later use these credentials to verify the identity of a user whenever required.

![Web Authentication (WebAuthn) Registration](https://images.ctfassets.net/23aumh6u8s0i/2xxX1F2zya0XdsiCRz5dXk/3c3350168175e59b2e41be8afda3e9fd/2-Registration.png)

Authentication, in contrast, allows the relying party to send a challenge to the authenticator. This challenge can then be signed with the previously generated public-key credentials and sent back to the relying party. This way, the relying party can verify that a user is in possession of the required credentials, proving their identity.

![Web Authentication (WebAuthn) Authentication](https://images.ctfassets.net/23aumh6u8s0i/6iz4I2CXCV5CW7qNaSknTK/88fe1dd04f4bdde733d11f1fd947cfe4/3-Login.png)

Both processes work with the help of public-key cryptography and digital signatures. If you are not familiar with how public-key cryptography or digital signatures work, the important thing you must know is that there is a public key and a private key. The private key is secret, and only the user (or the authenticator) must know it. The public key, in contrast, is public and can be seen or stored by anyone. The public key can be used to verify signatures generated by the private key. No other key, other than the private key, can generate a signature that the public key can verify as valid. This way, the relying party can store a public key and use it to verify signatures performed by the user holding the private key.

Let's take a quick look at the actual API.

### API
The Web Authentication API has two main calls: [`navigator.credentials.create`](https://www.w3.org/TR/webauthn/#createCredential), and [`navigator.credentials.get`](https://www.w3.org/TR/webauthn/#getAssertion). There is also an [accessory API to list authenticators](https://www.w3.org/TR/webauthn/#isUserVerifyingPlatformAuthenticatorAvailable).

`create` can be used to perform the registration step. `get` can be used to perform the authentication step.

Here is a sample call of the `create` function inside an [EJS](http://ejs.co/) template:

```javascript
navigator.credentials.create({
  publicKey: {
    // random, cryptographically secure, at least 16 bytes
    challenge: base64url.decode('<%= challenge %>'),
    // relying party
    rp: {
      name: 'Awesome Corp' // sample relying party
    },
    user: {
      id: base64url.decode('<%= id %>'),
      name: '<%= name %>',
      displayName: '<%= displayName %>'
    },
    authenticatorSelection: { userVerification: "preferred" },
    attestation: 'direct',
    pubKeyCredParams: [
      {
        type: "public-key", alg: -7 // "ES256" IANA COSE Algorithms registry
      }
    ]
  }
}).then((res) => {
  var json = publicKeyCredentialToJSON(res);
  // Send data to relying party's servers
  post('/webauthn/register', {
    state: '<%= state %>',
    provider: '<%= provider %>',
    res: JSON.stringify(json)
  });
}).catch(console.error);
```

Here is a sample call of the `get` function in an EJS template:

```javascript
navigator.credentials.get({
  publicKey: {
    // random, cryptographically secure, at least 16 bytes
    challenge: base64url.decode('<%= challenge %>'),
    allowCredentials: [ {
      id: base64url.decode('<%= id %>'),
      type: 'public-key'
    }],
    timeout: 15000,
    authenticatorSelection: { userVerification: "preferred" },
  }
}).then((res) => {
  var json = publicKeyCredentialToJSON(res);
  // Send data to relying party's servers
  post('/webauthn/authenticate', {
    state: '<%= state %>',
    provider: '<%= provider %>',
    res: JSON.stringify(json)
  });
}).catch(err => {
  alert('Invalid FIDO device');
});
```

But the cool thing about all of this is that you don't need to care about any of it! If you use Auth0, you don't need to understand the gritty details of Web Authentication to use it.

<include src="TweetQuote" quoteText="Web Authentication at Auth0 will work with the flip of a switch!"/>

## A Working Web Authentication Implementation at Auth0
One of the cool things about our architecture is that changes in the login system can be integrated with little or no changes to client code. In other words, once our implementation of Web Authentication is released, enabling it for your apps will be a matter of making a few clicks in the [Auth0 Dashboard](https://manage.auth0.com/).

This is a proof-of-concept of how WebAuthn as a second factor will work in Auth0:

<video src="https://cdn.auth0.com/blog/webauthn/Auth0-Web-Authentication-2-small.mp4" title="Web Authentication proof-of-concept video - WebAuthn as a second factor with Auth0" controls autoplay loop></video>

What you see in this video is already working internally. We are eager to finish the implementation so you can start enabling Web Authentication in your apps.

Of course, there is more to Web Authentication than just using it as a second factor. We are also planning to enable Web Authentication as a **primary login solution**, that is, as a **passwordless login** mechanism. If you are not familiar with passwordless login and how it works, [take a look at our introduction](https://auth0.com/passwordless). Can you imagine logging in to your bank with just a push of your USB authenticator's button? <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for an Auth0 account</a> and start improving your logins today. When WebAuthn integration is ready, enabling it for your apps will be a breeze.

<include src="TweetQuote" quoteText="Web Authentication (a.k.a. WebAuthn) is backed by major players in the industry, let's find out what it's all about!"/>

## Conclusion
Web Authentication brings a stronger authentication mechanism to the masses by defining an API that both authenticators and web browsers can implement. With the release of [Firefox 60](https://www.mozilla.org/en-US/firefox/60.0/releasenotes/) and [Chrome 67](https://www.chromium.org/developers/calendar), Web Authentication has become available to a big number of users. Authenticators, such as [Yubikeys](https://www.yubico.com/), already support the necessary protocols and work with current implementations. At Auth0 we care about providing the necessary building blocks for your identity infrastructure, and Web Authentication could eventually become a major improvement in security and user experience. If you would like to use Web Authentication with Auth0 for your product, let us know in the comments, or [contact us through our "Talk to Sales" contact form](https://auth0.com/).


Introduction to Web Authentication: The New W3C Spec

Auth0 provides secure login and authentication for JDA’s retail customers



**BELLEVUE, WA -- January 8, 2018** – [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced that it has been selected by [JDA Software Group, Inc.](http://www.jda.com/), as the identity and access management (IAM) solution for its next-generation solutions that are part of JDA NEXT, such as JDA Retail.me and JDA Store Optimizer. Using Auth0’s extensible platform, JDA will provide secure and seamless information access to its users.

The JDA NEXT product strategy includes solutions that leverage edge technologies such as advanced analytics, artificial intelligence, the Internet of Things, machine learning, and SaaS to help retailers strategically plan and streamline operations around consumer buying behavior. With a need for Enterprise Federation across these solutions, JDA turned to Auth0 for its ease-of-implementation, flexibility, and compliance with modern security protocols.

“After a thorough review of competitive IAM solutions, Auth0 provided the best platform that matched our focus on flexibility and the customer experience,” said John Vrankovich, principal architect at JDA. “It was much more cost-effective for us to outsource authentication to Auth0, and the fact that it could be implemented quickly across all our next-generation JDA solutions is what sealed the deal.”

Enterprise Federation requires a great deal of time and internal resources. With increasing demand across growing business networks for fast information and the need for control over access, Auth0 has become a trusted partner to companies like JDA, that need an extensible platform that easily integrates with any combination of APIs, identity providers, protocols, custom databases, and deployment models.

“One of the primary reasons B2B organizations turn to Auth0 is Enterprise Federation. Relying on our platform allows companies to deliver results faster, more securely and efficiently than building internally, plus it eases developer resources to then focus on product innovation,” said Eugenio Pace, CEO and co-founder of Auth0. “We are very excited about working with JDA and growing with them as their far-reaching customer network continues to expand.”


<include src="asides/AboutAuth0" />


JDA Standardizes Identity and Access Management with Auth0

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

Learn why universal login is the most secure, standards-based strategy when authenticating with a provider.



**TL;DR:** To maintain a successful application, you will inevitably need a universal account system, as opposed to embedding login within your application. Universal login is more secure, standards-based, maintainable, and future proof. This is where the industry is moving, and in this post, we will explore this trend.

---

## Introduction

High standards of security and ease of use have been set for modern authentication platforms and APIs. Users expect seamless logins that work across apps and entities without requiring them to log in over and over on the same device. Companies and developers expect robust security for their data and top-notch protection for their customers, preferably without incurring intensive implementation or maintenance overhead.

### What is Universal Login?

**Universal login** refers to a [method of login hosted by the authentication provider](https://auth0.com/docs/hosted-pages/login) for your app or site. A link or button in your app triggers an authentication request and users are then presented with a login experience provided by the authentication provider. Because authentication is taking place on the same domain as the login, credentials are not sent across origins. Universal login is the most _secure_ way to authenticate users, as well as the most _standards-based_. We'll cover <a href="#why-use-universal-login" target="_self">how and why</a> in much more detail below.

### What is Embedded Login?

**Embedded login** refers to a method of authentication wherein credentials are entered via an experience that is _embedded_ on an app's domain with text inputs and are then sent to an authentication provider for verification and login. This is a _cross-origin_ request. Embedded logins present a range of potential security and implementation challenges that cause issues for developers and users; as a matter of fact, [Google no longer supports an embedded approach when implementing OAuth](https://auth0.com/blog/google-blocks-oauth-requests-from-embedded-browsers/).

### What Do Universal and Embedded Login Look Like?

![Universal vs. embedded login](https://images.ctfassets.net/23aumh6u8s0i/5lXoFh88lNEZ41N8NOORYA/35ade19a2e6603719c1338329b948174/centralized-embedded-diagram)

1. **Universal Login** - When clicking a button or link to authenticate in both the browser and native app, the universal login URL at [accounts.google.com](https://accounts.google.com) is loaded.
2. **Embedded Login** - When clicking a button or link to authenticate in the browser, an overlay modal is opened on the same domain, prompting the user to log in. The mobile app also displays input fields within the app.

## Why Universal Login is a Long-Term Investment

Let's look at a hypothetical example using a timeline from an imaginary company. Let's say our make-believe company, "SourceCentral", provides public and private source control repository hosting. Their timeline looks something like this:

![Hypothetical timeline for a service switching to universal login](https://images.ctfassets.net/23aumh6u8s0i/6wzVEf7a5UREYmGYdQ5yZl/d9a04c1906342c8ad2cb5035228fddce/timeline2)

* **Year 0: Launch!** We launched a source control repository hosting service. Our homegrown authentication is working out alright for our needs since we are still small and only have one service.
* **Year 1: Going native** Lots of people have signed up and outlook is great! People love our service. We are launching native Android and iOS mobile apps as well as desktop apps for Windows and MacOS, and we need to implement login for all of them.
* **Year 1.5: APIs** We're now developing an API so that we can better serve our customer base of developers who want to be able to integrate our service with third parties, but...
* **Year 2: Auth for third parties** Authentication has been a huge challenge now that we have an API that requires authorization as well as several apps and third-party integrations. 😧 To address the complexities and issues this is presenting, we're implementing OAuth in order to provide a much more _universal_ authentication and authorization process for our product and APIs.
* **Year 3: SSO** With a universal login approach, we're now able to leverage Single Sign-On. Our customers love this. This was easy with a universal login; instead of having to change every single service, we only had to do it once! It's much easier to maintain and enhance.
* **Year 4: Multi-factor Authentication** Our users demand more security, so we're adding Multi-factor Authentication. We can do this for all our apps at once using universal login!
* **Years 5, 6, etc: Growing and scaling!** We're rolling out new properties and apps at a steady pace. We have a desktop app, a community, chat hosting for repositories, and several other services as well. Securing and authenticating all our new services is a non-issue with universal authentication! 🎉

This is a hypothetical timeline, but many companies have undergone very similar processes over the years, including (in case you haven't already guessed!) [GitHub](https://github.com). Implementing universal login is a long-term investment. Doing so _early_ paves the way for growth, development, maintainability, and new feature integration far into the future.

<include src="TweetQuote" quoteText="Universal login is a long-term investment. Implementing early paves the way for growth and new feature integration far into the future."/>

## <span id="why-use-universal-login"></span>Why Universal Login is Best Practice

Universal login has many advantages over an embedded login approach, including better security, single sign-on benefits, simpler maintainability, modern user experience, and more. Let's explore these in more detail.

<include src="TweetQuote" quoteText="Universal login provides security, SSO, maintainability, best practice native app implementation, and more."/>

### Security

Universal login is more secure than embedded login. Authentication takes place over the same domain, eliminating cross-origin requests. Cross-origin authentication is inherently more dangerous. Collecting user credentials in an application served from one origin and then sending them to another origin can present certain security vulnerabilities. [Phishing attacks](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/) are more likely, as are [bucket brigade attacks](https://auth0.com/docs/security/common-threats#man-in-the-middle-mitm-attacks), also known as man-in-the-middle (MITM) attacks. Universal login does not send information between origins, thereby negating cross-origin concerns.

Embedded user agents are unsafe for third parties, including the authorization server itself. If an embedded login is used, the app has access to both the authorization grant and the user's authentication credentials. As a consequence, this data is left vulnerable to recording or malicious use. Even if the app is trusted, allowing it to access the authorization grant as well as the user's _full_ credentials is unnecessary. This violates the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and increases the potential for attack.

### Single Sign-On

Universal login orchestrates [single sign-on](https://auth0.com/docs/sso/current) (SSO) between multiple apps while providing cookies from the same origin. Once a user has logged in using a universal login, a cookie is created and stored. Any future calls to the authentication provider's authorization endpoint will then check the cookie. If the user has already signed on, the login page will not be shown again and the user will be logged in via SSO. On the other hand, embedded user agents don't share authentication state, meaning that they cannot be used for SSO.

![universal login with Google](https://images.ctfassets.net/23aumh6u8s0i/1YugCWp0Ra98EeeupBfBqN/7fadfd6f1334f1d3dfb5a5a17cd21a0d/google-login)

### Easier to Implement and Maintain

Universal login is easier to implement as well as maintain for app developers. Cross-origin authentication is inherently more dangerous, but universal login mitigates this risk entirely. Developers do not need to manage the dangers of cross-origin attack vectors if they use universal login instead of embedded login. A universal login page is also already fully implemented, negating the need for the developer to build out their own embedded login UI. The authorization server providing the universal login page can also ensure a consistent and secure experience across all apps that utilize it.

### Best Practice on Native Mobile

The [OAuth 2.0 Best Current Practice for Native Apps RFC](https://www.rfc-editor.org/rfc/rfc8252.txt) requires that _only_ external user agents, such as universal login, should be used for authenticating with OAuth 2.0 in native mobile applications. This is considered best practice for reasons cited above, including security and single sign-on. You can [read more about the OAuth 2.0 BCP for Native Apps here](https://auth0.com/blog/oauth-2-best-practices-for-native-apps/).

![Google login on mobile app](https://images.ctfassets.net/23aumh6u8s0i/3ahqZk6Umj456bBK6MR0en/0b2e534235a83ddbfafcc7ce3b1bab93/google-login-mobile)

<br>

<em>Native mobile apps that use OAuth 2.0 (such as Gmail, YouTube, and others) use the device browser as an external user agent for universal login.</em></p>

### User Experience

Modern users are comfortable with signing in at the authorization provider's universal login page to authenticate (e.g., OAuth with Google, Facebook, GitHub, etc.), in turn gaining the benefits of single sign-on and not being required to repeatedly log into other apps on the same device as long as they are using the same authentication provider.

![universal login with Facebook](https://images.ctfassets.net/23aumh6u8s0i/213AnVULw3nratInY7hOx4/0bb7f7764843aea22f4777c8ba38e55c/facebook-login)

These login pages are on the authorization provider's domain. However, most people don't even notice the redirect because the modern flow of universal login functions so seamlessly. After signing in, they're brought back to the application and are now authenticated. The user experience of universal login is easy and natural, and is the standard expectation for users of modern web and mobile apps. In addition to being more secure, it provides transparency. In doing so, the user is assured that they are securely logging in with a trusted and familiar entity.

![universal login with GitHub](https://images.ctfassets.net/23aumh6u8s0i/51Aq6EuG8BElVcD2RL14W2/aebce1638b1fce4f73a11dadd77349a4/github-login)

## Conclusion

Universal login is the most secure and maintainable standards-based approach to logging in with an authentication provider. Unlike embedded login, it is safer from cross-origin attack vectors and poses no danger to the authorization server. Universal login is the [best current practice for native mobile apps](https://auth0.com/blog/oauth-2-best-practices-for-native-apps/), and OAuth providers like [Google no longer support embedded login strategies](https://auth0.com/blog/google-blocks-oauth-requests-from-embedded-browsers/). It also provides a comfortable and consistent user experience that confers the benefits of SSO.

<include src="TweetQuote" quoteText="Universal login is safer from cross-origin attack vectors and poses no danger to the authorization server."/>

In keeping with app modernization and current best practices, [Auth0](https://auth0.com) provides a robust [universal login](https://auth0.com/docs/hosted-pages/login) solution with integrations for dozens of [social identity providers](https://auth0.com/docs/identityproviders#social), [enterprise identity providers](https://auth0.com/docs/identityproviders#enterprise), custom [OAuth 2.0 integrations](https://auth0.com/docs/protocols/oauth2), [username/password databases](https://auth0.com/docs/connections#database-and-custom-connections), features like [passwordless authentication](https://auth0.com/passwordless) (with SMS or email), and more.

With Auth0, the universal login page is a [fully customizable UI](https://auth0.com/docs/hosted-pages/login#3-customization). In addition, Auth0's [CNAME](https://en.wikipedia.org/wiki/CNAME_record) functionality to persist the same domain across the universal login page and the app is scheduled to launch before the end of 2017.

![Auth0 universal login page](https://images.ctfassets.net/23aumh6u8s0i/6TwsXjuNeMnkg5I4ZN3y5o/c4b1c77a6e5b8e10b44dc000bde49d19/auth0-centralized-login)

You can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a> to try out these features and more to modernize your app's authentication and follow standards-based best practices.


Authentication Provider Best Practices: Universal Login

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

Bluetooth, a standards based organization, chooses Auth0 to implement standards based authentication via OpenID Connect and OAuth for improved security, access, and interoperability.



**BELLEVUE, WA** - [Bluetooth Special Interest Group](https://www.bluetooth.com/) (SIG), a standards based organization that oversees the development and licensing of Bluetooth technologies, has chosen Auth0 to implement standards based authentication throughout their organization. Thanks to Auth0, Bluetooth was able to implement OpenID Connect and OAuth throughout their organization in record time, meeting the needs of today and also laying the foundation for future expansion.

![Bluetooth Website](https://images.ctfassets.net/23aumh6u8s0i/5WAxWlxKMK57zildCrXUv/34eba0420e66aa592dcd657e76c42f2e/site)

Auth0 was chosen not solely for technological capability, but also for state-of-the-art security, top-notch documentation, excellent customer support, and a superior licensing model that was a right fit for Bluetooth. Auth0 allowed Bluetooth to keep their existing infrastructure in place, while adding the standards based authentication layer on top. This allowed the Bluetooth engineering team to quickly implement the solution across multiple disparate apps.

> “Being a standards based organization, it was important for Bluetooth SIG to implement a standards based identity solution for our platform.”
– Jeremy Syme, Director of Systems Engineering

Read the [case study](https://auth0.com/learn/bluetooth-case-study/) to learn more about why Auth0 was the right fit for Bluetooth.

<include src="asides/AboutAuth0" />


Bluetooth Chooses Auth0 to Implement Standards Based Authentication

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

The NGINX Plus R10 release comes with native support for the JWT authentication standard. Learn how this can change the way your app handles authentication.



---

**TL;DR** NGINX Plus R10 brings native [JSON Web Token (JWT)](https://jwt.io/introduction/) support to the popular server. This enhanced capability allows NGINX Plus to validate JWTs and reject requests that do not have valid JWTs associated with them. This is very useful in protecting API clients and in this post we'll take a look at how we can leverage this new feature in our applications. 

---

[NGINX Plus R10](https://www.nginx.com/blog/nginx-plus-r10-released/) has only been out for a few weeks but it's got us very excited. The latest release boasts many new features and improvements including: "Dual-stack" support for ECC and RSA Certificates, transparent proxy support, nginScript support, and more. The feature we are most excited about is native support for **JSON Web Tokens (JWT)**.

With the R10 release, NGINX Plus makes it easy to protect your APIs and services with JWTs. In this post, we'll look at why you would want to offload the authorization aspect of your app to NGINX and then we'll build an application that does exactly this. We'll use Auth0 to issue the JWTs for us, but the same workflow is applicable to any JWT issuer.

## NGINX Plus JWT Support

Many companies employ NGINX as a reverse proxy or load balancer for their applications. This means that NGINX sits between the users making requests and your actual application servers. NGINX is the first point of contact between a request and your API or service. From here, the request is routed to the correct server for further processing and finally a response is served. If your API requires a user to be authenticated to access a resource, the validation of the request is typically performed after the request has passed through NGINX.

If the user requesting a protected resource is not authenticated, they've just wasted CPU cycles on both your NGINX server, bandwidth between NGINX and your application server, and resources on your application server, all so you could tell them they need to login.

The NGINX Plus `auth_jwt` directive verifies that the user is authenticated and has permissions to access a resource before the request is routed to your application server. If the request coming in does not have a valid JWT, the request is short-circuited and NGINX replies with an appropriate `401 Unauthorized` response. No additional resources wasted.

In addition to not wasting resources, having NGINX Plus handle JWT verification allows developers to focus on implementing business logic instead of building authentication systems. Since NGINX Plus can pass the authenticated user claims directly to the application server, performance gains could also be argued as the app server has less to do. The overhead of adding JWT verification to NGINX is also trivial, as NGINX is rarely the bottleneck in the infrastructure.

<include src="TweetQuote" quoteText="NGINX Plus native JWT support means developers can offload JWT verification and focus on business logic"/>

## Configuring NGINX Plus with JWT Support

With the benefits of having NGINX Plus handle JWT verification for us clear as day, let's see how we can get this implemented. 

*Since NGINX Plus is only available on Linux distributions, we'll be using an Ubuntu virtual machine for our demo.*

### Building our Application Server

For starters, let's create a mock API server. I'll just create a quick server with Node.js and Express and expose a couple of different routes. Take a look at the implementation of our application server below:

```js
// Declare dependencies
var express = require('express');
var app = express();

// Add some public routes that are accessible to everyone
app.get('/', function(req, res){
	res.send('<h1>Welcome to the Hompeage. <small>(Everyone can view this page)</small></h1>');
})

app.get('/about', function(req, res){
	res.send('<h1>Welcome to the about page<small>(Everyone can view this page)</small></h1>');
})

// Add some protected routes that only authenticated users will have access to
app.get('/api/leads', function(req, res){
	res.json({leads:[{id: 12345, name: 'ACME Corp'}, {id: 23456, name:'LeadGen'}, {id:45677, name: 'Organic Leads'}]})
})

app.get('/api/employees', function(req, res){
	res.json({employees:[{name: 'Ado Kukic', username:'@ado'}, {name: 'Diego Poza', username:'@tony'}, {name:'Prosper Otemuyiwa', username:'@unicodedeveloper'}, {name:'Sebastian Peyrott', username:'@speyrott'}, {name:'Kim Maida', username:'@kim.maida'}]})
})

app.listen(9000);
```

Our server exposes four routes. Two public, two protected. Without NGINX Plus to protect our API routes, we'd have to add a couple more dependencies, add some middleware to check and verify that the incoming request had a valid JWT, implement logic for when the token is not valid and more. Luckily, we are using NGINX Plus, so we don't have to do a single other thing. We can simply deploy this server by running `node server.js` and accessing our application at `localhost:9000`.

### Configuring NGINX Plus

NGINX Plus is a premium product. It requires an annual fee, but you can also try it for free [here](https://www.nginx.com/products/). You can find the installation instructions on the official NGINX Plus [website](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/). I'll assume that you already have NGINX Plus installed on your machine. If you have an older version of NGINX Plus installed, you can easily upgrade to the latest R10 release by running:

```bash
// Debian or Ubuntu
sudo apt-get update
sudo apt-get install nginx-plus

// RHEL, CentOS, or Amazon Linux
sudo yum upgrade nginx-plus

// FreeBSD
sudo pkg upgrade nginx-plus
```

Before continuing, check that the version of NGINX Plus installed on your machine is `nginx-plus-r10` or higher. With the appropriate version installed, let's configure our NGINX Plus server. Open the `nginx.conf` file and paste the following:

```
user nginx;
worker_process auto;

events {}

http {
  # Here we are defining the server that we'll pass the requests to
  upstream api_server {
    server 127.0.0.1:9000;
  }
  server {
    # Our NGINX Plus server will listen on Port 80
    listen 80;

    # By default all routes will proxy to our Node.js server at localhost:9000
    location / {
      proxy_pass http://api_server;
    }

    # For any of the /api/* routes, we'll ensure that the user has a valid JWT
    location /api/ {
      # We'll name our domain or realm our Auth0 Domain
      # This is not required so you can name it anything
      auth_jwt "YOUR-AUTH0-DOMAIN.auth0.com";
      # We'll need to load a JWK that contains our secret credentials that will be used to verify incoming JWT's
      auth_jwt_key_file /etc/nginx/secret.json;

      # If an incoming JWT is valid, we'll proxy to our Node.js server
      proxy_pass http://api_server;
    }
  }
}
```

We'll need to create a `secret.json` file next. You can create this file anywhere, as long as it's accessible by NGINX, so we'll just create it our nginx directory.

The `secret.json` file will contain a [JSON Web Key (JWK)](https://tools.ietf.org/html/rfc7517) which will hold our signing key. This file can either be a `.json` file or a `.jwk` file, as long as the format is correct. Learn more about what compromises a JWK [here](https://tools.ietf.org/html/rfc7517).

For our implementation, our JWK will look like:

```json
{"keys":
    [{
        "k":"YOUR-AUTH0-SECRET",
        "kty":"oct"
    }]
}
```

Let's go ahead and get our Auth0 client credentials so we can test our implementation. If you don't already have an Auth0 account, sign up for a free one <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">here</a>. Log in to your [management dashboard](https://manage.auth0.com), navigate to the client you wish you to use, and retreive your **Domain** and **Client Secret**. Replace the `YOUR-AUTH0-DOMAIN` from the `nginx.conf` file and with your domain and `YOUR-AUTH0-SECRET` with your secret and save the files.

![Auth0 Management Dashboard](https://images.ctfassets.net/23aumh6u8s0i/5VmGAcLFkxC2f9WMGuptQK/442660c778bf0f59c828881ec6a814f6/management-dashboard)

To start your NGINX server, run the `sudo nginx` command.

Navigate to `localhost`. You'll see the response from the Node.js server we created earlier and the text displayed: "Welcome to the Homepage". Our proxy server works. NGINX took the request from `localhost:80` and forwarded to our Node.js server at `localhost:9000`.

![Our Node.js Application](https://images.ctfassets.net/23aumh6u8s0i/7MJRdejJyEJPWTZLRXtvN5/e39694d35cfd7777e1b01796680c9f3d/our-app)

Now, let's try to access an API route, navigate to `localhost/api/leads`. You will see a `401 Unauthorized` message served from NGINX. We didn't write this page or have an implementation for it in our Node.js server. When NGINX received the request, it looked for a JWT and since we didn't pass one in, the request was rejected.

![Unauthorized NGINX Plus request](https://images.ctfassets.net/23aumh6u8s0i/4n8PaH6Oy7WEOpGVG57c21/71506bd4ed1455ffaf7f1c0c5857788d/unauthorized)

Let's send a request with a valid JWT. The easiest way to get a valid JWT for our Auth0 implementation is to visit the [Auth0 playground](https://auth0.github.io/playground/). Here, all you need to do is add your ClientID and Domain and you will be able to login with the Lock widget. Let's `console.log` the token we get upon a succesful login and copy it. For reference, our Auth0 playground code will be:

```
var domain = 'YOUR-AUTH0-DOMAIN.auth0.com';
var clientID = 'YOUR-AUTH0-CLIENTID';

var lock = new Auth0Lock(clientID, domain);
lock.show({
  focusInput: false,
  popup: true,
   authParams: {
    state: 'foo'
  }
}, function (err, profile, access_token, state, token) {
  // Console.log the access_token or JWT
  console.log(access_token)
});
```

![Auth0 Playground](https://images.ctfassets.net/23aumh6u8s0i/3Ph31s2T4ZbhFY0zBmUIi6/0bb7812e2001fee4a576229d02ae0796/auth0-playground)

Now that we have a valid JWT, let's make another request to our NGINX server, this time passing the JWT alongside the request. To accomplish this, we'll use `curl`, but you can use a GUI app like Postman to do this as well. Our command to the server will be as follows:

```bash
curl http://localhost/api/leads -H "Authorization: Bearer {JWT}"
```

The `-H` flag will append a header which we'll define as the Authorization header. The Authorization header value requires the word `Bearer` followed by a space and then the JWT. Let's run this command by hitting the return or enter key and our response will be the list of leads we defined in our Node.js server.

![Curl with valid JWT](https://images.ctfassets.net/23aumh6u8s0i/4gXuDaHbOJSPttXXdOsnpk/a4dd45a4158860a593504a76e49f9170/curl-with-jwt)

To double check and make sure that this works, try making a request without passing the Authorization header. Try running `curl http://localhost/api/leads` and you'll see the `401 Unauthorized` response.

![Curl without valid JWT](https://images.ctfassets.net/23aumh6u8s0i/11qW4xkFruCigZolxL1bhB/74cab3f377e412ce245a024bfe2f63b8/curl-without-jwt)

By default NGINX Plus looks for the Authorization header with the JWT, but we can easily change this so we can send the token as a query parameter or even a cookie. For directions on how to do that, check out [this post](https://www.nginx.com/blog/authenticating-api-clients-jwt-nginx-plus/) on the NGINX Plus blog.

*Note: Notice that on your local machine, you can go to `localhost:9000/api/leads` and see the response. This is intended as we are not validating JWTs on our Node.js server. In a real world scenario, you would not allow direct access to `localhost:9000` outside of your private network.*

## Conclusion

Today, we looked at how NGINX Plus can take the burden of validating JWTs off our application servers. We showed how you can integrate Auth0's identity platform to handle the issuance of JWTs. Since we adhere to standards, everything we covered today is also applicable to non-Auth0 JWT implementations, but for the quickest and most secure option, give us a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">try</a>. 


Use NGINX Plus and Auth0 to Authenticate API Clients

All National Association of REALTORS affiliated listing services are now required to adopt the Open ID Connect standard



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Forrester Research conducted a comprehensive analysis of our identity platform and determined that using Auth0 can yield a 548% ROI and $9.9M in savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.</strong>
</div>

---

At the Real Estate Standards Organization's annual conference in Austin last October, the issue of identity authentication had top billing. The big announcement? Widespread and wholesale encouragement to adopt the Open ID identity management standard across the industry.

Today, it's more than a recommendation. All National Association of REALTORS affiliated listing services **[are now required](http://www.reso.org/new-reso-web-api-standard-3-reasons-implement/)** to adopt the Open ID Connect standard. This is huge, because the seamless management of identity has historically been a big problem for the increasingly digital real estate industry. 

While agents have been able to use their personal Google or Facebook accounts to access and share information across different apps, vendor lock-in and proprietary software have made it impossible to do the same at work. Single SSO integrations have taken weeks to complete.

And there's been no shortage of reasons to open up the information flow. Between contact management systems, listings management systems, marketing programs, market analysis systems, and document storage, real estate agents consume a ton of data. All that data used to be siloed off in databases that were totally disconnected from one another—until now.

## What Is Open ID Connect?

Before the RESO adopted Open ID Connect, they were on the Real Estate Transaction System, or RETS. A sixteen-year old system based in XML, this antiquated standard was difficult to learn and use, it was slow, and it was once used by every single real estate website out there.

Open ID Connect is a authentication layer that sits on top of the widely used OAuth 2.0 authorization standard.

OAuth gives websites the power to delegate access to secure areas. It's like a key—if you have yours, you can log in to your account. 

Unfortunately, it doesn't offer any way to tie that key to your identity. That means if someone else gets your key, they can also log into your account. 

Individual service providers like Facebook have built their own extra authentication layers in years past, ensuring that when *your* key is used it's actually you on the other end. Open ID Connect extends the same logic across the web, providing the same kind of security that Facebook and Google have been using for years as an open standard that any organization can adopt.

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

## Implementing Open ID Connect With Auth0

The coup de grâce of Open ID Connect is [how easy](https://auth0.com/docs/oauth-web-protocol) it can be to implement into your application. Cal Heldenbrand shared his experience with the OpenID Foundation

> The certification process was pretty easy as well. I was expecting it to be more intensive! Our environment is Ruby on Rails, and I used [Nov’s openid_connec](https://github.com/nov/openid_connect)t Ruby gem for constructing ID Tokens. Other than that, my Provider is written from scratch. It took me about 2 weeks to have a very simple provider running for demo purposes. Then another 2 weeks to have it fully compliant with the certification tools. This is also along side my usual day job tasks of web operations. I’d have to say this was a breeze compared to the old OpenID 2.0.

Of course, it can always be a bit faster and easier. Auth0 supports Open ID Connect and a long list of [identity providers](https://auth0.com/docs/identityproviders) and [development stacks](https://auth0.com/docs). 

![Auth0 Identity Providers](https://images.ctfassets.net/23aumh6u8s0i/MZw4ZJty6uqbarp5Sawxu/8214ba813366952e9e10bf66ed159c52/identity-providers)

You're covered no matter your IdP. There's no need to spend a month writing your own provider and getting it compliant, either—Auth0 is as close to plug-and-play as it gets.

You can set up Open ID Connect in four basic steps: 

1. Set up a callback URL from your Auth0 dashboard
2. Integrate Auth0 Lock on your site or trigger login manually
3. Send the `code` your app receives to the Auth0 with a `POST`
4. Use a `GET` to retrieve the user profile from the server's response

Then, when users visit your website, this is what they'll see (you can customize the look of the box, of course!):

![Auth0 Lock Widget](https://images.ctfassets.net/23aumh6u8s0i/5UdQftKG0ytbhU93otU4S3/a672e7d099743d3035ce87451452eeda/auth0-lock)

For the full breakdown, check out the documentation on implementing Auth0 into your web app [here](https://auth0.com/docs/oauth-web-protocol).

### Building Your Own Identity Provider Hurts

Building your own identity provider could be a good summertime project—no one knows that better than us!—but that month spent wrangling with Open ID Connect starts to look very different when it's the only thing keeping you from launching.

It can easily become a frustrating way to spend your valuable time early on while you should be worrying about finishing your product and finding customers. It can also become a serious roadblock on your feature map, and that sucks.

Plus, even once you finish building it, you have to deal with the tweaks and changes that will become necessary every time a change is made to one of the platforms your users use to log-in. Building an identity provider is not a one-time investment.

With an identity “clearinghouse” like Auth0, all the work of maintaining and keeping your different connections current is taken care of. 

## Why Open ID Connect 

We've been working with OAuth since we first started building out the core functionality of Auth0. OAuth was always simple, widely used, and highly cross-compatible. But it was never enough to provide secure federated identity management, which is how we found Open ID Connect. 

But Open ID Connect isn't just secure. That's the baseline. The true magic of it is something you've already experienced if you've ever used your Facebook account to find your friends' playlists on Spotify—the seamless interchange of information between apps.

Imagine having your listing info, market analysis, customer data and documents all accessible to one another. No more signing in and out of different overlapping systems for different markets and dealing with incompatible systems. One login and one password—that's what Open ID Connect promises. 

Auth0 can handle all the different connections and layers of authentication, but it can also help use this data to supercharge your company's marketing and promotional efforts.

### Put Your User Data To Work And Drive Growth

Auth0 “rules” are Javascript snippets run by Auth0 and executed when users are authenticated in your app. These are what allow Auth0 to provide simple, actionable analytics for you to use to grow your business.

![Auth0 Rules Engine](https://images.ctfassets.net/23aumh6u8s0i/9NMB5Cr08Ue9dCbzeug3B/3c8dc313d9bab5547b4ceb489ecc6eb7/rules-engine)

Conventional analytics run client-side often fail, or even return misleading results—rules are far more reliable because they're run from the back-end. That means clean data you can immediately start using to execute on personalized marketing and retention tactics: 

1. **Enrich lead profiles:** Pull publicly available information on your new sign-ups and use it to build detailed customer personas.
2. **Notify your team of new leads:** Loop your authentication into an application like Slack to let everyone know when you have a new prospect.
3. **Craft highly personal marketing emails:** Send the right emails to the right users—you don't want to send a listing announcement to a user who's been inactive for a year.
4. **Analyze user registration info:** Graph your new sign-ups and separate them by source so you can understand what promo campaigns are working and which aren't.

Open ID Connect is changing the world of real estate technology by making it easier than ever to develop and use business applications, but it's not just good for convenience's sake. 

Because it provides a way to securely share authentication and verification across platforms, Open ID Connect is opening up to real estate companies the same opportunities that tech companies have had for years—opportunities to treat customers better, learn faster, and [grow at unprecedented rates](https://auth0.com/blog/7-ways-to-2x-your-revenue-growth-by-putting-your-user-data-to-work/).


How Real Estate Companies Can Implement Open ID Connect With Auth0

HTTP/2 is the latest web standard that aims to improve the way we interact with the web. Learn all about HTTP/2 and how it affects you.



---

**TL;DR** HTTP/2 is a much needed upgrade to the HTTP protocol, used to manage the communication between web servers and browsers. The new standard paves the way for faster page loads through better data compression, multiplexing of requests, and other improvements. Many servers and browsers have support for HTTP/2 and developers can take advantage of these new capabilities today.

---

The world wide web at large operates over the [Hypertext Transfer Protocol (HTTP)](https://www.w3.org/Protocols/). HTTP was first conceived way back in 1989 and the last major revision was ratified in 1999. The Internet was quite different in those days. The majority of websites were text-based with very few images, scripts, and styles - and video was even rarer. Today, websites are much more interactive with images, animations, styles, custom fonts and much more, but this comes at a price, a single page can easily request [over 100](https://www.sitepoint.com/average-page-weight-increased-another-16-2015/) different resources.

![Amazon 1999 vs 2016](https://images.ctfassets.net/23aumh6u8s0i/1TnWHOiamRvrEf2pb7HUEJ/fcbda4b9659a819a0e050773d8ad632b/amazon-1999-2016)

The ever-increasing number of resources requested and the growing size of pages has led to slower page load times which further led to bad user experiences. Users do not like waiting, even a delay of a [few seconds](https://blog.kissmetrics.com/loading-time/) can cause users to leave your website and go to a competitor. The explosion of mobile has not made the job any easier on developers, as devices connected to mobile networks tend to be slower and even more bandwidth constrained.

 Developers have fought back by combining and concatenating multiple files into one, creating sprite sheets for common web elements, delaying requests until absolutely necessary, and many other techniques to reduce the number of requests as well as the bandwidth required to load web pages. Striking a balance between giving the user a great experience and delivering it fast has become an artform. At the end of the day, these optimizations can only go so far and a change to the underlying technology is required.

 <include src="TweetQuote" quoteText="Delivering a great user experience and doing so quickly has become an artform."/>

## Enter HTTP/2

**HTTP/2** aims to address many of the current failings of HTTP/1.1 by evolving the standard to meet the needs of modern applications. HTTP/2 standardization is fairly unique in that its concepts have already been proven to work years before the standard was finalized. [SPDY](https://www.chromium.org/spdy/spdy-whitepaper), a network protocol primarily developed by Google, implemented many of the features and benefits that HTTP/2 would eventually provide. In fact, the first draft of HTTP/2 was heavily influenced by SPDY.

SPDY was implemented in many browser and server technologies, but as HTTP/2 standardization was approaching, Google decided to deprecate the SPDY protocol in favor of HTTP/2. As of Chrome 51, SPDY has been completely removed from the Chrome web browser.

## Benefits of HTTP/2

HTTP/2 was designed for the modern web, but it remains backwards compatible with HTTP/1.1. Backwards compatibility ensures that browsers that support the protocol can leverage the benefits, but those that do not can still operate without affecting the user workflow. Here are some of the benefits HTTP/2 provides:

* **Header Compression** - HTTP Header size will be greatly reduced
* **Multiplexing** - Multiple requests can be served concurrently over a single connection
* **HTTP/2 Server Push** - Resources can be pushed to the client before they are requested
* **Prioritization** - Resources can have dependency levels allowing the server to prioritize which requests to fulfill first
* **Binary** - HTTP/2 is a binary protocol making it a lot more efficient when transferring data

HTTP/2 is especially useful when dealing with TLS connections. The TLS handshake can be quite long but thanks to reduced latency and multiplexing, other requests can do their work without being blocked.

## HTTP/2 Performance

Two companies that are synonymous with web performance are [CloudFlare](https://cloudflare.com) and [Akamai](https://akamai.com). Both of these companies provide CDN and other solutions to improve the performance and reliability of websites and both support HTTP/2. To promote the adoption of HTTP/2, let's look at the demos they provide to showcase some of the benefits.

 The [CloudFlare demo](https://www.cloudflare.com/http2/) shows the difference between downloading a large number of resources from an HTTP/1.1 and an HTTP/2 server. In our tests the HTTP/2 side won every single time by more than 2.5X.

![CloudFlare HTTP/2 Demo](https://images.ctfassets.net/23aumh6u8s0i/1PCM6JumW9sNTCe6EG2PTN/f56fbc511ad17b2b6b843ba9cb2b83c1/cloudflare-demo)

 The [Akamai demo](https://http2.akamai.com/demo) is fairly similar as are the results.

 ![Akamai HTTP/2 Demo](https://images.ctfassets.net/23aumh6u8s0i/MUWBW18RY4gtUCaTRvtli/98a6cc057a0d14b1b650481552a2b3ef/akamai-demo)

 One final demo I'd like to show is provided by the [Golang](https://golang.org/) team at Google. This demo, again downloads a bunch of resources but additionally allows you to set a latency to the request to really show the benefits of HTTP/2. Without any latency, the difference between HTTP/2 and HTTP/1.1 was 569ms vs 3227ms. If we add 200ms of latency, the results look quite different with HTTP/2 loading the page in 839ms compared to 9095ms that it took HTTP/1.1. Check out the demo for yourself [here](https://http2.golang.org/gophertiles).

 ![Gopher HTTP/2 Demo](https://images.ctfassets.net/23aumh6u8s0i/5l5i10R2zRqo6Aqh0sFAuT/854b7d2e405e537bff6b4a90327758cc/gopher-demo)

 If you are curious to see which websites are leveraging HTTP/2, there are a couple of easy ways to check. The [HTTP/2 and SPDY Indicator](https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en) Chrome extension is one way to easily be notified if a website has HTTP/2 enabled. If you would rather not install extensions, [HTTP/2 Test](https://tools.keycdn.com/http2-test) by KeyCDN provides a website where you can type in a URL and see if that domain has HTTP/2 enabled.

## HTTP/2 Browser Support

Implementations of the HTTP/2 protocol for many languages, servers and browsers have already been deployed. Browsers like Chrome and Firefox have full support for the HTTP/2 protocol. Microsoft's Edge and Apple's Safari browsers support HTTP/2 but only over secure connections. Mobile versions of Chrome and Safari also offer support for the HTTP/2 protocol.

Chances are your users are capable of utilizing the protocol, and even if not, HTTP/2 is fully backwards compatible so you don't have to worry. To follow progress and stay up to date on browser support, you can check the [Can I Use HTTP/2 page](http://caniuse.com/#search=http2).

## Using HTTP/2 In Your Stack

When it comes to your technology stack, whether you are on [IIS](http://blogs.iis.net/davidso/http2), [Apache](https://httpd.apache.org/docs/2.4/mod/mod_http2.html), [nginx](https://www.nginx.com/blog/nginx-1-9-5/), or any of [these technologies](https://github.com/http2/http2-spec/wiki/Implementations), you can effortlessly enable HTTP/2. Since the HTTP/2 protocol is backwards compatible, you will not need to make any changes to your actual code. As of the 1.6 release of Golang, the standard http library actually uses HTTP/2 by default when browser support is available.

<include src="TweetQuote" quoteText="HTTP/2 implementations are available for most tech stacks in use today! What are you waiting for?"/>

## Future of HTTP/2

HTTP/2 was standardized in 2015 and since then many websites have begun using the protocol. The [uptake](http://trends.builtwith.com/docinfo/HTTP2) has not reached the masses at large though. It is too early to speculate when or what the future of HTTP will be, but on the official [HTTP/2 homepage FAQs](https://http2.github.io/faq/#will-there-be-a-http3), when asked about HTTP/3, the answer was that is is possible. For now, let's focus on adopting HTTP/2 across the board!

## HTTP/2 At Auth0

Here at Auth0, we strive to deliver a great user experience. We have already rolled out HTTP/2 support for our CDN and [main website](https://auth0.com). We will be adding HTTP/2 support to more of our systems in the future.

## Conclusion

HTTP/2 is a long and overdue update to the HTTP protocol. The benefits of the new protocol are multiplexing, header compression, binary format, server push, resource prioritization, and backwards compatibility. HTTP/2 is ready for production use today and available across the majority of tech stacks. Since it is backwards compatible, enabling it on your server is fairly easy and if you haven't already, you should enable it today!


What is HTTP/2 All About?

Contrary to popular belief, reducing vendor lock-in helps gaining enterprise customers



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>EDITOR’S NOTE (June 22, 2018): Today, open standards alone won’t save you from vendor lock-in. Find out why they ought to now be considered “table stakes” and what “pure breed” providers are doing to help you avoid hard lock-in in this post by Auth0 Principal Architect Vittorio Bertocci.  <a href="https://auth0.com/blog/open-standards-wont-save-you-from-vendor-lock-in">Read now</a>.</strong>
</div> 

---

It’s hard to close an enterprise software deal with a large company, but once you do, you have a customer for life . . . or so the logic goes. If a big company goes through all the trouble to run through the buying process, integrate its systems, train its people and more, it’ll be a cold day in hell before it even considers ripping your software out.

This is what’s called vendor lock-in, and it’s what makes the massive headache of selling to the enterprise worth it.

But there’s a catch—because vendor lock-in is so advantageous to the vendor, it’s one of the biggest worries on an enterprise buyer’s mind. And if you’re a startup, enterprise buyers are going to be doubly worried. Getting locked in to software from a startup that might not exist in a year is their worst nightmare.

It’s counterintuitive, but one of the ways we’ve been able to win at enterprise sales here at Auth0 is through *reducing* vendor lock-in. We build upon open standards rather than creating our own proprietary standards that force involuntary vendor lock-in. In the end, we acquire and keep our customers by making it possible for them to leave at any time.

<include src="TweetQuote" quoteText="We build upon open standards rather than creating proprietary standards that force involuntary vendor lock-in."/>

## Open Standards in an App Built for the Enterprise

Your employees’ identities are split up across all the different apps that your company uses to get stuff done. This gets hugely annoying for employees of big companies who have to login to a bunch of separate systems and remember a username and password for all of them. Plus, employee user profiles are split across these systems which creates discontinuities in the user experience and inefficiency from siloed information stores.

Auth0 is a service that helps big companies bring all of those federated identities into a single place.To make that happen, Auth0 connects with the most common identity protocols used in enterprise deployments (e.g. [SAML](https://auth0.com/docs/saml-configuration), WS-Federation, LDAP) and those used in consumer apps (e.g. OAuth, OpenId Connect), all of which are open standards.

![OAuth flow](https://images.ctfassets.net/23aumh6u8s0i/48nkRUBi0TGGNfVrRDV3JY/3d05270126f3a3676c7696959732b907/oauth-flow)

By connecting these protocols together, we can run identity through a central clearinghouse that manages authorization and authentication and centralizes user profiles in a single location. Here’s how happens in 3 steps, using [OAuth as an example](https://auth0.com/docs/protocols) per the diagram above:

1. **Authorize**: Someone using a browser requests a page that requires users to be authenticated. Your website redirects the user to the Authorization Server on Auth0.
2. **Authenticate**: Auth0 will start the authentication against the requested identity provider. The protocol between Auth0 and the identity provider could be different. It could be OAuth2 again or something else. (e.g. Office 365 uses WS-Federation, Google Apps uses OAuth2).
3. **Getting the Access Token**: Upon successful authentication, the user will eventually return to your web site with a code (steps 3 and 4 in the diagram). Your web site will then call Auth0 again using the code with a request to obtain an "Access Token.” That Access Token can be used to further interact with Auth0’s API—for instance, to retrieve a user profile for the user.

At every step, we’re connecting protocols together that are open standards and building on top of others like JSON Web Tokens. Conventional wisdom says that this would hurt us in enterprise sales, reducing our value in the eyes of big companies and making it easier for them to leave.

Here are the 3 counterintuitive ways we approach selling to the enterprise having been built on open standards. In each case, conventional wisdom would say that our approach to open standards would lower our value in the eyes of enterprise buyers and make it all too likely that we would lose customers to competitors. We’ve been able to win by turning around each weakness into our source of strength.

## Make your code easy to remove

Using open standards in Auth0 makes it easier for customers to adopt our product and hit the ground running, but it also makes it easier for a customer to rip our code out. If they’re unhappy with our product, they can drop us and go with a competitor in a heartbeat, without writing much more code to get a new solution up and running.

### Necessary to integrate into complex environments

Big customers work in incredibly diverse environments with a ton of internal and 3rd party applications that all need to talk to each other and work together. A representative customer might be a bank that has 100,000 employees, all of whom rely on a multitude of different apps to do their jobs. In addition to all the 3rd party tools that employees use, it’s not uncommon to see companies managing 10+ internal tools, each built on a different tech stack that talks to others with a different protocol.

Doing a deal in this kind of environment can be incredibly tricky. You’re only able to deliver value if you can integrate your service with every application—internal and 3rd party—that the customer is running. To make those assurances, companies often resort to building in a custom software development schedule into the enterprise deal.

The problem is that custom software development consulting adds to deal complexity, making it more expensive, increasingly difficult to understand, and harder to execute. And we all know time ruins deals.

Because at Auth0, we support open standards and integrate with everything, we need to do very little in terms of customization for enterprise deals. Customers are more confident purchasing our product because uncertainty, and extra costs like custom development are removed.

<include src="TweetQuote" quoteText="Customers are more confident purchasing our product because uncertainty, and extra costs like custom development are removed."/>


### lock in via value-added functionality

Moreover, it’s by supporting all open standards that we end up delivering core value. Customers don’t want to rip us out because by supporting open standards, we actually expand the functionality of their tools. Given the modernization of the enterprise stack and the transition to the cloud, this means that building on modern open standards means that we’re helping big companies move into the future.

Before a company installs Auth0, you can imagine that different apps create identity continuity by plugging directly into each other using different protocols. But if a company uses, say, LDAP, which was created around 1993 without the cloud in mind, they won’t have mobile functionality because LDAP doesn’t play nice with iOS and the cloud apps you use every day.

![Old world - New World](https://images.ctfassets.net/23aumh6u8s0i/1daU62dqnWyIByuKLm3yHP/93242d5a11934a10ff73f367fdf49be3/old-world-new-world)

In the old world, every enterprise app lived behind the firewall, was built on heavyweight web frameworks, and authenticated using Windows Auth or LDAP. Today, not only are enterprises relying on apps in the cloud like Salesforce, the building blocks they’re using for their own internal apps rely on [3rd party services like Amazon AWS and Firebase](https://www.firebase.com/blog/2014-06-05-auth0-guest-blog.html) that run in the cloud. And it’s via modern open standards like JSON Web Tokens that makes this happen and helps enterprises transition from the old world to the new one.

Because Auth0 works with all relevant open standards, it’s not just installed—it’s made the very central hub of all identity verification for the company. Every app plugs into it using whatever protocol is best for the app. The upshot is that two apps that might not have been able to talk to each other previously, now are able to—through Auth0. In our example, Auth0 would talk LDAP and then do protocol translation to a standard supported on mobile.

## Make yourself easily replaceable

Open standards come with the communities that maintain and grow them. Within those communities are engineers and experts who are working to potentially render your expertise and your product obsolete. Your customer isn’t dependent on your personnel and can go to someone else for advice on your own product. In some sense, you’ve outsourced key parts of your value to a community that you have no control over, and that’s lowered your value in the eyes of your buyer.

### Operate within your customer’s sphere of expertise

However, giving up tight-fisted control over your product that provides you with an incredible amount of leverage, and this is particularly true in the realm of security. It can’t be overstated: security is hard. It’s much better to work with a community of cybersecurity experts who have a vested interest in finding and killing security holes than to go at it alone. Fundamentally, it’s the community behind open standards that gives enterprise buyers the confidence that your tech is built on solid ground, and will be easily supported.

Your enterprise buyer will have internal experts on open standards as well, and that will give the buyer confidence to do the deal. They’ll know that they can maintain your app internally without having to hire an outside expert or train their existing team in a new technology. That helps reduce the most dangerous kind of uncertainty—”the unknown unknowns”—the things that you don’t know that you don’t know.

### Choosing a better developer experience

Instead of locking customers into technology that only you know how to use, do the opposite—build on open standards that whole communities of developers work on. You’ll earn customer loyalty by delivering more value on top of that, instead of locking them in.

At Auth0, we offer customers [libraries and SDKs](https://auth0.com/docs) that make it easier to work with open standards in building your app. Developers then choose to work with Auth0 because we’re delivering value on top of what open standards offer. They want to use our tech—they’re not forced to use it.

<include src="TweetQuote" quoteText="At Auth0, we offer customers libraries and SDKs that make it easier to work with open standards in building your app."/>


![How Auth0 works](https://images.ctfassets.net/23aumh6u8s0i/58SCL6EJIXHRs6GqucifqK/f2801527941fadc265859dec60e4afca/rules)

Our [Rules engine](https://auth0.com/docs/rules) makes it easy to implement user-facing functionality like multi-factor authentication and encryption. Rules are code snippets written in JavaScript that are executed in Auth0 as part of the authentication pipeline every time a user authenticates to your application. Rules allow you to easily customize and extend Auth0's capabilities.

Developers choose to work with Rules because (a) we save you the hassle of wiring up your internal code—with Rules, you can write code in the browser that’s separated from the rest of your code; (b) you don’t have to add any additional infrastructure; and (c) Rules are sandboxed so they won’t break your app if they fail. When developers write Rules, they’re putting their code into the Auth0 platform, and that creates lock-in. The difference is that they’re doing it voluntarily, and receiving value in return.

## Plan for your startup death

9 out of 10 startups fail, and that’s a fact that enterprise companies know well. To [former HubSpot exec David Cancel](http://davidcancel.com/3-startup-lessons-i-learned-the-hard-way), if you haven’t won yet, you’ve either died or you’re failing—and that has terrible implications for your enterprise customer.  If a buyer has been burned in the past by doing a deal with a startup that died or got bought and then shut down the product, you can expect that they’ll be doubly concerned about your company’s longevity.

![Startup Lifecycle](https://images.ctfassets.net/23aumh6u8s0i/1eopcl5QsywSkOJ2RG68Tb/9819037369097eb266ae50eaef61cdf6/startup-lifecycle)

But acknowledge your startup’s precarious existence, and you could potentially draw even more attention to it. Stability, above all in many cases, is what enterprise customers are buying. Admitting that you’re a startup in itself could ruins your company’s chances of getting the deal.

### The longevity of open standards

If, god forbid, your startup doesn’t work out, you’ll have done your customer a solid by building on open standards. That means that they won’t have to rewrite all of their code. They can replace your defunct product and go with a [competitor](https://auth0.com/auth0-vs) with minimal hassle.

Open standards have seen thousands of companies come and go. They were around before your company existed, and they’ll be around after. SAML—a protocol that allows you to login once and have that login you into a number of separate websites—was first created in 2001. So when you build on open standards, you get a succession plan for your startup for free.

## Go from Lock-In to Customer Loyalty

By eschewing the traditional notion of lock-in where your customers are forced to rely on you—an effect that engenders bitterness and resentment—you reduce the technological barriers to switching or leaving. While potentially having a disastrous effect on the economics of the business of enterprise software, we’ve seen it to have the opposite effect.

Those constraints force you to get creative and build real value on top of what’s been commoditized and made open and free. When you do that, customers will actively choose you, and you’ll win more deals and build real customer loyalty based in free choice.

[Unlock B2B SaaS growth with modern identity management. Download free eBook here.](https://resources.auth0.com/unlock-b2b-saas-growth-iam/)


"standard"