1454075?s=400

Guest Author

Dominick Baier

dominick

Product Designer at Auth0

Dominick Renzetti

jess-author

Jessica Temporal is a Senior Developer Advocate at Auth0 and co-founder of the first Brazilian data science podcast called <a target='_blank' href='https://pizzadedados.com'><strong>Pizza de Dados</strong></a>. She’s the author of <a target='_blank' href='https://www.amazon.com/dp/B0CDNX6NS7/ref=sr_1_1?&_encoding=UTF8&tag=jesstempora0e-20&linkCode=ur2&linkId=efc4229f6b816609dfce4f185781d99a&camp=1789&creative=9325' ><strong>The Big Git Microbook</strong></a>, creator of <a target='_blank' href='https://gitfichas.com/en'><strong>GitFichas.com</strong></a>, and a part of <a target='_blank' href='https://www.linkedin.com/learning/instructors/jessica-temporal'><strong>LinkedIn Learning</strong></a> instructors team. Jessica helped develop the AI that identifies possible unlawful expenses from Brazilian politicians. She is part of the PyLadies initiative that works to improve diversity and inclusion in technology. In her free time, she likes to knit, play video games, use her 3D printer, and is learning to create 3D models.

Sr. Developer Advocate

Jessica Temporal

profile small square

Shreya is the Developer Advocate for Auth0 for Startups. She previously founded a non-profit called Bit Project, worked at a YC-backed Startup as a Developer Advocate, and currently hosts The Developer Diaries podcast. Through each experience, she has found her love for building resources and tools that help move the needle for developers. Outside of work, she enjoys traveling, watching K-Dramas, and drinking boba.

Developer Advocate, Startups

Shreya Gupta

A comprehensive guide to configuring custom domains in Auth0, from DNS setup with Namecheap or Squarespace to updating your application code for SDKs and APIs

Setting Up Auth0 Custom Domains: A Complete Guide to DNS and SDK Configuration

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

Let's explore why Broken Access Control continues to rank highest on the OWASP list of security risks in web applications and APIs after several years.

Why Broken Access Control Still Dominates the OWASP Top 10 in 2026?

Meina Liu

Meina Liu is a Technical Product Marketing Manager Intern with a focus on the convergence of identity, security, and artificial intelligence (AI). Currently studying Computer Science on the AI track at Stanford University, she works at the intersection of engineering and go-to-market strategy. Over the past year on the Auth0 team, she built deep-dive demos, technical architectures, and authored blogs for features ranging from Actions to Fine Grained Authorization (FGA), and more. She is passionate about leveraging her engineering background to build solutions that help developers integrate secure identity infrastructure with ease.

Technical Product Marketing Manager Intern 

Auth0 Multiple Custom Domains and Auth0 Actions create a seamless, branded login experiences across multiple applications from a single tenant.

Multi-Brand Identity Simplified with Auth0 Multiple Custom Domains

E017NDYFGQL-U4W9C40NL-51be4d627a6f-512

Ari is a seasoned Product-Led Growth (PLG) leader with a passion for architecting flawless customer journeys. As the VP of Developer-Led Growth at Auth0, he leads the Developer Marketing, Developer Relations, Activation, and Conversion teams, among others. His career journey includes a key role on the Microsoft Developer Evangelism team and a foundational period as a Software Engineer at Southworks and other firms, where he delivered mission-critical projects for Fortune 100 clients.

Vice President, DLG

Ari Schapiro

Enhanced developer security with PII masking in logs and improved bot detection, new global cloud regions, early access programs for Multiple Custom Domains, Passkey support, and more developer-focused features.

Welcome to our July product update! 🎉 This month, we've been busy rolling out exciting new features, enhancing existing capabilities, and expanding our global footprint to provide you with an even more robust and flexible identity platform. Our focus remains on empowering developers and organizations to build secure, seamless, and scalable authentication experiences. You can also check the [July release highlights on Youtube](https://www.youtube.com/watch?v=iBQDgUmHbWI):

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

<NonAmpContent>
<div
  className='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/iBQDgUmHbWI'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

## What's new this month

### Enhancing Security & Compliance 🛡️

* **PII Obfuscation/Masking in Log Streaming:** We're excited to introduce a new feature that allows you to mask sensitive Personally Identifiable Information (PII) directly within your log streams. This significantly enhances your security posture and helps meet compliance requirements by ensuring sensitive data isn't exposed in your logs. [Learn more](https://auth0.com/docs/customize/log-streams) 📖.  
* **Cascade Token and Session Revocation for Native to Web SSO:** Improving token lifecycle management and session integrity, this update automatically revokes dependent web sessions and refresh tokens when the original refresh token is revoked. This is a crucial step for maintaining robust security across your applications. [Learn more](https://auth0.com/docs/authenticate/single-sign-on/native-to-web/native-to-web-sso-and-sessions) 📖.  
* **Updates to Bot Detection:** We’ve upgraded our bot detection model to improve accuracy and reduce friction for legitimate users, particularly on mobile devices and evolving browser platforms. [Learn more](https://auth0.com/docs/secure/attack-protection/bot-detection) 📖.

![Screenshot of the Auth0 dashboard for configuring Bot Detection, showing options like Auth Challenge, Simple CAPTCHA, and Google reCAPTCHA](https://images.ctfassets.net/23aumh6u8s0i/4glCjfQm2TLSk9WpbETqJg/bfe92a68bf1cbd5272d1235b918ccb84/bot-detection.png)

* **IETF JWT Profile for Access Tokens:** JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens \- [RFC9068](https://datatracker.ietf.org/doc/rfc9068/) is now Generally Available for all customers. You are now able to opt-in to use the new profile for your Access Tokens on a per-API basis. [Learn more](https://auth0.com/docs/secure/tokens/access-tokens/access-token-profiles) 📖.

### Expanding Global Reach 🌍

* **New Private Cloud Regions:** To better serve our global customers and address data residency needs, we've expanded our Private Cloud offerings with new regions in **Mexico 🇲🇽, Hong Kong 🇭🇰, and Calgary, Canada 🇨🇦.**  
* **Public Cloud Environment in Canada:** We've also launched a new Public Cloud environment in **Canada 🇨🇦**, providing more options for organizations seeking local data hosting.


### Early Access Programs 🚀

We're also excited about several features currently in Early Access, offering a glimpse into future enhancements:

* **Multiple Custom Domains on a Single Auth0 Tenant:** simpler, more flexible branding and white-labeling. Allowing you to:  
  * Deliver tailored, branded experiences for your users, including customized login URLs and emails.  
  * Enhance security through the consistent use of custom domains across end-user interactions.  
  * Scale B2B SaaS usage rapidly through Multiple Custom Domains (MCD) on a single tenant.

  [Learn more](https://auth0.com/docs/customize/custom-domains/multiple-custom-domains) and please send a request through the [Auth0 Support Center](https://support.auth0.com/?_gl=1*dea6jn*_gcl_aw*R0NMLjE3NTQwNjUzMDEuQ2p3S0NBand5N0hFQmhCSkVpd0E1aFFOb2hCN3pYUTJxRjVwakYxcC1vNkxhSHl6M1MyM2diZG1oM0Y5M3hwZ2RjdHYtMll0dl9kREhob0NNMjRRQXZEX0J3RQ..*_gcl_au*MTUzNDIzOTk3My4xNzUwMTg5ODMy*_ga*ODYzMzAwMjA5LjE3MzQ0ODQwMTg.*_ga_QKMSDV5369*czE3NTQ2MDI0MzEkbzI2NCRnMCR0MTc1NDYwMjQzNiRqNTUkbDAkaDA.) if you are interested in participating\!


![Diagram illustrating the Multiple Custom Domains feature, with a central 'MarketZero Tenant' connected to four different custom domains](https://images.ctfassets.net/23aumh6u8s0i/4TgAfhWwYWkd0PpCH3Za3M/06a5e44f1e9838a797140ce640b8fc92/multiple-custom-domains.png)

* **Passkey Support for Custom Database Connections (with import mode off):** you can now leverage passkey support directly with your custom database connections, without needing import mode. Request access by contacting your Technical Account Manager.  
* **My Account API Explorer:** Empower your users with self-service capabilities. The new My Account API Explorer provides a user-friendly interface for managing their own account settings and preferences.[Try it out](https://auth0.com/docs/api/myaccount).  
* **Advanced Customizations for Universal Login:** Gain even finer control over the look and feel of your Universal Login pages, allowing for a truly branded experience. Check out our [online documentation](https://auth0.com/docs/customize/login-pages/advanced-customizations) to learn more about ACUL\!

![Advanced Customizations for Universal Login](https://images.ctfassets.net/23aumh6u8s0i/h6C4eHfv46EVD5OlLI2x2/a2e4f69e413a053fe7cd8594ab5fe148/universal-login-banner.png)

* **Right-to-Left Language Support for Universal Login:** Expanding our global accessibility, Universal Login now supports right-to-left languages, catering to a wider audience. Contact your Auth0 account manager or [Auth0 Support](https://support.auth0.com/) to enable Early Access on your tenant.  
* **Multi-Resource Refresh Tokens (MRRT):** This feature allows applications to use a single refresh token to request access tokens for multiple resource servers (APIs), each with its own audience and scopes providing a more granular control and flexibility.  [Learn more](https://auth0.com/docs/secure/tokens/refresh-tokens/multi-resource-refresh-token) 📖.

We're continuously working to bring you the best in authentication and authorization. These updates reflect our commitment to providing a secure 🔒, flexible 💪, and developer-friendly platform 🧑‍💻.

## Where we were in July

* [DWX 2025](https://www.developer-world.de/dwx) (June 30 – July 3, Mannheim, Germany) – [Ramona Schwering](https://auth0.com/blog/authors/ramona-schwering/) presented *"From the Crypt to the Code"*, diving into secure coding and modern auth strategies  
* [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress) (July 9–11, Berlin, Germany) – [Deepu K Sasidharan](https://auth0.com/blog/authors/deepu-sasidharan/) and [Ramona Schwering](https://auth0.com/blog/authors/ramona-schwering/) were at the booth answering developer questions. They also found themselves on stage:   
  * [Ramona](https://auth0.com/blog/authors/ramona-schwering/) presented *"The Cake Is a Lie... And So Is Your Login’s Accuracy"*, unpacking real-world login flaws and how to build trust in AI-era authentication  
  * [Deepu](https://auth0.com/blog/authors/deepu-sasidharan/) presented *"Delay the AI Overlords: How OAuth and OpenFGA Can Keep Your AI Agents from Going Rogue"*

* [AWS Summit](https://aws.amazon.com/events/summits/new-york/) (July 16, New York, USA) – Fred Patton and Lily Wisecarver were at the booth connecting with cloud builders and answering developer questions.  
* [dev\_night](https://auth0-japan.connpass.com/event/359423/) (July 16, Tokyo, Japan) \- [Daizen Ikahara](https://auth0.com/blog/authors/daizen-ikehara/) hosted a dev\_night in Tokyo for the local developer community. Keep an eye out for our next dev\_night Tokyo in the fall covering our extensibility capabilities.  
* [TechRAMEN 2025](https://techramenconf.net/) (July 26 \- July 27, Asahikawa, Japan) \- [Daizen Ikahara](https://auth0.com/blog/authors/daizen-ikehara/) presented a talk about FGA for RAG during the after conference.

![Collection of images from past events in July](https://images.ctfassets.net/23aumh6u8s0i/5nxgPtun4i3j8Q6w8OSror/f8d940fa00290ad29c71c21814dc592e/auth0-dev-adv-at-events-july-2025.png)

Thank you to all that stopped by to chat with us – We loved connecting with our developer community around the world. 

## Where we are going in August

* [Agentic AI Summit](https://rdi.berkeley.edu/events/agentic-ai-summit) (August 2, Berkeley, USA) \- Fred Patton and Shreya Gupta at the booth networking with the local developer community.  
* [Google Cloud Next Tokyo 2025](https://www.googlecloudevents.com/next-tokyo/) (August 5, Tokyo, Japan) \- [Daizen Ikahara](https://auth0.com/blog/authors/daizen-ikehara/) at the booth connecting with cloud builders  
* [Build Secure AI Agents with Auth0 and Workers](https://workshop.cloudflare.dev/) (August 5, virtual) \- [Juan Cruz Martinez](https://auth0.com/blog/authors/juan-cruz-martinez/) hosting a workshop with CloudFlare developer advocate, Confidence Okoghenun, on how to build and securely deploy a Google Calendar-integrated personal assistant using Auth0 and Cloudflare.  
* [AI Dev Tool Demo Night @ AWS Gen AI Loft](https://lu.ma/toyijx9w) (\#2nd Edition) (August 8, San Francisco, USA) \- Fred Patton presenting an Auth0 demo.   
* [KCDC](https://www.kcdc.info/) (August 14 \- August 15, Kansas city, USA) \- [Ramona Schwering](https://auth0.com/blog/authors/ramona-schwering/”) will present 2 sessions: A workshop titled *“One Does Not Simply Build Authentication: UI Components to the Rescue!”* and a session titled *“The Cake Is a Lie... And So Is Your Login’s Accessibility”*  
* [Auth0 x AI Tinkerers Demo Night](https://urldefense.com/v3/__https://nyc.aitinkerers.org/p/ai-tinkerers-august-demo-day-ft-auth0__;!!PwKahg!4AUFzM5IwkAkFdHtB0dwCZjD1dRUEt_uO_xU1Fh4UCfW2e-XWPDhbksTwUshJmlKPe1osSJdoFSuRoB6KEMZ5LjJR4Dl$) (August 26, New York, USA) \- Fred Patton presenting an Auth0 demo.   
* [TechBBQ](https://techbbq.dk/) (August 27 \- August 28, Copenhagen, Denmark) \- Two days of networking, sessions, and startup energy.

Will you be attending? Reach out! We’d love to connect and hear what you’re working on! 


Auth0 Product Updates (July 2025): New Security Features, Global Regions, and Developer Previews

bonfida

Establishing your identity in a permissionless and censorship-resistant way using Solana. We give the power back to our users

Bonfida.sol

What about a single username for all the dapps that you have to sign up for? No passwords, no emails, just your SNS domain. One that is uniquely yours across Web3.

It’s no secret that an average internet user makes use of an array of emails, passwords, and username combinations spread across different apps to ensure logins. A process that prevails to be a logistical effort.

Today, however, we’re changing the game for Solana developers, their dapps, and users - to make the Solana “login” experience(s) a dream.

We present to you a tooling built by Bonfida and Auth0: **Sign-in with SNS** (SIWSNS). SIWSNS is a new authentication method for .sol domain name holders. A method that allows a domain holder to live interoperably, control their digital identity and build Web3 profiles under a single name across every dapp they interact with.

Following a few simple steps, developers are able to harness the power of Web3 domains and automatically populate the identities of users interacting with their projects. One that is secured by the technology of public-private keys and guarantees consistent identities across the space. Besides the security of this method, we are accelerating the onboarding process for users and enabling already existing personalities to nest themselves in the new projects they delve into. Carrying over their potential following.

This makes for a much simpler experience - where practically no information is required. Ultimately reducing the barriers to entry and stimulating a better and more convenient Web3 experience.

[View the Marketplace page for SIWSNS for developers.](https://auth0.github.io/marketplace-integrations/#/marketplace-integrations/preview/889/details/siwsns)

## A Better Experience for Solana Users

Domain names are unique. This means only one `[king.sol](https://king.sol/>)` and only one `queen.sol` can exist in our space. No, you don’t have to worry about signing into a dapp and not being able to use the same username you have on another.

Sign in with the Solana Name Service Powered by Auth0

Samuel Frank

Sam Frank is Auth0's Sr. Product Manager for new initiatives. He works within the Auth0 Lab to commercialize the team's new ideas so they're available for builders everywhere. As a former platform product manager and startup product lead, he knows the challenges that developers face when creating new apps and he leverages those experiences to focus our teams efforts delivering the next generation of identity tools.

Senior Product Manager

Connect with 350 thousand Unstoppable users and bring Web3 universal usernames into your application

We're excited to announce the latest addition to our [Web3 marketplace category](https://marketplace.auth0.com/categories/web3): [Unstoppable Domain's](https://unstoppabledomains.com/) new [Social Connection](https://marketplace.auth0.com/integrations/unstoppable-domains) in the [Auth0 Marketplace](https://auth0.com/marketplace). You can now add Login with Unstoppable to your login box and let users use their Unstoppable NFT domains as an authentication method.

## Unstoppable Domains

A backbone of Web3 technology is the [public/private keypairs](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/). The public key acts as a blockchain 'address' that can be used on-chain to assign tokens and other resources. Users hold their private keys to verify ownership of the address. 

One of the usability challenges Web3 users face is interacting with these very long public addresses. If they make one typo when sending a cryptocurrency payment, it can lead to '[burned coins](https://www.coindesk.com/learn/what-does-it-mean-to-burn-crypto/)' – a mistake I made when I first started using Web3 tech.

Similar to how domain names made IP addresses human-readable in the 1980s, Unstoppable Domains is looking to make blockchain addresses more human-readable and easier to transact with through the use of Unstoppable NFT domains. 

These domains let users create a universal username, like myname.crypto, to use with any application. Instead of typing their wallet address into Web3 dApps, like cryptocurrency payment apps, they can instead use their NFT domain, provided the dApp developer implements [Unstoppable Domain's libraries](https://docs.unstoppabledomains.com/developer-toolkit/resolution-integration-methods/resolution-libraries/libraries-overview/) or [uses their API](https://docs.unstoppabledomains.com/developer-toolkit/resolution-integration-methods/resolution-service/overview/). 

Additionally, users can build out their digital identity attached to their NFT domains, bringing the Web3 vision of user privacy and data ownership to life.

## Web3 Signal Sign-On

Unstoppable is competing in the new Web3 wallet signal sign-on sector with over 150 dApp integrations and counting. They are an alternative [Identity Provider (IdP)](https://auth0.com/docs/authenticate/identity-providers) to Facebook, Twitter, or Google, etc. Instead of relying on these Web2 alternatives, users can use their wallet, facilitated by Unstoppable infrastructure, to sign in to applications.

![Web3 Signal Sign-On](https://images.ctfassets.net/23aumh6u8s0i/QnwtlykYKcnkdAySSzzH6/b43ce1324134ca5810ee537a05ecbafd/01_marketplace.png)

Unstoppable lets users enrich the profile associated with each domain with other data usually found in user profiles like social media accounts, personal data, other blockchain addresses the user owns, and more. Some of this data is accessible to anyone via the [Polygon Blockchain](https://polygon.technology/), while other data is stored off-chain and retrieved only when the user signs in with Unstoppable. 

Having profiles stored in Unstoppable available when signing in with Unstoppable Domains lowers the friction to create rich profiles in applications that use the Unstoppable ecosystem.

## How It Works

The Unstoppable team has done a lot of work making this process easy for developers. At a high level, it's two easy steps:

1. Create an Unstoppable client account. This video walks you through the process. You can also: [https://www.loom.com/share/f1655c8e94cc464188472eea80d0f921](https://www.loom.com/share/f1655c8e94cc464188472eea80d0f921); learn about its client configuration options here: [https://docs.unstoppabledomains.com/login-with-unstoppable/login-integration-guides/login-client-configuration/](https://docs.unstoppabledomains.com/login-with-unstoppable/login-integration-guides/login-client-configuration/)
1. Install and configure the social connection in the [Auth0 Marketplace](https://marketplace.auth0.com/integrations/unstoppable-domains) and Auth0 [Dashboard](https://manage.auth0.com/). Configuration instructions are on the marketplace integration page.

It takes five minutes. The (simplified) login flow looks a little like this:

![Unstoppable](https://images.ctfassets.net/23aumh6u8s0i/2z9a1dPN8BZLdbweEtBUVy/810fedf4d956033928516cc4d3331d7c/02_marketplace.png)

## What's Next?

The Auth0 Lab team is actively exploring the best ways to enable developers to build applications that rely on Web3 identity constructs and help bridge the Web2 and Web3 worlds. You can follow our progress on [Twitter](https://twitter.com/auth0lab). If you're interested in speaking with the team, join our [Discord](https://discord.gg/xkbkz9rZcD) and start a thread.

The [Auth0 Marketplace](https://marketplace.auth0.com/) is looking for Web3 partners to build new extensions onto Auth0. Visit [https://auth0.com/integrate](https://auth0.com/integrate) to learn more.


Sign in with Unstoppable Domains, Now on Auth0 Marketplace

philippederyck

Philippe De Ryck helps developers protect companies through better web security. His Ph.D. in web security from KU Leuven lies at the basis of his exceptional knowledge of the security landscape. As the founder of Pragmatic Web Security, Philippe delivers security training and security consulting to companies worldwide. His online course platform allows anyone to learn complex security topics at their own pace. Philippe is a Google Developer Expert and an Auth0 Ambassador/Expert for his community contributions on the security of web applications and APIs.

Web Security Expert, Founder of Pragmatic Web Security

Philippe De Ryck

Learn how Trusted Types help eradicate DOM-based XSS in frontend Angular and React applications.

Securing SPAs with Trusted Types

I'm a Product Designer, Visual Designer and UX Developer in the Seattle area. I create beautiful products that enhance customer experiences and drive business goals.

We provide these out-of-the-box solutions to your end users through a not-so-little product we call Universal Login.


Here at [Auth0](https://auth0.com/), we provide our customers with the means of easily implementing that one thing we all do just about every day — Authentication. Ah yes, the good ol’ email address and password. Tired of typing in that password? Yeah, we’ve got passwordless login. Need an extra layer of security? Hell yeah, you can implement two-factor authentication. We provide these out-of-the-box solutions to your end users through a not-so-little product we call Universal Login.<br /><br />

Alright, you’re probably not here to read a pitch as to why you should be using Universal Login and I’m most definitely not the right person to be doing that. In fact, what it’s capable of isn’t even that important here either. What’s more important to understand are the end users who might use this very product: Everyone. That implies people with disabilities, lower tech devices, without access to high speed internet, and the likes. If the title didn’t give it away, we’re talking about how we’ve taken steps towards creating a customizable product while remaining accessible, and we’ve started with Universal Login.<br /><br />

## Our Journey
You may have gathered this by now but if you haven’t, Universal Login is a white-label product meaning it’s meant to be re-styled to match a company’s brand. Although our journey started by using best practices towards creating an easily customizable experience for our users, we slowly started facing some of the challenges that designing both a white-label and accessible product creates and ultimately learned the importance of ensuring our product remained accessible. Sure, when building a product from scratch you can select colors that offer enough contrast, but what happens when you put that in the hands of your customers? How do we ensure that when UL is customized it remains just as accessible?<br /><br />

![Auth0s-Journey-Towards-a-Customizable-Accessible-Login-Experience](https://images.ctfassets.net/23aumh6u8s0i/5K6pIjP1kfmNlEf7cUHB2N/a2b71303b163dd89ca40bd18552c2f3b/hero_journey)

### Understanding Our Customers
As with everything, you can’t build the right product without knowing your customers, and that same concept certainly remained true here. We couldn’t build a white-label product without understanding our customer’s problems and needs, so we took our questions to them. We wanted to know what they would need to be able to customize in order to make our out-of-the-box solution viable for them and their product. Knowing their specific needs would allow us to determine areas where accessibility might be a concern and how we can ensure the product remains accessible.<br /><br />

After talking with some of our customers, our findings were generally in line with our expectations: Besides the obvious logo, primary color and background color/image were the most important variables necessary to provide a simple yet customizable experience. Defining how these are used within the experience was the fun part, and I’ll dive deep into that soon.<br /><br />

Skipping ahead a bit, the one thing on everyone’s mind during the design process was simplicity. Not just simple flows, but a simple visual language to help foster a simply customizable experience. How did we achieve this?<br /><br />

### Keeping It Simple
As designers, we love to be trendy and push design boundaries when possible. I know this because that’s something I find myself trying to do maybe a bit too often (which is not necessarily a bad thing). Either way, Universal Login was not the place for this, and that’s okay. We saved ourselves a few headaches by not going nuts trying to invent the next big design thing.<br /><br />

Here’s a perfect example: I’m sure you’ve seen those large yet subtle and soft drop shadows on buttons and cards all over Dribbble or even a few different company websites. While this is admittedly pretty, it might not match other company’s product branding, so why force it? These details are great for individual company branding, but doesn’t work for a white-label product.<br /><br />

We kept the fancy stuff to a minimum to ensure that we met branding requirements for ~95% of companies out there, not just the 5%.<br /><br />

### One color to rule them all
Besides a background color (or image), we knew that our customers wanted a customizable primary color. Could that one color be sufficient enough? That’s something that we’re still learning, but if we assumed that most companies tend to have one unique brand color, then we’re getting pretty damn close. This one color, when applied across the experience, would ensure that our out-of-the-box experience felt like yours. And to make things even more simple, we didn’t try applying this color across multiple components. Each prompt typically has one primary action button, and we found that by applying the customer’s primary color to this button, we could provide sufficient coverage of the brand color to the complete login experience.

![One-color-to-rule-them-all](https://images.ctfassets.net/23aumh6u8s0i/53pDOHpDtflqN9kbjFYHjN/51295037ae1ce7ffeec3f962016bcc5a/image_1)
<p align="center"><i>With the change of one color and a logo, we’re able to make the experience feel branded towards any company.</i></p>

### Thinking One Step Ahead
So what does all of this have to do with accessibility, you ask? We all know that if you give people the option to do something, they will do it, and for us that will result in a bright yellow button with white text over top. If we’re allowing our customer to change something as important as the button color, how could we help them ensure that the text over top had enough contrast to make it legible? It was at this point that accessibility, specifically color accessibility, became something we were actually starting to think about.<br /><br />

Our solution? Don’t let our customers make the decision on their own. Let’s do the heavy lifting and suggest the best possible contrasting text color.<br /><br />

Using some simple yet nifty code, we’re able to remain one step ahead and automatically select the best contrasting text color between black or white based on the provided primary color, all the while maintaining [AA conformance](https://www.w3.org/TR/WCAG20/) for accessibility. This is quite the improvement over the previous Universal Login experience which defaulted to a white text color and would require some development knowledge to adjust the text color if necessary.<br /><br />

![Thinking-One-Step-Ahead](https://images.ctfassets.net/23aumh6u8s0i/5xJuRIzMCwyqPowbiSfJuG/b7b737923dbc6725e52b39283a821d14/image_2)
<p align="center"><i>How the button text color changes based on the user provided primary color.</i></p>

## What Have We Done to Create More Accessible Components?
Accessibility is a topic that’s gaining traction within Auth0 and becoming something we value and incorporate into our every day process as designers. A year ago, you could have asked us “Hey Auth0, what do y’all do to be more accessible?” and our response would have been something along the lines of “not enough”. As designers, we have the power to influence the product’s direction and push for customer-centric design initiatives within our product teams, and that’s exactly what’s starting to happen. As a company, we’re now aware of the importance of providing an accessible product, and within the Login team, we’re working towards that goal every day.<br /><br />

## Color Accessibility
We started by ensuring all of our colors met AA conformance. After running out first set of colors through the [WebAIM contrast checker](https://webaim.org/resources/contrastchecker/), we were somewhat surprised to see several colors that were not passing, leading us to make another attempt at making these more accessible. This resulted in a more robust set of gray values ranging from light to dark that could be used across UI components and different variants of text. At the same time, we also improved the remainder of the colors including the secondary color (used for links and component focus states) and the set of alert colors for informing the user of success or that an error has occurred.<br /><br />

![Color-Accessibility](https://images.ctfassets.net/23aumh6u8s0i/5Piv53NiCWNJzxQWuP48Yn/42a2343cb1ec85037f9656a2d064636a/image_3)

## Low Vision Accessibility
Improvements were made to the prompts to increase readability for users with low vision by increasing the default font size to 14px except for input fields, buttons, and other interactive components where the size was increased to 16px. While we were at it, we took a moment to also increase the line spacing to match ~1.5x the font size. While increased line spacing is typically beneficial when dealing with larger paragraphs, there are a couple of scenarios where the body text of a prompt reaches onwards of four lines. Increased line spacing ensured that the body text is scannable, accessible, and readable.<br /><br />

### Other Forms of Accessibility
For users with motor disabilities, we increased the button and input component sizes alongside the increase in font size. Lastly, we ensured to create better focus states for all interactive components, including buttons, input fields, list items, and links, creating a tabbable experience that can then be completed solely by keyboard.<br /><br />

## What Does the Future Hold?
While many efforts were made over the past year, there are still areas where accessibility falls short within Universal Login, specifically for users who are blind. Our input fields remain inaccessible in this area due to the lack of labels. This forces us to rely on an icon to represent a field in the situation that the placeholder text is not descriptive enough or the field has been filled in. This is a major problem because not only is the field visually hard to understand, but this also means it’s not readable by a text reader for folks who are blind.

![What-Does-the-Future-Hold](https://images.ctfassets.net/23aumh6u8s0i/4DJJoRrM3RzNGD7vN13wNl/dbd6adafae477b7ca32e10d9b6629b98/image_4)
<p align="center"><i>Input field exploration.</i></p>

In terms of accessibility, screen reader compatibility is a top priority for us, including adjusting the input design to support labels. We’ve explored several input design options, outlined the pros and cons of each, and are currently in the process of selecting the best of the options so that we can move forward with implementation and ensure that each prompt can be read and successfully completed by using a screen reader.<br /><br />

## Conclusion
When I look at accessibility, I see it like this: It’s not an optional side quest in a video game that you can just overlook. It’s actually part of the main quest and you must complete it to truly finish the game. And while I know that sounds a bit daunting, the truth is that it’s not all that difficult to make a big impact with minimal effort. As designers, we have a responsibility to make our designs accessible for all, and we’ve gotta start somewhere.<br /><br />

At the end of the day, whether you’re reading this as a designer or as someone seeking Auth0 as a potential identity solution, know that accessibility is just as important to us as it is to you.<br /><br />

Until next time!<br /><br />

P.S. If you are considering a job at Auth0, learn more about working remotely as a designer [here](https://medium.com/auth0-design/designing-remotely-at-auth0-5d9fb8499e29) and be sure to check out our jobs page here.


Auth0’s Journey Towards a Customizable & Accessible Login Experience

joan-pepin

As CSO, Joan is responsible for the holistic security and compliance of Auth0's platform, products, and corporate environment. She brings 20 years of experience to the role, with a career that has spanned a wide variety of industries, including healthcare, manufacturing, defense, ISPs, and MSSPs. <br /><br />Previously, Joan served as Business Information Security Officer (BISO) at Nike, Inc, CISO, and VP of Security at Sumo Logic, and held different positions at Guardent/Verisign/Secureworks organization. Joan holds a patent for developing the methodology to assess whether a communication contains an attack. <br /><br />She is also is a well-recognized thought leader and has spoken at major events, such as RSA, WhiteHat Security Summit, and Forrester Security Summit, and is frequently called upon for her expertise and commentary in Cloud Security and Compliance in large-scale and DevOps/CI environments.

Chief Security Officer (CSO)

Joan Pepin

A security researcher claimed that an attacker could perpetrate a phishing scam that could target a company using the Auth0 platform based on domain. Learn about this attack, the prevalence of phishing in the industry, and how to mitigate these scams.



A security researcher working for another company recently published a blog post stating that they could potentially perpetrate a phishing attack targeting users of a website that uses Auth0 authentication. Note that phishing is not the same as hacking a code vulnerability, and therefore, no software patches can be applied because no flaw exists in Auth0's system. Let’s explore the mechanism behind this theoretical phishing attack, the prevalence of social engineering scams in today’s tech industry, and what companies and their users can do to better protect themselves.

## What is Phishing?

[Phishing](https://www.csoonline.com/article/2117843/phishing/what-is-phishing-how-this-cyber-attack-works-and-how-to-prevent-it.html) is a type of social engineering cyber attack that has been around since the 1990s and is still extremely prevalent today. Phishing typically begins with email. Emails are sent to target individuals, and these emails contain links or attachments that have malicious intent: either to install malware on the user’s device, or get them to enter sensitive data into a website that masquerades as legitimate.

Phishing attacks are [growing increasingly sophisticated](https://www.menlosecurity.com/blog/from-your-account-is-deactivated-to-oauth-the-evolution-of-phishing) in the modern landscape of the internet, and the intent is to deceive people into providing protected information, often credentials. Regardless of sophistication, however, the premise of phishing is still very straightforward.

Consider this sequence of events, for example:

1. A user of Service A (`service-a.com`) is sent an email that appears to be from Service A. The email tells the user they need to log in using a link in the email.
2. The user clicks on the link, which takes them to a login page at `malicious-service-a.com` (_not_ the real website at `service-a.com`).
3. The page has been styled to look like a legitimate page from Service A, so the user enters their credentials into the login form.
4. The credentials have then been given to the attacker, who can now access the real Service A with the victim’s stolen login information. In addition, due to the common practice of [password reuse](https://www.troyhunt.com/password-reuse-credential-stuffing-and-another-1-billion-records-in-have-i-been-pwned/), the attacker may even have access to other accounts that the victim holds on other sites.

This is just one possible example of a phishing scam flow. The attacker could just as easily ask for other kinds of personal information, or request that the user download a malicious email attachment.

## Phishing with Auth0 Subdomains

The specific idea behind the security researcher’s phishing scam was a way to target a website that uses Auth0 authentication. Auth0 supports regional subdomains: `auth0.com`, `eu.auth0.com`, and `au.auth0.com`. A bad actor could potentially attempt to scam users of a website or application that uses one of the subdomains by registering any of the other regional subdomains while using the same name. The attacker could then set up a custom page on their subdomain and, _assuming that they had access to the email addresses of users_, send them a link and attempt to solicit secure information from them. Similar scams could be attempted using _any_ domain that users could mistake for a legitimate one.

<a href="https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)">Cross-Site Scripting, or XSS</a>, was not used in the exploration of a phishing attack that could use Auth0 regional subdomains to trick users. [XSS describes the injection of malicious scripts into a vulnerable web application](https://www.incapsula.com/web-application-security/cross-site-scripting-xss-attacks.html). This exploration relied on using a custom Auth0 page in a subdomain in another region, but [no malicious cross-site code could be injected](https://auth0.com/docs/hosted-pages#why-use-hosted-pages). The ability to include JavaScript in custom pages is a feature available to Auth0 customers to enable necessary flexibility. However, _cross-site code_ cannot be executed from these pages.

## This Attack is Not New and Not Unique

As stated previously, phishing attacks have been around for decades: almost thirty years, in fact. They have become more sophisticated and insidious in their execution, but they rely on tricking people into divulging confidential information: these kinds of attacks are referred to as <a href="https://en.wikipedia.org/wiki/Social_engineering_(security)">social engineering</a>. In these scams, it is common for malicious actors to use domains that look very similar to the target domain to make their phishing attempt more convincing. This is still true now, as well as historically.

> "It's unclear why the researcher used Auth0 as a common example of phishing targeting Auth0. There are no vulnerabilities here and their research doesn't show anything new. It is simply another example of possible phishing. The same could be done with the `anycompany.com` website by using a look alike domain and then setting up a login page same as this one `https://www.anycompamy.com/Login`."
>
> –Cesar Cerrudo, globally recognized security expert and CTO at [IOActive Labs](https://ioactive.com/)

**No company that has users with email addresses is impervious to phishing scams.** There are thousands of ways to perpetrate the [same kind of phishing attempt](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/) [on any company](https://www.justice.gov/usao-sdny/pr/lithuanian-man-arrested-theft-over-100-million-fraudulent-email-compromise-scheme), aside from Auth0, [making the attacks quite prevalent](https://www.tripwire.com/state-of-security/security-data-protection/three-quarters-organizations-experienced-phishing-attacks-2017-report-uncovers/) in the tech industry.

## Phishing Relies on Tricking Users

[Phishing is not the same as hacking a code vulnerability](https://blog.varonis.com/whats-difference-hacking-phishing/), and therefore, no software patches can be applied because no flaw exists in Auth0’s system. The particular phishing attack described by the security researcher is not being actively used. Auth0 provides security measures to help prevent credential harvesting via phishing, such as [Single Sign-On](https://auth0.com/docs/sso/current), [Multifactor Authentication](https://auth0.com/learn/get-started-with-mfa/), and [Passwordless](https://auth0.com/passwordless). In addition, [Breached Password Protection](https://auth0.com/breached-passwords), [Brute Force Protection](https://auth0.com/docs/anomaly-detection#brute-force-protection), and [Anomaly Detection](https://auth0.com/docs/anomaly-detection) can help mitigate the potential outcomes of phishing attacks. Auth0 also supports the use of [Custom Domains](https://auth0.com/docs/custom-domains), which removes `auth0.com` (or regional `auth0.com` subdomains) from your application and replaces with a domain of your choosing, which completely eliminates the ability of an attacker to perform this scam using Auth0 subdomains.

However, it is important to remember that **phishing scams are quite common and easy to execute if an attacker already has your users’ email addresses**. Although using an Auth0 Custom Domain or registering all regional Auth0 subdomains eliminates the attack avenue described in this specific case, an attacker could still register any other Top Level Domain name that is similar to yours and attempt to deceive your users. For example, if your company’s login domain is `login.real-company.com`, a phishing attack could be perpetrated from a similar domain, such as `login.rea1-company.com`. In addition, a bad actor could just as easily send a malicious email attachment to your users instead.

## Protecting Your Company and Users

The safety of companies and their users should be the paramount concern when discovering and sharing information regarding security. Not committing to thorough research can negatively impact customers, users, and the general technology community.

Any company implementing authentication of any kind — proprietary or using an Identity and Access Management platform such as Auth0 — should have security practices in place to mitigate phishing attacks. These practices should include regular internal anti-phishing campaigns and training, as well as Multifactor Authentication or Passwordless. Monitoring for lookalike domain names is also recommended. With the proliferation and increasing cleverness of phishing scams, the importance of awareness and training cannot be understated.

Phishing Attacks with Auth0? Facts First

justin-hinerman

Justin is a Software Engineer at Auth0, focusing on solving authorization challenges for customers. Before Auth0, Justin spent several years as an Identity Management consultant and architect. It was in this job that he came to appreciate the many challenges customers face when trying to implement identity. This knowledge informs his current work at Auth0, trying to make identity as simple as possible for our customers. In his free time, he enjoys spending time with his family, playing soccer, camping, traveling, and playing drums.

Software Engineer

Justin Hinerman

Auth0 now provides your own custom domain for login with a central authorization server.



## Using Custom Domains to Brand Central Authorization Servers

Authenticating with a provider through a central authorization server provides you with a standards-based, maintainable, and secure login approach. This type of login also provides single sign-on benefits and a modern user experience. You can explore the[ benefits of this architecture further in this blog post](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/).

For those who are not familiar with the concept, you may have noticed that you are always redirected to [accounts.google.com](https://accounts.google.com) when you log into Google sites such as Gmail or Youtube. Google has a _central authorization server_ that is used across all of their applications and third-party apps.

![Google central authorization server](https://images.ctfassets.net/23aumh6u8s0i/7CnL0OedgtBQGe3FxUbyfE/f94f36fcd0c31e2fccd6570b1d6c8fb7/google)

Auth0 provides this same capability out of the box, allowing you to unify login for your own brand and products. Enabling Auth0's central authorization provider, [Universal Login](https://auth0.com/docs/hosted-pages/login), is easy, straightforward, simple to configure, and can be customized to suit your brand.

Customers who prefer this experience to be served from their own domain, instead of `[your-account].auth0.com`, can configure their own custom domain in Auth0. This feature is available for all free-tier customers. Adding your own custom domain to an existing implementation only requires small code changes thoroughly detailed in our [custom domain setup docs](https://auth0.com/docs/custom-domains#step-3-complete-feature-specific-setup). Simple configuration can be completed within your Auth0 dashboard.

<include src="TweetQuote" quoteText="You can configure your own custom domain in Auth0. This feature is available for all paid customers."/>

## Benefits of Using a Custom Domain

### End-User Benefits

By using a custom domain for your authentication page, you keep your users interacting with you within the context of your brand, which helps you build brand loyalty. Users are not redirected to a third-party site that breaks the branding context. This prevents users from becoming confused about whether or not they are still running a transaction or operation with you.

For example, if your Auth0 domain is `northwind.auth0.com`, you can have your users to see, use, and remain on `login.northwind.com`.

<include src="TweetQuote" quoteText="Using a custom domain with Auth0 allows your users to feel confident that they are providing their credentials to the right party. Authentication happens within the context of your brand."/>

Auth0 support for custom domains allows us to do the authentication heavy lifting for you without compromising your branding experience.

### Customer Benefits

Brand loyalty from users is a pillar for the success of an organization of any size. One of the ways to build brand loyalty is by offering a consistent branding experience to users. It's important that your users always feel that they are interacting directly with you to avoid confusion or session abandonment.

From the security point-of-view, using [Universal Login](https://auth0.com/docs/hosted-pages/login) is the preferred way to handle end-user credentials. It allows you to have comprehensive control of authentication in one centralized place, as opposed to having individual applications handling credentials. Consequently, having your authentication services contained in one place will make your application architecture more maintainable. Applications are only given the access they need and authentication services can be scaled easily.

You can mitigate certain phishing attacks when your users expect to run transactions within your domain. Having that domain consistency will allow your users to easily and quickly reject phishing attempts.

Universal Login also offers you simplicity as an implementation advantage. You don't have to worry about integrating login user interfaces into different applications. When you use Auth0 Universal Login, you get all the features you need in the fastest possible way: redirecting to a common login interface. Adding custom domains to this workflow creates a seamless experience for your developers and end-users.

## Custom Domain Authentication Features

Core Auth0 features and flows support the use of custom domains:

* OAuth 2.0/OIDC-Compliant Flows (those using the `/authorize` and `/oauth/token` endpoints).
* Database and Social Connections.
* SAML Clients and Connections.
* A full list of features supporting the use of custom domains is available in the [feature section](https://auth0.com/docs/custom-domains#features-supporting-use-of-custom-domains) of our custom domains document. New features, such as enterprise connections, will be added to the list as they become available. Keep an eye on that space!

## How It Works

To [configure your custom domain with Auth0](https://auth0.com/docs/custom-domains#how-to-configure-custom-domains), go to your account settings, select Custom Domains, add your own domain, and follow the instructions.

![Auth0 custom domains tenant settings](https://images.ctfassets.net/23aumh6u8s0i/4sOb3yHNVMECyroBboPtTX/11e347f12d8b3ee97b028818e021cbfc/custom-domain-setup-auth0-dashboard.png)

You will need to complete a [verification process](https://auth0.com/docs/custom-domains#step-2-verify-ownership) for your domain that varies depending on whether you decide to use an Auth0-managed or a [self-managed certificate](https://auth0.com/docs/custom-domains/self-managed-certificates#step-2-verify-ownership).

Your existing integrations using your `[your-account].auth0.com` domain will continue to work. After migration to your custom domain is complete, users will have to log in again since existing sessions will no longer be valid.

## Custom Domain Self-Service

Different than other solutions, Auth0 not only gives you the option to use a custom domain, but Auth0 also empowers you with full control over setting up and using your custom domain for authentication. Flexible self-service options are available through our Dashboard for you to directly handle selecting, verifying, and implementing your custom domain. You don't have to wait on us for anything to complete this process. You are in charge.

## Using Custom Domains with Auth0

[Atlassian](https://www.atlassian.com/) is an early-adoption Auth0 customer using a custom domain. Atlassian is consolidating all of their B2B and B2C products under a central authorization provider at [id.atlassian.com](https://id.atlassian.com).

![Atlassian central authorization provider](https://images.ctfassets.net/23aumh6u8s0i/6gwmZK2fxPEmUWFZ1t4Tdf/85045a917ff13e7b2951a593aa836a03/atlassian)

Other Auth0 customers currently using custom domains with a central authorization server include [AGL](https://www.agl.com.au/residential), [National Life Group](https://www.nationallife.com/), and [News UK](https://www.news.co.uk/).

With the launch of custom domains with Auth0, your users will benefit from a first-class login experience, while keeping your brand through a trustworthy domain.

<include src="TweetQuote" quoteText="Using custom domains with Auth0 allows your users to benefit from a first-class login experience while keeping your brand through a trustworthy domain."/>

For more information, check out our [Custom Domains documentation here](https://auth0.com/docs/custom-domains).


Take a No-Compromise Approach to the Login Experience Using Custom Domains

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Username and password still dominates, but not for long



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

---

In 2017 we have more options than ever before for strong password management. Between [social](https://auth0.com/docs/extensions/custom-social-extensions#social), [enterprise,](https://auth0.com/docs/extensions/custom-social-extensions#enterprise) and [Passwordless](https://auth0.com/docs/extensions/custom-social-extensions#passwordless) connections, companies that are ready to offer more than username and password have several good options.

This is great news, considering that [59% of consumers](https://www.passwordboss.com/password-habits-survey-part-1/) will admit that they reuse the same password—simply because it's too hard to remember a unique password for every account. In 2017, companies are offering simpler, safer options than just traditional username and password. And we're already seeing a big shift happen.

Throughout 2016 we gathered data on how Auth0's users and our user's users were using Auth0. Let's check in on how things are changing, and what's staying the same.

## What Types of Connections Are On The Rise?

Single Sign On (SSO) and Passwordless have been around for a while, even as traditional username and password (U/P) have been around much longer. In 2015 we launched Auth0 Passwordless, which  removes passwords from the login process completely and instead uses “Magic Links” sent through email or one-time codes sent through SMS.

Since 2015 we've seen Passwordless grow at a fairly steady rate of 10,000-20,000 connections [per month](https://auth0.com/blog/analysis-of-passwordless-connections/), though it hasn't yet caught up to social or enterprise login. Social connections have seen a big increase in 2016 and it's easy to see why. Users log into your site with existing login information from a social network provider. It's quick and takes out a lot of friction for the user.

Here's our data for 2016. We can see how U/P, enterprise (authentication through LDAP, Microsoft, Google Apps, and other clients), social, and Passwordless connections stack up:

![Username & Password vs Enterprise vs Social vs Passwordless](https://images.ctfassets.net/23aumh6u8s0i/1IUGDM1r0SZKtNGJ3Ur2K7/387ff9d6a7105ea1b77107060c310572/enterprise-social-passwordless)

While traditional username and password logins still dominate at 67% in 2016, we also saw the number of social connections **double** from 2015.

In 2015, Passwordless and social together only amounted to **5%** of our total use. We grouped them together as SSO here:

![Total users](https://images.ctfassets.net/23aumh6u8s0i/18Lc26UhXJk0WbR6Ir20k3/7ba5937d3bf272dba9331bf29e3afb98/total-users)

Yet in 2016, **11.10%** of all logins were social connections. This tells us that more and more users are beginning to see social connection as a stronger, more convenient option than U/P.

Companies too are finding U/P [less effective](https://auth0.com/blog/2015/12/16/how-to-use-social-login-to-drive-your-apps-growth/) and less attractive, as offering [social connection](https://auth0.com/blog/analysis-of-social-connection-data/) can increase conversion rates by as much as 50%. With more login options becoming available over the past few years, it can seem daunting to pick the right one and stick with it. Customer-facing apps would do well to include social in the mix.

## Top Used Social Connections

Now that we've seen how social is rapidly becoming more popular with a 2x growth in connections from 2015 to 2016, let's take a closer look at *which* social platforms users are using to log in.

Throughout 2016, we collected data to find out which social connections were being used most often:

![Social connections by popularity](https://images.ctfassets.net/23aumh6u8s0i/1IehHLWWCHMvieiOmANwqa/335e09ace0083a2eed19aa86f88e5472/social-connections-by-popularity)

In 2016 Google was the most popular social connection at **48.7%**, nearly double Facebook's share at **26.6%**. GitHub came in third place at **9%** before Windows Live at **3.6%**.

The biggest shift from our [2015 data](https://auth0.com/blog/analysis-of-social-connection-data/) is that **Twitter** dropped from fourth to seventh place, at **2.6%**.

As in 2015, these distributions are roughly reflected in the estimated monthly site visits of each of these sites, according to data from [Alexa.com](http://alexa.com/), Google's and Facebook's visitor numbers are in the billions, while Windows Live and Twitter are dwarfed in the millions, with [Twitter's use declining](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=9&cad=rja&uact=8&ved=0ahUKEwivlKXtxvzTAhXJqFQKHQ2dCYoQFghSMAg&url=https%3A%2F%2Fhbr.org%2F2016%2F02%2Fthe-reason-twitters-losing-active-users&usg=AFQjCNHTzjPHEveNh03-RjDUqEQ75et4nQ&sig2=_uqjOMNw9-vN9hh94-l6Fg).

So, social connection is clearly growing in popularity, and as these numbers suggest, Google and Facebook are still driving a lot of that growth. Yet dark horse **GitHub** climbed up to third place for social login in 2016. A full 9% of social connections through Auth0 came through Github, a developer-focused site that barely has a fraction Google's user numbers.

If you want to personalize your site's experience with social connection, go deeper than Google and Facebook and think about what smaller platforms your users are on. If your users are all developers who are on GitHub everyday, take note of that. If your users are in sales and marketing, have them log in through Salesforce. If they tend towards editorial and publishing, have them go through WordPress.

## When Will Single Sign On Surpass Username & Password?

In 2015, using the data we collected, we projected growth estimates for Passwordless implementation in relation to traditional U/P. We predicted that Passwordless would overtake U/P in mid-2027:

![Forecast username & password vs Passwordless](https://images.ctfassets.net/23aumh6u8s0i/4PiztzzQ7MN4ZuwSDTFf8O/213446c245763ff4411108f1197b057b/forecast-up-vs-passwordless)

Using our data from 2016, we ran the same growth estimates for Passwordless implementation against U&P and came up with an even more surprising outcome.

At this point we can see that Passwordless is projected to overtake U/P in mid 2020:

![Forecast (U/P vs Passwordless](https://images.ctfassets.net/23aumh6u8s0i/7w7wW4MpYUiHERIBiuQg36/3893b35a0212e78bb02f5cbfbea7b669/up-vs-passwordless-2020)

When looking at our first chart in this post, Passwordless seems like a small player. Among Auth0 users and our users' users, 67% of logins are still U/P.

But once we take into account the growing share of social connections, and how different platforms are positioning themselves within the social login space, we can see big shifts happening. And they're happening faster than we thought a year ago.

With so many other options available for authentication, including social, enterprise, and Passwordless, the number of people using U/P is likely to decrease significantly. As more users begin to understand U/P as the most inconvenient and least secure option, we could very well see its share drop below 50% in 2020. It's already down to 67%.

## Looking to 2017 and Beyond

From 2015 to 2016 we saw the dominance of U/P slip even further. It still makes up about 67% of our users' logins, but that's changing fast. With social connections jumping up 2x and some interesting changes within that group, we could see SSO overtake U/P much faster than we're expecting right now.

In running this analysis of our 2016 data we found 16,972 logins with breached passwords being entered every month, on average. In April of this year, 4.42% of logins were with leaked credentials. On average, we added 40 million new leaked credentials to our database in 2016.

These numbers may seem startling, but they also illustrate why companies are moving away from U/P so rapidly. Safer, simpler options are available and the industry is having a lot of success nudging users towards social, enterprise, and finally Passwordless options like one-time codes and Magic Links.


2016 Social, Passwordless and SSO Data: What Can We Learn?

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

We have updated our latest benchmark article to use array keys and see what happens!

More Benchmarks: Virtual DOM vs Angular 1 & 2 vs Others

You asked? We listened! Benchmark series is back with even more frameworks and metrics!

Take a look at competing DOM manipulation libraries and find out which one is faster with a performance benchmark!



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Visit <a href="/blog/build-and-authenticate-an-emberjs-3-application/">Build and Authenticate an EmberJS 3 Application</a> to read our most up-to-date tutorial.</strong>
</div>

In this post we will explore three technologies to build dynamic DOMs. We will also run benchmarks and find out which one is faster. At the end we will share with you why we choose one of them for our projects. Read on!

-----

## Introduction
There are many [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) manipulation frameworks and libraries. Among these, three have been the center of the attention due to their focus on performance: [React.js](https://facebook.github.io/react/), [Ember.js](http://emberjs.com/) and, more recently, [Incremental DOM](https://github.com/google/incremental-dom). While React and Ember handle much more than just DOM building/update, Incremental DOM focuses only on building DOM trees and allowing dynamic updates. We will now explore these libraries and find out which one is faster.

![DOM tree](https://images.ctfassets.net/23aumh6u8s0i/6oEcAYeaWwsrEMXh7SVwil/6dfc83c50b2ef5a51ea37fd7217dd3c4/domtree)

Before getting into the details, if you are not a web developer, you might be asking yourself what exactly *DOM manipulation* is. Web sites are built as trees of different elements. These elements are defined in the HTML spec. By composing these elements a developer can create arbitrarily complex web sites. The DOM is the abstract representation of a website as a tree of HTML elements. It is defined by a [W3C spec](http://www.w3.org/TR/DOM-Level-2-Core/introduction.html) and implemented by all major browsers.

Besides aiding in binding the data model to the view, these libraries help in doing updates to DOM **efficiently**. A series of updates that would normally be performed by manually issuing a series of DOM API calls can be automatically batched into a single call (or a reduced set of calls). For instance, suppose the logic behind an update to the site requires that you:

1. Remove an element
2. Add a new element
3. Change a property of the added element

Directly issuing DOM API calls for doing changes such as these will result in intermediate repaints and reflows of the content. These are expensive operations. By working on a virtual model these steps can be flattened into one.

### Templates
Templates are a popular way of building DOM trees. With templates a developer can use a specific template syntax that tells a template compiler how to turn that into a DOM tree (or HTML document). Templates can look like an extension of HTML, or be completely different.

Not every library in this post favors the use of templates. For instance, React favors the use of JSX: an extension of Javascript (in the form of a precompiler) that allows easy insertion of HTML-like snippets in Javascript code. Ember, on the other hand, favors the use of [Handlebars](http://guides.emberjs.com/v1.10.0/templates/handlebars-basics/), a template language.

Incremental DOM does not favor any particular template engine. However, being a Google sponsored project, a [Closure templates](https://github.com/google/closure-templates/) backend is being developed. Incremental DOM can also be used with [superviews.js](https://github.com/davidjamesstone/superviews.js), [starplate](https://github.com/littlstar/starplate) and even [JSX](https://github.com/babel-plugins/babel-plugin-incremental-dom).

## React.js' Virtual DOM
*Virtual DOM* is the name React developers gave to their DOM manipulation engine. *Virtual DOM* provides a series of Javascript calls that tell the library how to build an **in-memory DOM tree** and how to update it when data bound to it changes. The central piece of Virtual DOM is its **smart diffing algorithm**: once the differences in the model have been mapped to the in-memory copy of the DOM, the algorithm finds the **minimum number of operations required to update the real DOM**. This results in two copies of the in-memory DOM being present during the diffing process.

![React.js' Virtual DOM](https://images.ctfassets.net/23aumh6u8s0i/oM52qwUuOVavnUKS8fStA/ebb35ef8e24191bbeb4cea8efca1aaad/reactdom)

> Disclaimer: some of the graphics in this post are based on the ones found in this [excellent post explaining DOM manipulation libraries](http://teropa.info/blog/2015/03/02/change-and-its-detection-in-javascript-frameworks.html)

#### Pros
- Fast and efficient "diffing" algorithm
- Multiple frontends (JSX, hyperscript)
- Lightweight enough to run on mobile devices
- Lots of traction and mindshare
- Can be used without React (i.e. as an independent engine)

#### Cons
- Full in-memory copy of the DOM (higher memory use)
- No differentiation between static and dynamic elements \*

\* React has [recently implemented](https://github.com/facebook/react/issues/3226) functionality that detects constants and reduces the number of elements that need to be checked for updates.

## Ember.js' Glimmer
*Glimmer* is the name for Ember.js' latest rendering engine. Glimmer is the result of Ember's developers trying to integrate the benefits of React's Virtual DOM engine into Ember while maintaining API compatibility. Do note that Glimmer is a full rewrite of Ember's rendering engine and in no way shares code with Virtual DOM.

Glimmer differentiates between **static** and **dynamic** components, thus reducing the number of elements that need to be checked when looking for changes. This differentiation can be achieved thanks to the expressiveness of Handlerbar's templates.

Another key difference between Glimmer and other solutions lies in the way nodes are stored and compared. Glimmer stores nodes as simple stream-like objects (that is, simple queues of values) rather than full-fledged DOM-like nodes. To find out whether a real DOM node needs updating, the final value of a Glimmer node is compared to the last known real DOM value. If the value has not changed, no further actions are taken.

![Ember.js' Glimmer](https://images.ctfassets.net/23aumh6u8s0i/7lAoKFzu3mk96HBlvgU9Jb/a77719062e194ee06fbb14d4260fa2a3/emberdom4)

#### Pros
- Fast and efficient diffing algorithm
- Differentiation between static and dynamic elements
- 100% compatible with Ember's API (you get the benefits without major updates to your existing code)
- Lightweight in-memory representation of the DOM

#### Cons
- Meant to be used only in Ember
- Only one frontend available

## Incremental DOM
Incremental DOM tries to bring a simpler approach to the table than the alternatives: rather than keeping a full in-memory representation of the DOM, or keeping a tree of lightweight elements, Incremental DOM uses the **real DOM** to find differences when data changes. You might be asking yourself why, if this is simpler, it hasn't been the solution picked by other libraries all along. Simple: it results in a **tradeoff between speed and memory**. Incremental DOM, by removing the additional copy of the DOM, results in **reduced memory usage**. In practice this also results in **reduced speed** while looking for differences. The reduced memory usage is key for mobile or other memory constrained devices. Read [our article on Incremental DOM](https://auth0.com/blog/2015/10/23/incremental-dom/) for more information on this.

![Incremental DOM](https://images.ctfassets.net/23aumh6u8s0i/10r0ke7cIPEQoAPjxzuVdS/0fb7fe4a20ce7cd1ca7c146b82bf2577/idom)

#### Pros
- Reduced memory usage
- Simple API
- Easily integrates with many frontends and frameworks (meant as a template engine backend from the beginning)

#### Cons
- Not as fast as other libraries (this is arguable, see the benchmarks below)
- Less mindshare and community use

## Benchmarks!
For our benchmarks we have picked the [dbmonster test app](https://github.com/wycats/dbmonster) as [shown in this post](http://blog.nparashuram.com/2015/03/performance-comparison-on-javascript.html). `dbmonster` is a simple application that simulates the load caused by an application updating tons of rows in a table that shows the activity of different simulated database clusters. This application was originally developed to test Ember's performance. We have run this test using the latest versions of React, Ember 1.x and 2.x (both use Glimmer) and Incremental DOM. All tests were run using Chromium 46 on Linux (Core i5-5200U CPU). Five passes were performed for each test and then averaged.

![Major GC time losses](https://images.ctfassets.net/23aumh6u8s0i/2iFPuzIou6JUyGYeztDEJB/6c9ad47c00d5181722b91eb7c972314d/MajorGC)
![Minor GC time losses](https://images.ctfassets.net/23aumh6u8s0i/3bLUVwYmUBOG2hdkjZhFvV/31a19b6ca2ab336b9b30a427b2827c2e/MinorGC)

In these charts the time spent during major and minor GC collections can be seen. As expected, Incremental DOM is much more efficient in this area. React remains a close second for major collections but falls way behind Incremental DOM in minor collections. It is interesting to note how much Ember has progressed from version 1 to version 2 in this area.

![Layout and Paint time losses](https://images.ctfassets.net/23aumh6u8s0i/3JMcJsuB8PCbu65nL0uurq/2973f5ab3d915eb360c77467693d4dce/LayoutAndPaint)

Ember shines in this case: time spent doing layout operations and then performing the actual paint to the screen. Incremental DOM trades memory usage for speed so it is expected in this case to see it behind the alternatives. React stays close to Ember and appears balanced so far.

![Dropped frame counts](https://images.ctfassets.net/23aumh6u8s0i/5H6504nEFMusXwSbnIsNHe/7f30a178d740d49cac78dbcadb4e1c0e/droppedFrameCount)

This charts shows the number of frames that Chrome decided to drop (i.e. to stop drawing) due to long pauses. Dropped frames result in lower framerates and visible pauses. In this case, Incremental DOM shines again. Less time spent in GC pauses means more time is available to draw frames. React, Ember 1 and Ember 2 all remain close behind Incremental DOM.

One important thing that is not shown in the charts: the subjective feeling of the browser when using it. Incremental DOM seemed much more responsive. By taking a look at the collected data, Incremental DOM appears to be making less JavaScript calls than the alternatives. It should be noted that while Incremental DOM is just a library to dynamically update the DOM, both React and Ember handle much more: events, data passing, etc. A proper test of Virtual DOM without React should be interesting.

Take a look at the [full](https://github.com/auth0/blog-dombench/blob/master/article_results/data.json) and [summarized](https://github.com/auth0/blog-dombench/blob/master/article_results/results.csv) results.

[Get the full code](https://github.com/auth0/blog-dombench) for the tests. To run the tests, you will need ChromeDriver and all node.js dependencies for the test driver (json2csv, browser-perf). Once all dependencies are installed, run `node run-benchmarks.js`. Once the tests are done, results can be found in `data.json` (full) and `results.csv` (summarized).

## Aside: React.js use at Auth0
At Auth0 we are constantly evaluating the best technologies for our platform. For the development of our [Passwordless Lock library](https://github.com/auth0/lock-passwordless/) we picked React.js. React is an excellent choice because of its unopinionated integration model and its declarative way of developing components. On other fronts, React remains a well balanced approach between speed, memory usage, ease of integration and good documentation/support.

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign-up</a> and start using our Passwordless Lock library in a minute! Or take a look at the [code](https://github.com/auth0/lock-passwordless/).

## Conclusion
Virtual DOM, Glimmer and Incremental DOM are all excellent options for handling dynamic DOM updates. React's mindshare and ease of integration make it a no brainer for many projects. Increased memory use can be a problem in memory constrained devices for big websites. This problem, however, is getting smaller everyday as mobile devices carry more and more memory. Incremental DOM surprises by remaining fast even when doing less. We look forward to seeing Incremental DOM integrated into Closure and other libraries. React and Ember remain as well balanced approaches each favoring different development methodologies.

<include src="TweetQuote" quoteText="Virtual DOM, Glimmer and Incremental DOM are all excellent options for handling dynamic DOM updates."/>

When picking one of these libraries focus on mindshare and ease of integration unless you are pushing the number of updates per frame to the limit. In that case, study carefully the results from this post and don't forget to run your own specialized benchmarks.


React Virtual DOM vs Incremental DOM vs Ember’s Glimmer: Fight

647b1eea820b3fc8a5aee0383930b888

Pablo Terradillos

Learn how Incremental DOM works and how it compares to Glimmer and Virtual DOM



## Introduction

Hitting the DOM is probably the most expensive operation that most modern web applications must perform, and much effort has gone into providing solutions to solve this problem.

Without a doubt, the one that has gained the most popularity in recent times is the so called _virtual DOM_. Introduced by Facebook's React library, it basically builds an in-memory representation of the DOM. On every update made that is made to the UI, it will create a new representation, diff against it, and only hit those nodes that need to be changed in the _real_ DOM.

Ember's implementation is called _Glimmer_, and it is a substantial improvement to React's. Instead of building a complete representation of the _DOM Tree_, it just takes the elements from a Handlebars template that are dynamic and builds a _tree of streams_, reducing the amount of memory needed to keep them.

Google is working on a different approach with [Incremental DOM](https://github.com/google/incremental-dom) (IDOM). We can say that it has the same base as _virtual DOM_, but with a different approach: **instead of building a representation of the _DOM tree_ in memory, it just uses the real DOM to diff against new trees.**

While React provides JSX as a template engine and Glimmer relies on HTMLBars, **IDOM** is just a simple API for building DOM elements and is not intended to be used directly but as a compilation target for template engines.

In this article, we're going to explore the simple Incremental DOM API by building a library to work with it, along with a functional to-do app.

## Working with Incremental DOM (IDOM)

The IDOM API just consists of four functions for building DOM elements:

* `elementOpen`  - Which corresponds to an opening tag (e.g. `<div>`)
* `elementClose` - Which corresponds to a closing tag (e.g. `</div>`)
* `elementVoid`  - Which corresponds to self-closing tags (e.g. `<input />`)
* `text`         - Which corresponds to text nodes.

So, imagine that we want to produce the following output:

```html
  <div class="foo">
      Hello world!
  </div>
```

The corresponding IDOM function will be:

```js
import ID from 'incremental-dom'

function renderHello() {
  ID.elementOpen('div', null, ['class', 'foo'], null);
  ID.text('Hello world!');
  ID.elementClose('div');
}
```

It should be clarified that `elementOpen` receives three extra parameters besides the tag's name. It also accepts the `key` that will identify the element (we will come back to this later), an array of _dynamic properties_, and another one of _static properties_ (i.e. the ones that are not intended to be changed). Both arrays consists of property-value pairs.

Finally, IDOM provides a `patch` function that will walk our current DOM, diff it against the DOM we want to insert, and finally modify just those elements that need to be modified.

So, if we want to render the previous "DOM declaration" into our app we need to do

```js
patch(document.body, renderHello);
```

And that's it! All you need to know is that `patch` receives an extra parameter that will be passed as an argument of the render function, and you can say to all your coulleages that you know Incremental DOM.

That was a simple example, but the real power comes when we have a DOM structure that constantily needs to be changed. Lets build a _real app_ to see how it works.

## Making IDOM friendlier

The API that IDOM provides makes it really simple to target a custom template engine or any other more expressive API. Lets build something to write our components in a more declarative way.

<include src="TweetQuote" quoteText="The API that IDOM provides makes it simple to target a custom template engine or any other more expressive API."/>

Taking a look at the HTML, we know that each element can contain text or other elements, so lets build a recursive function to allow that using JavaScript. The final result will be an API that allow us to write IDOM components like the following:

```js
ul([
  li('one'),
  li('two'),
  li('three')
], null, ['class', 'foo']).renderTo(document.body);
```

This will render into our body:

```html
  <ul class="foo">
    <li>one</li>
    <li>two</li>
    <li>three</li>
  </ul>
```

Simpler, right?

We want our elements to be capable of receiving one or more elements as children or even simple strings (text nodes) just as in regular HTML. So lets start building a class to represent this structure:

```js
import ID from 'incremental-dom';

class EL {
  constructor(tag, content, key, dynProps, staticProps) {
    // We want to hold local references to element's props
    this.tag = tag;
    this.content = content;

    // We are going to implement a _private_ TEXT class to provide the same interface
    // we have for our elements to Text Nodes.
    // So if we pass a string as an element, we just convert it to this class.
    if ('string' === typeof this.content) {
      this.content = new TEXT(this.content);
    }

    // We allow the users to pass a single element as a child.
    if (!Array.isArray(this.content)) {
      this.content = [this.content];
    }

    this.key = key;
    this.dynProps = dynProps;
    this.staticProps = staticProps;
  }
}
```

In this code, we convert strings to a `TEXT` class so we can have the same interface on Text Nodes as we do in regular elements. Lets implement it:

```js
// ...

class TEXT {
  constructor(content) {
    this.content = content;
  }

  render() {
    ID.text(this.content);
  }
}
```

finally, the render function for our EL class can be written as follows

```js
//...
class EL {
  // ...

  render() {
    // Passing a `null` content, we can assume that we're creating a
    // self closing tag (e.g. `<input />`).
    if (null === this.content) {
      ID.elementVoid(this.tag, this.key, this.props);
      return;
    }

    ID.elementOpen(this.tag, this.key, this.props);

    // Since we have `normalized` our elements to
    // always have the same interface, we can just walk
    // throught them and call it `render` method.
    this.content.forEach((c) => c.render());

    ID.elementClose(this.tag);
}
```

Finally, we need a way to `patch` our element to the DOM:

```js
//...
class EL {
  //...

  renderTo(container) {
    ID.patch(container, this.render.bind(this));
  }
}
```

To make things easier, lets create _builder functions_ so we can just call the elements by its name to construct them (i.e. `div('foobar');`)


```js

// We build helpers function for each DOM tag (reduced to those we're going to need in our up to make it simpler)
let elements = ['div', 'span', 'ul', 'li', 'h1', 'h4'].reduce((prev, tag) => {
  prev[tag] = (elms, key, props) => {
    return new EL(tag, elms, key, props);
  }

  return prev;
}, {});

// we export this elements so we can use them as a module in our project.
export default elements;
```

I have published this as a package called _charata_ that you can find on npm (`npm i charata`). You can take a look at its repository on [Charata's Github repo](https://github.com/auth0/charata).

## Working with DOM

Lets start building our todo app by writing our HTML file:

```html
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Incremental TO-DO</title>
</head>
<body>
 <form id="add-todo">
  <input type="text" name="new-item" />
 </form>

  <div id="todo">
  </div>

  <script type="text/javascript" src="incremental-todo.js"></script>
</body>
</html>
```

As you can see, I've put a form element with an input inside in "plain" html and left a `#todo` element where we're going to render our _to-do component_. This is just to emphasize the flexibility of working with static html and our recently created library, but you can create a custom component for the `form` as well.

Inside our `incremental-todo.js` file, we're going to create a `class` to represent our todo list. Objects from this `class` should be capable of:

  * Adding a new item to the list.
  * Removing an item from the list.

On every list mutation, we want to re-render our list (which is going to be represented with a component created with our previous helper).

```js
export default class TodoList {
  constructor() {
    this.list = {};
  }

  /**
   * Adds a new item to the list
   *
   * @param {string} text todo-item's text
   */
  addItem(text) {
    var idx = Date.now();
    this.list[idx] = text;
    this.render();
  }

  /**
   * Removes an item from the list.
   *
   * @param {string} idx id of the element to remove
   */
  removeItem(idx) {
    delete this.list[idx];
    this.render();
  }
 }
```

We haven't yet used anything from IDOM or our custom library and the `render` function is called on every mutation of the list. We're going to implement it later, but for now, just note that we have an `id` attribute for each item. This is what we're going to use to identify each individual to-do item and provide it to IDOM (the second parameter of `elementOpen`).

But before the real fun, lets attach an event handler to our form so we can add elements to the list:

```js
let form = document.getElementById('add-todo');

form.addEventListener('submit', (ev) => {
  ev.preventDefault();
  let input = form.elements.namedItem('new-item');
  myList.addItem(input.value);
  input.value = '';
});
```

Great! we're adding elements to our list. To render them to the DOM, we need to implement the `render` function from our `TodoList` class.

```js
 //...
 render() {
   if (this.list.length) {
     ul(Object.keys(this.list).map((idx) => {
       li(this.list[idx], idx, ['data-idx', idx]);
     }), null).renderTo(this.container);
   } else {
     div('Hooray! you are free!', null, ['class', 'center']).renderTo(this.container);
   }
 }
```

Note the `idx` that we've passed to each `li` element. This is what IDOM is going to use to identify elements when we're rendering collections (similar to the `key` property in React).
We're rendering it as a `data-attribute` so we can add an event handler to each of them and identify which is the one we want to delete.

```js
let liElements = document.getElementsByTagName('li');

Array.prototype.forEach.call(liElements, (liEl) => {
  liEl.addEventListener('click', (ev) => {
  ev.preventDefault();
  let idx = LiEl.dataset.idx;
  this.removeItem(idx);
});
```

Feel free to have a look at the [final implementation](http://auth0.github.io/incremental-todo/) of the todo app.

Fire up your inspector and note that even though we're telling our component to re-render itself every time an item is added or deleted, IDOM takes care of re-rendering just the item that changes:

![Incremental DOM in action](https://images.ctfassets.net/23aumh6u8s0i/3p6QirpaLgeZIl0qurNNIn/420bea382bfcca83e3659475c96b484c/incremental-dom)

## Conclusion

The Incremental DOM approach seems to not be as fast as _virtual DOM_ based implementations. However, IDOM uses less memory since it doesn't need to maintain a _live_  representation of the DOM. Rather, it uses the _real DOM_ to walk and compare against the new *state*. This is great for underpowered devices like low-end phones.

IDOM's simple API makes it really powerful for targeting template engines. Google is working on using it as a backend for [Closure Templates](https://developers.google.com/closure/templates/) and there's also an implementation of React's JSX syntax using a [Babel plugin](https://github.com/babel-plugins/babel-plugin-incremental-dom) so we can expect a lot of other template engines to start using it in the short term.

In Auth0 we take performance as a primary goal for each of our products. We are investing a lot of time analyzing view engines. We recently released [Lock Passwordless](https://github.com/auth0/lock-passwordless) which uses React and we're exploring integrate Incremental DOM on some of our current products.
We also have an SDK to use [Auth0 with React](https://github.com/auth0/auth0-react)

To learn more about it, you can take a look at the [Incremental DOM repo](https://github.com/google/incremental-dom).

## Aside: Authentication is Easy with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [single sign-on](https://auth0.com/docs/sso/single-sign-on), user management, support for social (Facebook, Github, Twitter, etc.), enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code.


Incremental DOM 101: What is it and why I should care?

ryan-chenkie

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

Developer

Ryan Chenkie

Learn about Angular 2's new Dependency Injection system and how to use models to organize your app.

---

**TL;DR:** Domain models are important for defining and enforcing business logic in applications and are especially relevant as apps become larger and more people work on them. In this article, we show how this can be done in an Angular 2 app by moving logic out of the component and into a model. We also cover how to inject model classes using Angular 2's new Dependency Injection system. Check out the [repo](https://github.com/auth0/angular2-models-di) for the article to see the code.

This is the second part of our Angular 2 series. You can also check out the first part about [Angular 2 pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/).

---

> Auth0's Angular 2 series brings you tutorials on how to implement the latest features from the framework using the most recent Alpha release at the time of writing.

As applications grow in size, it becomes increasingly important that they be well organized with a solid structure in place. This is especially critical as increasing numbers of developers are added to the team. Application architecture should also strongly focus on the business rules that govern the application and protect sensitive methods from being exposed where they shouldn't be.

<include src="TweetQuote" quoteText="As applications grow in size, it becomes important that they be well organized with a solid structure in place"/>

At the same time, it is important that we keep our applications DRY and maintainable by moving logic out of components themselves and into separate classes that can be called upon. A modular approach such as this makes our app's business logic reusable.  

One way we can achieve this type of structure in Angular 2 applications is by using models to organize our business logic. Whereas the term "model" in Angular has typically been used to refer to the View-Model, what we're discussing here is the domain model-or the set of rules and business logic that an application implements for it to adhere to the organization's needs.

The term "domain model" is, of course, a generic one. Domain models are relevant in any kind of application. In this tutorial, we will see how we can abstract business logic to a model in an Angular 2 app and use the new **Dependency Injection (DI)** system to call upon these models. We will also explore the DI system's features and various ways it can be used.

## Getting Started with an Angular 2 app

We'll be writing our app in TypeScript, but everything will work just fine in ES6. If you'd like an Angular 2 starter app in ES6, checkout [Pawel Kozlowski's](https://twitter.com/pkozlowski_os) [ng2-play](https://github.com/pkozlowski-opensource/ng2-play/) repo.

Our sample app will take a user's details as input and use a model to handle those values. Let's start with a simple component called `UsersAppComponent`.

```js
// app.ts

/// <reference path="typings/_custom.d.ts" />

import {Component, View, bootstrap, bind, FORM_DIRECTIVES} from 'angular2/angular2';
import {Inject} from 'angular2/di';

@Component({
  selector: 'users'
})
@View({
  // Form directives to be used in the template
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  constructor() {}

}

bootstrap(UsersAppComponent);
```
Our template has some simple inputs for the user to provide their information, including checkboxes for them to select which programming languages they know.

```html
  

  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    
    <input type="text" placeholder="Enter your name" [(ng-model)]="user.name">
    <input type="text" placeholder="Enter your email" [(ng-model)]="user.email">
    <h3>Languages</h3>
    <input type="checkbox" [(ng-model)]="user.javascript">JavaScript
    <input type="checkbox" [(ng-model)]="user.ruby">Ruby
    <input type="checkbox" [(ng-model)]="user.php">PHP
    <button>Submit</button>
  </form>
```

## Handling User Data

For our app, we'll want to take the user's input to see how it can be handled with a model. For simplicity, we'll just log the info to the console in these examples, but you would typically be doing HTTP requests to send the user data off to a server to be persisted.

We could set up a simple `User` class that acts as a model for our data and have some additional methods in our `UsersAppComponent` that act upon the form data. We can do this right within our component, but as will become evident later, there are some drawbacks to this. Let's see what it would look like for now. The class arrangement will be:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/6o3tJOtNbC96nlsVPqjeLs/a54fc2b4d2955d66f1b84410801b03d6/classes-at-start)

```js
// app.ts

...

class User {
  name: string;
  email: string;
  rating: number;
}

@Component({
  selector: 'users'
})
@View({
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  // We instantiate the user class.
  user = new User();

  submit(userInfo) {
    // HTTP request would go here
    console.log(
      this.user.name,
      this.user.email,
      this.calculateRating(this.user)
    );
  }

  // Method to calculate the user's points
  calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }
}

...
```
We have two-way data binding set up on our form inputs, and they are bound to the instance of our `User` model. The `submit` method in our component's constructor logs the all the data to the console, including a calculation for the user's rating that it runs with the `calculateRating` method. How the heck did PHP get to be worth 50 points? I guess we'll never know.

## Improving the Model

While this approach works sufficiently well when an application is small, the way we have set things up does have a few drawbacks:

1. The `User` class isn't enforcing which values should be present or not. This can have implications if some operation downstream expects certain values to always be present.
2. The model doesn't have methods of its own to handle the calculation of the user's rating or the submission of the data. What if we wanted to have this same functionality in another of our app's components? We would need to duplicate the code in those other components.
3. While `calculateRating` is trivial in this example, what if we had some important and sensitive method with business logic that is meant only for specific circumstances? We need a way to be certain that such methods can't be used in places they're not supposed to be.
4. We currently have no ability to potentially share models with a JavaScript backend.

Let's see how we can tackle some of these issues. We'll start by moving the model to its own file. We'll eventually want to end up with classes that look more like this:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/2AZ4VJnqch6kcfIL6DlYlv/6fc64e402d51f1a5e9c12975324c0ac3/classes-at-end)


```js
// models/user.ts

export class User {
  name: string;
  email: string;
  rating: number;

  constructor(userInfo:any) {
    this.name = userInfo.name;
    this.email = userInfo.email;
    this.rating = this.calculateRating(userInfo);
  }

  private calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }

  save() {
    // HTTP request would go here
    console.log(this.name, this.email, this.rating);
  }
}
```

We're now using a constructor in our `User` method, which will set the values for `name`, `email`, and `rating` when the class is instantiated. We've got our `calculateRating` method in our class now, along with a `save` method to take care of making an HTTP request to save the data.

In our template, let's switch from using `ng-model` for two-way data binding to `ng-control` to get the form values when the form is submitted.

```html
  
  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    <input type="text" placeholder="Enter your name" ng-control="name">
    <input type="text" placeholder="Enter your email" ng-control="email">
    <input type="checkbox" ng-control="javascript">JavaScript
    <input type="checkbox" ng-control="ruby">Ruby
    <input type="checkbox" ng-control="php">PHP
    <button>Submit</button>
  </form>
```

We can now modify the `UsersAppComponent` to instantiate and save a new instance of the model when the form is submitted.

```js
// app.ts

...

import {User} from 'models/user';

...

class UsersAppComponent {

  submit(userInfo) {

    // Instantiate and save when the form is submitted
    this.user = new User(userInfo);
    this.user.save();

  }
}

...

```

The model and the methods that it relies on are now in the same spot and can be used in other parts of the application as well. In the model, we specified that we want `calculateRating` to be `private`, but as it stands, we would still be able to gain access to it from outside the `User` model. This is part of [TypeScript's design](http://typescript.codeplex.com/discussions/451129), but we can put a workaround in if we really wanted to protect `calculateRating`. Although it might not work as an architectural approach in every situation, we could define `calculateRating` as a function within the class constructor, which would prevent it from being accessed elsewhere. The downside here is that the function is not available to other methods within the class.

```js
// models/user.ts

...

constructor(userInfo:any) {

  this.name = userInfo.name;
  this.email = userInfo.email;
  this.rating = calculateRating(userInfo);

  // Function is only available inside the constructor
  // when the logic really needs to be protected.
  function calculateRating(userInfo) {...}
}

...
```

## Moving to Factories

We've seen how we can instantiate a new model and access methods on it, but what if we wanted to take the factory approach? In this approach, instead of instantiating the model directly in our components, we would call a method like `create` on the factory. As applications grow and classes become increasingly complex, this can have certain advantages, especially for maintainability. For example, if we wanted to change the name of a class that gets instantiated, the factory approach allows us to make a change solely to the factory itself and not all the instantiation points around the app.

This is also where Angular 2's Dependency Injection comes in, as we'll need to inject the factory to make use of it.

```js
// models/userFactory.ts

import {User} from './user';

export class UserFactory {

  // Uses the User model to create a new User
  create(userInfo:any) {
    return new User(userInfo);
  }

}
```

We'll need to inject the `UserFactory` into our component's constructor. Angular 2 comes with an `@Inject` decorator, which is used to attach metadata to the component. We also need to include `UserFactory` in an array when the app is bootstrapped so that it is included as a binding.

```js
// app.ts

...

import {UserFactory} from 'models/userFactory';

...

class UsersAppComponent {
  userName: string;
  userRating: number;
  rating: number;

  // We inject the UserFactory
  constructor(@Inject(UserFactory) UserFactory) {  
    this.UserFactory = UserFactory;
  }

  ...
}

// We bind the UserFactory when the component is bootstrapped
bootstrap(UsersAppComponent, [UserFactory]);

```

With `this.UserFactory` pointing to the `UserFactory`, we can now make use of its methods. Let's adjust the `submit` method to use the factory.

```js
// app.ts

...

submit(userInfo) {
  this.user = this.UserFactory.create(userInfo);
  this.user.save();
}

...


```

Now when the user submits the form, `create` and `save` are called with the form data.

We can also use the model approach to get the data for the user that just submitted the form. For example, we could add a `get` method to the `User` class that returns (or in this case logs to the console) the user's data.

```js
// models/user.ts

...

get() {
  console.log(this.name, this.email, this.rating);
}

...
```

Then within the component we can create a `getUser` method to retrieve it.

```js
// app.ts
...

getUser() {
  this.user.get();
}

...
```

## More on Dependency Injection

We used the `@Inject` decorator to bring in `UserFactory` above; however, TypeScript also allows us to use type annotations, which means the constructor can be written as:

```js
// app.ts

...

constructor(UserFactory: UserFactory) {...}

...
```

The array syntax we used to bind `UserFactory` to our component is the shorthand way of doing it. We can also explicitly state what we want to bind to, which gives us the option of binding to other classes. For example, we could bind `User` to `UserFactory` directly.

```js
// app.ts

...

// The UserFactory can be bound to another name, in this case, User
bootstrap(UsersAppComponent, [bind(User).toClass(UserFactory)]);

...
```

With this, `UserFactory` becomes `User` when used in our component.

## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [Single Sign On](https://auth0.com/docs/sso/single-sign-on), User Management, support for Social (Facebook, Github, Twitter, etc.), Enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/4PnRDegulvaccUIfNyaAtn/8342312355dc6af44a69c07c66f58be7/pub_w_1219_amp_h_559" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

It's important that thought be given to how applications are architected so that they are easier to maintain and can be collaborated on by more developers as team sizes grow. It's also important to protect business logic and keep sensitive methods from being accessed outside the class to which they belong. These effects can be achieved by moving logic into models.

Angular 2 gives us a new Dependency Injection system that allows us to inject classes into our components easily. We had a brief look at how the new DI system works, but for a more thorough overview, we recommend you check out [Pascal Precht](https://twitter.com/PascalPrecht)'s post on [Dependency Injection in Angular 2](http://blog.thoughtram.io/angular/2015/05/18/dependency-injection-in-angular-2.html).

"dom"