Shreya Gupta

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

Calah Vargas

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

Associate Manager, PLG

Before you start working with AI developer tools, understand what it could mean for you, your product, and your customers.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Note:</strong><br> 
  This blog post is based on interviews conducted with startup founders, engineering managers, data scientists, and risk analysts in the Artificial Intelligence and Machine Learning space.<br> 
</div>

Evaluating tools that can help optimize your development processes? Maybe you’re entirely building alongside [Devin, the first AI software engineer](https://www.cognition-labs.com/introducing-devin) to get your app to market faster, generating code snippets for your React app with [V0.dev](https://vercel.com/blog/announcing-v0-generative-ui), or using [GitHub CoPilot](https://thehackernews.com/2024/03/github-launches-ai-powered-autofix-tool.html) to help patch your website’s security flaws.

While productivity and efficiency are hallmarks of development success, security and privacy are just as paramount to protect your product and maintain customer trust. According to [Snyk’s 2023 AI Code Security report](https://snyk.io/reports/ai-code-security/), **80% of developers are bypassing security policies to use AI**.

But modern-day [Generative AI](https://news.mit.edu/2023/explained-generative-ai-1109) tools don’t typically have the built-in capability to determine whether the data it is exposed to is sensitive. It’s completely up to the user to take precautions and set up the proper protocols when choosing to use one of these tools. Let’s explore the potential risks of using AI tools in the dev process and what questions you could ask yourself to help make more informed decisions – for you, your product, and your customers.

## Productivity vs. Risk

According to Snyk’s blog, [How to Embed Security in AI-assisted software development](https://snyk.io/blog/snyk-and-atlassian-embed-security-ai-assisted-software-development/), “Code generation, using generative AI… is the area that stands to offer the greatest productivity benefits — **and the highest potential for introducing risk**.“

AI tools can help accelerate the process of taking an idea and building an MVP with limited resources. Although engineering productivity cannot be tracked by a single metric for all, it’s easy to see how these tools are already helping developers reduce time spent in generating code and improving the quality of code.

Like with all third-party tools, to strike the perfect balance between productivity and risk, it’s important to recognize ways in which these tools can hurt your product and customer security, now and in the future. In many situations, risk cannot be quantified, but companies can have an increased or decreased risk factor (risk tolerance) depending on:

* Industry
* Product type and use case
* Company stage

For example, risk tolerance can be higher for startups in growth mode, especially in industries outside of security.

## Risk Prevention Strategies

Let’s explore the most common risks associated with AI tools and mitigation strategies outlined by some engineers. 

Nonprofit OWASP (The Open Worldwide Application Security Project) documented a [list of potential security risks](https://owasp.org/www-project-top-10-for-large-language-model-applications/) when deploying and managing Large Language Models (LLMs) – some examples include:

* Sensitive Information Disclosure (LLM06) - LLMs can inadvertently disclose sensitive, proprietary, or confidential information leading to privacy breaches, intellectual property theft, and unauthorized access
* Prompt Injection (LLM01) - Attackers can manipulate LLMs through crafted inputs, causing the LLMs to execute the attacker’s intentions
* Overreliance (LLM09) - Systems or people overly dependent on LLMs without oversight may face misinformation, miscommunication, legal issues, and security vulnerabilities due to incorrect or inappropriate content generated by LLMs

When adding these tools to your tech stack, do these questions come to mind?

* How are you deciding which tools to use to increase your efficiency and productivity? 
* Do you have an internal vetting process for third-party vendors? How are you updating this for AI tools?
* Will you be prompting the AI tools with customer data and PII or proprietary restricted information? Are you in line with your applicable regulatory compliance frameworks? (GDPR, etc.)
* Does this tool abide by your corporate guidance?
* Do you have customer permission to use their data in this way?
* How could these tools impact you?
* What risks will you, your product, and your customers face?
* What guidance or guardrails does the tool have to protect your data as a user? Two popular types of AI developer tools are those for engineering productivity and those for general use, and the available configurations may vary.

We interviewed a few engineers (anonymously) about what they’re doing to minimize the risks associated with AI developer tools. Here’s a breakdown of some of the most common concerns and questions engineers are asking to reduce any harmful and inadvertent impact while coding with Gen AI tools.

* PI and copyright concerns
    * Once one of these tools generates code, who is the owner?
    * What happens if the tool is suggesting the same code to another customer, maybe even a competitor?
    * If you use AI tools in order to create a customer-facing chatbot, and a customer includes PII in their prompt – who is in charge of monitoring and removing this data and ensuring it isn’t being used to re-train models?
* Overreliance
    * Generating a few lines of code vs a few files of code – how familiar are you with the code in your product, and how much do you trust it?
    * Are you aware of the potential risk of [AI hallucinations](https://www.ibm.com/topics/ai-hallucinations) and how are you reducing it?
        * AI hallucinations are outputs from models that are nonsensical or inaccurate. For example:
            Question: where can I find the help center?
            Context: you’re looking for a website like [domain].com/help or support.[domain].com
            AI answer: the help center is located on the ground floor of this building.
* How are you updating your code and content review processes to deal with Gen AI?
* Data Exposure
    * Can you make sure your own data won't be used to answer prompts for competitors or malicious actors?
    * What are practical and technical strategies you can take to prevent data exposure?
    * Do you have strict policies and training for engineers when they are using these tools, or are you exploring third-party tools that tackle data leak prevention?

There’s no specific path to being completely secure from the risk of AI tools today, but there are many different strategies you can take to build strong guardrails to protect code and mitigate risk. Ensuring restrictions are very specific when engineers are using AI tools like Devin and code review is a must.

## AI Developer Tools Now and Tomorrow

AI tools for developer productivity are becoming increasingly popular. Further down the line, a startup founder might be able to ideate, possibly write [pseudocode](https://builtin.com/data-science/pseudocode), and use these tools to bring their idea to life. They might be able to start testing in a matter of minutes, not months.

If you’re an early-stage company, you might be eager to get started and may not have as much internal guidance as a large corporation. We hope this blog helps you start to outline the potential risks and considerations when evaluating AI tools for developer productivity. 

[Auth0 for Startups](https://auth0.com/startups) is empowering early-stage startups – tell us what we can do to best support you and your team!

_These materials and any recommendations within are not legal, privacy, security, compliance, or business advice. These materials are intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments or all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials. Information regarding Okta's contractual assurances to its customers can be found at [okta.com/agreements](http://okta.com/agreements)._

Security Considerations in the Time of AI Engineering

monica-bajaj

Monica Bajaj is the Vice President of Engineering at Okta, where she leads the Developer Experience portfolio for Customer Identity Cloud ( CIAM) Product unit. She is responsible for the development and innovation efforts for building a frictionless developer experience for our developers, customers, and partners.  Before joining Okta she held senior engineering leadership positions at Workday, Network Appliance, and UKG. Outside work, she loves spending time with boy scouts, hiking, painting, and supporting the cause of mentorship and uplifting women and young girls.

VP of Engineering, Customer Identity Cloud, Okta

Monica Bajaj

Elevating, overcoming adversity, connecting, and inspiring other women through a month-long series of events

![A show of solidarity amongst Women in Engineering during Okta Vice President Engineering - Developer Experience Monica Bajaj’s[ #Iamremarkable](https://iamremarkable.withgoogle.com/) session at the Auth0 product unit offsite in Cancun, Mexico during Women’s History Month 2023.](https://images.ctfassets.net/23aumh6u8s0i/2AbKDnju5aOGvc2JF5QR7b/369b8c78c418fdacf53811968b7ca344/Women_in_Engineering_01.jpg)

During Women's History Month at Okta, we focused on action over reflection. We wanted to commemorate the trailblazers who came before us, encourage those leading today, and make plans that will inspire and improve the lives of women in the future. We planned a month-long series of events with a different theme each week to bring all of us together on this journey. Our themes were _Elevate, Adversity, Connect, and Inspire._

* **Week 1: Elevate:** We focused on bringing visibility to the contributions we all make each day. We encouraged everyone to make a specific commitment to elevating themselves or other women, whether it was volunteering to mentor in RISE (Okta’s internal mentorship program), requesting a stretch assignment, speaking up, or bringing their own chair to the table. (For more on what I mean by “elevate,” please check out [this](https://www.linkedin.com/pulse/magical-monica-bajaj) LinkedIn post.)
* **Week 2: Adversity:** We created a safe space for candid conversation and questions about the adversity our women leaders have faced in the past and the challenges we all face today via a panel discussion. We talked about specific ways to address and overcome these challenges while providing inspiration and encouragement to one another to change those things we see as wrong today.
* **Week 3: Connect:** This year, we had the perfect opportunity to meet face-to-face for our first-ever in-person WinE (Women in Engineering) meeting. In addition to celebrating Women's History Month, we also had our first team-wide offsite since 2019. Over 400 Oktanauts attended, and it was a fantastic opportunity to build stronger relationships with colleagues while enjoying the beautiful beaches and soaking up the sun. Our theme was “ASSEMBLE”, which played an important role in fortifying our community, building deeper connections, and making our community of women stronger and more resilient than ever. During this week, I got to do an [IAmRemarkable](https://iamremarkable.withgoogle.com/) session with Women in Engineering focused on Women Empowerment and focus on our[ Word of Intent ](http://myintent.org/)
* **Inspire week:** Special guest speaker, [Jhillika Kumar](https://www.linkedin.com/in/jhillika/) founder and CEO of [Mentra](https://www.mentra.com/) and TEDx speaker for diversity and neuro-inclusion, joined us. Born from neurotypical and neurodivergent individuals looking to understand each other, Mentra uses AI to help recruiters bridge recruitment gaps. Jhillika shared her experiences and helped us reflect on how we can live our dreams, embrace the unknown, and shake things up.

![Jhillika Kumar](https://images.ctfassets.net/23aumh6u8s0i/6DgXY8QNyuwK5YcYMMAMPq/8ff2d33817e5a69702812eb348a1964b/Women_in_Engineering_02.jpg)

Reflecting back on March, my favorite part was getting to meet everyone in person at the offsite, thus creating a sense of community and fostering a shared mission. I had an opportunity to lead the [IAmRemarkable](https://iamremarkable.withgoogle.com/) session in person, where we focused on self-promotion, empowerment, and inclusion. The stories were powerful, some touched my heart, and I was able to meet so many remarkable people. We also came together to carve the [word of intention](http://myintent.org/), where we were able to reflect on our purpose and make it actionable. 

March was the kind of month that makes you pinch yourself to check if it was real. Together we got to energize & motivate, educate and align, and, most importantly, recognize and celebrate! And, of course, these connections and foundations are just a part of how we continue to build our incredible WinE community. I’m so excited for what's to come for the Customer Identity Cloud and feel proud that I get to work with so many amazing people every day who are true builders, collaborators, owners, and learners.

Curious about joining Okta or, in particular, Okta’s Customer Identity Cloud? [Please reach out](https://www.okta.com/company/careers/).


Taking Action During Women’s History Month: Elevating Women in Engineering

bernardo

Bernardo is an Engineering Manager at Auth0 focusing on improving its Performance and Resilience posture. He is a technical leader who is passionate about building quality software that is scalable and resilient to failure, so we can meet the rising expectations of our customers.

Engineering Manager (Performance and Resilience Testing)

Bernardo Guerreiro

How Auth0 uses Performance Engineering to balance infrastructure cost and performance.

Auth0 is providing a world-class service empowering the critical path of millions of logins around the world, so it’s important that we ensure our services are performing well while keeping our infrastructure efficient. The Performance and Resilience Testing team was established in late 2021, as Auth0 made a lot of improvements in its resilience posture. Together with Platform and Product teams, we work toward upholding that performance, reliability, and resilience posture that is such an important pillar of Auth0. 

During 2022, the [development of Auth0’s new Kubernetes-based platform ramped up](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/), which allows for a more repeatable and automated deployment of public and private cloud environments. Since then, our team began a natural partnership with the Platform teams and started working on defining the Private Cloud offerings for our customers. 

One of our key responsibilities has been to define performance tiers for private cloud customers based on different RPS (requests per second) thresholds - 100 RPS, 500 RPS, and 1500 RPS (with more to come). This initiative, called Tier Right-Sizing, is essential to ensuring Auth0 is able to provide our customers with offerings whose infrastructure costs are efficient for their needs, allowing our sales teams to more accurately sell to customers based on their capacity and performance needs. This blog post outlines the process we followed to define these tiers.

## Our Performance Testing Tooling

As you’ll find out as you read the blog post, in order to define these tiers, our team (and many other individuals at Auth0) ran countless performance tests of varying durations. One of the key things our team works on is the tooling and infrastructure for Performance Testing for the whole Engineering organization.

For the last three years, we’ve used [Artillery](https://www.artillery.io/) to run Performance Tests at Auth0, and it has allowed us to scale easily as usage of our framework organically grew within the company. This was important for a few reasons:

- Firstly, because in the last year and a half, the adoption of our framework went from a few people running Performance Tests at Auth0 to almost every engineering team;
- Secondly, because the scope of our tests also grew. For example, in December 2022, as part of the Tier Sizing for a larger customer, we ran 6,000+ RPS tests, which Artillery was able to easily handle thanks to leveraging AWS Fargate’s horizontal scaling.

We’ve also written our own CLI (a wrapper around the Artillery CLI called Airstrike), which has allowed us to standardize Artillery usage across the organization and cater to Auth0-specific use cases. Developers can now run authentication flows they’re familiar with by name, point it at an environment of their choice and simply type a target RPS, all without having to use an Artillery config. This abstracts even further the work of running a Load Test, which is especially helpful for teams that might not be product experts but still need to understand the performance impact of their work, such as platform teams. For example, anyone can run the `authorizationCode` scenario in a specific internal environment at any given RPS, for the duration they need, and with their desired load profile. All they need to do is run this fully configurable command:

```
airstrike run authorizationCodeNew --env tus1 --targetRPS 100 --targetDuration 3600 --loadProfile spike
```

Additionally, the latest Artillery offering, Artillery Dashboard, was also an important part of this Tier Right Sizing effort. Since Airstrike programmatically adds the relevant tags to tests by default, we were able to leverage the dashboard as a centralized location to view all our Performance Test reports for this effort, by filtering by tags to get the relevant test executions. Any load test report is available there for easy historical reference with all its results, logs, and graphs, and we found it easy to consume for stakeholders and developers alike.


![Auth0 Artillery Dashboard](https://images.ctfassets.net/23aumh6u8s0i/1ZpGlYTzV4cNJShIKMk9eq/f1d22eb93f77fe897cd2d75f91cda7bd/auth0-artillery-dashboard.png)


## Tier Right Sizing

My team followed a thorough four-step process which I’ll outline in this section. This process was followed for each of the tiers we’ve defined (5 private cloud tiers total). For all phases, a subset of core authentication scenarios was chosen by our Product team, which represents key product patterns our customers use. 

### Phase 1 - Exploratory Investigations

During this phase, the team worked together with Platform experts on experimenting with several infrastructure sizings and configurations, including:

- Number of resources needed for main services;
- Database Instance Sizes;
- Burstable Instance types;
- Kubernetes Nodes Instance Sizes;
- Kubernetes resource allocation;
- etc.

Since there were a lot of permutations to try, each experiment was only a 10-15 minute load test. This phase can almost be compared to “Exploratory Testing”. Apply an infrastructure change, run a load test, analyze results, rinse and repeat. It gave my team a good sense of the “gotchas” of the new platform, and served to develop an instinct for what would work and what wouldn’t. 

Once the team had arrived at what they believed to be an optimal configuration, it was time to prove that.

### Phase 2 - 1-Hour Baseline Load

This phase was the main acceptance criteria given to us by Product. Once we reached a stable configuration in Phase 1, the intent was to prove that it could hold the Performance SLA for 1 Hour at the defined Max RPS for the tier, for each of the core scenarios (ran sequentially).

If it failed the SLA, it was then necessary to go back to Phase 1 with more experiments until the team narrowed down a working configuration again.

### Phase 3 - 6-Hour Synthetic Load 

The previous phase (1-Hour Baseline Load) gave us confidence in the performance of each individual scenario at peak load, but that’s not always a typical traffic pattern. Realizing this, we decided to borrow from a concept we have in our Staging environments we call “Synthetic Load”, which emulates production-like traffic by running multiple weighted scenarios at the same time. 

For this effort, we added to our existing core scenarios a few more scenarios that customers are likely to have in their environments (Management API, Extensibility, etc.), creating a 6-hour Synthetic Load test, with a total RPS of the Max RPS for the Tier. This gave us confidence that the Tier would perform under more normal production-like conditions, when a lot more services are being hit.

### Phase 4 - 72-Hour Soak Test

The final piece of due diligence was to ensure that we didn’t see a performance impact from any memory leaks, cron jobs, database background operations, etc. For that reason, after consulting with a few experts in the system, we decided to be safe and run long soak tests. These gave us confidence that we wouldn’t see a problem manifest itself over time.

This ended up being a crucial part of the process and actually revealed a few important performance improvements that had to be done in our platform.

### Rollout

After the new tier definitions were live, all new customers used the new tier definitions. However, in a few cases, we had customers already migrated to our new Private Cloud platform, but not yet in our new optimized tiers. In order to guarantee a seamless transition to the newly defined tiers, a dedicated Platform team worked on a release plan. 

All infrastructure changes were gradually rolled out to customers through our [automated release pipeline](https://auth0.com/blog/how-we-do-releases-in-auth0-s-new-private-platform/). Changes were broken down into small batches, and thanks to our automated testing and the soak time built into our release pipeline, Platform teams were able to monitor each change going in to ensure no issues had been introduced, therefore minimizing any risk during this transition. 

## Conclusion

Right Sizing infrastructure is a game of balancing infrastructure cost and performance. There is no right final answer, and while this effort has taken us quite a bit of time, it will likely never be fully done - we will continue to optimize and improve on this over time. In a few cases, we have also had to do this exercise for specific customers with more unique and large-scale use cases (adapting which scenarios were used), so we will be working on generalizing some of these customer patterns.

I want to leave a final note that we were very excited to support this effort on the road to providing a modern platform for our customers. On a personal note, I am incredibly proud of my team for their contributions to this project, from the work in the tooling that eventually supported this effort to the people who directly worked on the project. It’s exciting to take our new platform to higher limits and take on bigger and bigger customers!

Optimizing Cost and Performance of Auth0's Private Cloud

MatthewHughes

I'm a Liverpool-based technology writer with a passion for usability and security. When I'm not churning out copy, you'll find me walking my two dogs: Luna and Apollo

Business Content Writer

Matthew Hughes

There’s no patch for humanity, but that’s not a bad thing

Let’s face it. We all make mistakes. Even the most diligent, well-intentioned employee can inadvertently open the floodgates to an attack. Telecoms giant Verizon illustrated this earlier this year, when it published the 2021 edition of its Data Breach Investigations Report (DBIR).

The DBIR examined approximately 5,250 successful security breaches, gathering data about the methodologies used. It found 35 percent of attacks incorporated a social element. Of these, the vast majority (85%) used phishing tactics.

**In short:** you can deploy all the technological measures you want, but unless you address the human element, an attacker can defeat your defenses with a simple phone call or email.

Social engineering has always intrigued me. There’s something weirdly compelling about someone circumventing the defenses of a company with nothing but a winning smile and a confident tone, and industry raconteurs like Jenny “The People Hacker” Radcliffe and Kevin Mitnick have some incredible stories to share.

But there’s something else. Many of the tactics successfully employed by social engineers can be found throughout history, used in the fields of warfare, espionage, and criminality. Shadowy state actors targeting government departments can be found using the same playbook as Classical-era Greek military tacticians.

There’s a reason for this. Humans are social animals. We have certain inherent traits. We’re often willing to trust strangers, and we help those we don’t necessarily know. We live by a set of rules, both written and unwritten. These attributes allowed us to develop societies, permanent settlements, and eventually nation states. But they can also be exploited by malicious actors seeking to further a particular goal.

> Technologies and tactics change. Human nature is a constant.

This article will explore some of these historical parallels. We’ll take a journey through time that starts in the Roman city of Brundisium, circa 19 BCE, with detours through the swinging sixties, the latter years of the Vietnam War, and the early days of the Internet. We’ll put the tactics used by social engineers into context, and show why they’re so effective. And finally, we’ll learn how to defend against them.

## Our Unpatchable Human Zero-Days

Before we start our trip, it’s probably a good idea to talk about the human qualities commonly targeted by social engineers.

While researching this post, I sought out as many tales of real-world social engineering as I could find. I thumbed through books by Chris Hadnagy and Kevin Mitnick. I listened to conference talks from the likes of Paul Wilson and Jenny Radcliffe. I devoured entire episodes of The Darknet Diaries.

As I went through, I noted most attacks focused on certain human attributes. These included:

*   **Curiosity**  
    **Every great scientific and technological leap started with the words: “What if?” But you don’t need to be Einstein to have curiosity. We use trial-and-error and experimentation to make sense of our environment. Social engineers frequently exploit this when harvesting credentials or [deploying malware](https://darknetdiaries.com/episode/100/).
*   **Trust**  
    **Life’s easier (and nicer) when you assume everyone acts in good faith. And so, we take people at their word. If an unfamiliar voice calls and claims to be from your bank or phone company, you might instinctively believe them. Social engineers can — and often do — exploit this.
*   **The Desire to Help**  
    **Since we’re social animals, collaboration is inevitable. If we see someone in need of assistance, chances are we’ll offer it. When exploiting this, a social engineer might pretend to be a low-ranking employee in need of credentials, access, or documents. They’ll count on the target feeling pity for them.
*   **Fear**  
    **The “fear factor” frequently features in social engineering attacks. You’re probably familiar with phishing emails claiming your bank account has been hacked, or your social media profile will be deleted unless you click a link. This tactic pressurizes the target into making hasty decisions and dropping their skepticism.
*   **The Desire to Comply**  
    **Almost all organizations — both public and private sector — are hierarchical. There’s a pecking order, with some people at the top, and others at the bottom. We tend to listen to (and obey) those higher up in the echelons. Attackers can exploit this by masquerading as high-ranking employees and issuing edicts to junior employees.

Each of the historical examples listed in this article uses these innate attributes, often to devastating effect.

## From USB Sticks to Wooden Horses

The year is 2008. A threat actor, most likely working for a foreign state, had broken into the heart of the United States defense establishment. Showing remarkable skil, the attacker had successfully deployed a data-siphoning worm onto a Central Command (CENTCOM) computer. From there, it proliferated like a fungus, spreading undetected into other computers.

William J. Lynn III, an Obama-era Deputy Secretary of Defense, later described it as "[the most significant breach of U.S. military computers ever.](https://archive.defense.gov/home/features/2010/0410_cybersec/lynn-article1.aspx)" He wasn’t wrong. The worm took almost 14 months to eradicate, and it infected both classified and unclassified machines. It’s hard to quantify the damage it inflicted on the Department of Defense.

Adding insult to injury, the damage was arguably self-inflicted. The virus, later dubbed Agent.biz, was distributed on USB sticks dropped in the parking lot at an unnamed Middle East military base. A CENTCOM employee picked one up and plugged it into their laptop.

The Department of Defense never identified the employee responsible for the first infection. We’ll never know their motivations. Were they curious about the drive’s contents? Did they want to reunite the drive with its owner? Or did they just want to save the $20 on a new memory stick? It’s not clear.

In the end, it doesn’t matter. The damage was done. The Department of Defense was forced to spend critical resources identifying and wiping infected machines, as they eliminated the worm one computer at a time. And it forced the military to radically change their approach to computer security, ultimately leading to the creation of the United States Cyber Command.

Still, I can’t help but wonder what the ancient Roman poet Virgil would think of this tale. Two millennia prior, Virgil was spending his twilight years in the city of Brundisium (now Brindisi), where he worked on his opus, the epic poem Aeneid.

Aeneid described the Siege of Troy. This is perhaps the most famous battle that never actually took place — or, at least, in the way depicted. Pretty much everything below is apocryphal. Still, it’s a great story, so indulge me.

Here’s the TL;DR: Greece was at war with Troy. It wasn’t going well. Both sides were effectively at a stalemate. Troy had retreated behind the walls of its capital city, where it could hold out indefinitely. After an exhausting decades-long siege, the Greeks were eager to end the campaign. And so, their leader, Odysseus, conjured a devious ruse.

Greece would pretend to surrender. Their forces would retreat. By means of apology, they left a large wooden horse at the gates of the city, which the Trojans interpreted as a tribute to their greatness.

We all know what happened next. The Trojans hauled the horse into the city, unbeknownst to the shock force of Greek warriors lurking within its interior. As night fell, they crept out and unlocked the gates to the city. The rest of the Greek army surged forward, flooding in and bringing the war to its conclusion in a matter of hours.

Technologically, USB drives and wooden horses couldn’t be more different. But in both of the examples cited, they were used to inflict devastating losses to the target. More importantly, they were only effective because the victim implicitly trusted they wouldn’t be used to harm them. Trust can be a dangerous thing.

## Helpful Humans

In the 1990s, Kevin Mitnick was the ultimate cybercrime bogeyman. He won his notoriety by breaking into some of the most powerful technology and telecommunications companies in the world. His misadventures were front-page news and even inspired two feature-length movies (one documentary, another dramatic).

Now, Mitnick is a legitimate cybersecurity professional and author. Through talks, articles, and books, he warns about the risks posed by social engineering attacks, giving examples from his own criminal past.

Many of his tales describe interactions with relatively low-level employees at the target company. He would build a rapport with the worker and gather information, which he would later use to achieve his larger goals.

In one example, detailed in his book [Ghost in the Wires](https://www.amazon.com/Ghost-Wires-Adventures-Worlds-Wanted/dp/0316037729), Mitnick sought to access the phone records of a friend he suspected of working for the FBI. He repeatedly called the phone provider, each time building a rapport with the employee and teasing out details relating to the account. Once he gathered enough information, he convinced the provider to fax the target’s previous invoice, claiming he needed it to rebuild his phone book.

Mitnick was successful because the employees didn’t question whether he was the real account holder. They weren’t motivated by data security, but rather customer happiness. They simply weren’t suspicious. He would successfully re-use these tactics again and again, before the FBI brought his criminal career to an abrupt end in 1995.

Twenty-five years earlier, a group of Anti-Vietnam War activists used a similar approach when breaking into a Delaware draft office. The group had already penetrated several military offices, as they sought to frustrate the recruitment of new soldiers into the highly unpopular war. They were seasoned burglars.

This Delaware office, however, proved a challenge. It was protected by an advanced, heavy duty door. Their usual tools — crowbars and lock picks — were useless here. And so, they had to think outside the box.

During the daytime, the office’s door was unlocked. A member of the group crept in and left a note behind. It read: “Please don’t lock this door tonight.”

It was simple. Obvious, even. And it worked. The group later returned under the cover of darkness. They approached the door and twisted its handle. It opened with a satisfying click. They gathered the documents they came for and left. In 2014, after the statute of limitations expired, the group would tell their tale to veteran Washington Post journalist Betty Medsger.

No doubt, the draft office was staffed by seasoned military servicemen. They understood risk, and no doubt knew of the widespread opposition to the Vietnam war. And yet, this experience was overridden by their desire to be helpful, and to comply with the request of a colleague or superior. They trusted the note’s provenance, and didn’t think to consider that it may have been left by an adversary.

## Why Social Engineering Works

The term “social engineering” sounds deceptively modern. In reality, it could be used to describe the kind of subterfuge used by criminals and military leaders throughout history.

You can draw parallels between the approaches detailed in Chris Hadnagy’s book [Human Hacking](https://www.amazon.com/Human-Hacking-Friends-Influence-People/dp/0063001780), which focuses on their application in legitimate offensive security procedures, and those used by convicted fraudster Frank Abagnale, as described in his book [Catch Me If You Can](https://www.amazon.com/s?k=catch+me+if+you+can+book&gclid=Cj0KCQjwwNWKBhDAARIsAJ8HkhcNRSvRdVegZPvCiI176SCZvOnGn3rDQGLMGOoA039SYYck0AfzRFAaAtWEEALw_wcB&hvadid=409998390125&hvdev=c&hvlocphy=9033339&hvnetw=g&hvqmt=e&hvrand=1184131583828329460&hvtargid=kwd-421448854&hydadcr=24630_11410023&tag=googhydr-20&ref=pd_sl_7yubf00gv6_e). The basic concepts are the same, with the only real point of differentiation being how they’re used.

Complicating matters, it’s now possible to perform social engineering attacks at scale. Through phishing (as well as its evil siblings, Smishing, or SMS phishing, and Vishing, or phishing via voice), a bad actor can reach millions in a matter of moments.

In 2020, the FBI received 231,000 reports of phishing attacks — or double that previous year’s figure. The real figure is almost certainly significantly higher, with most attempts unreported to the bureau. It affects non-profit organizations, businesses, and individuals, albeit to varying levels, and the costs can measure in the millions.

Earlier this year, US authorities sentenced the ringleader of a Business Email Compromise (BEC) scam to ten years in prison. The man, Obinwanne Okeke, stole $11m from companies in the construction industry by issuing fake invoices with the funds directed to foreign bank accounts.

Looking further back, in May 2000, Filipino malware developer Onel De Guzman caused an estimated $5.5bn to $8.7bn in damages, after he released a self-propagating worm masquerading as a love letter. The ILOVEYOU worm sought to steal dial-up internet credentials, and inadvertently took down the mail services of the UK parliament, Microsoft, and the US Department of defense.

> Here’s the good news: You can take steps to mitigate the risk social engineering poses to your organization.

Technical measures, as recommended by the US Computer Emergency Response Team (US-CERT), include the use of multi-factor authentication (MFA), email filtering, and firewalls. It helps to stay abreast of recent developments, and the Anti-Phishing Working Group provides helpful information about new threat actors and trends.

Training also plays an important role. It’s possible your colleagues are unaware that social engineering exists. Teach them about the tactics used and the importance of verifying the identities and details of those they interact with, along with your organization’s phishing reporting procedures. If you don’t have one, make a point to create one, even if it’s something as simple as a dedicated inbox, where employees can forward suspicious communications.

Finally, creating a culture of transparency and collaboration is important. Your colleagues should feel able to report security issues without fear or judgment.

"Our innate human traits make us vulnerable to social engineering attacks, and always will. The best and most scalable defense is to create a strong security culture, both within organizations and across society at large. When we empower people to detect and respond to these attacks, we build a more secure Internet for all," said Annybell Villarroel, Security Awareness and Culture Manager. To find out how Auth0 can meet your organization’s identity needs, click here.

How Social Engineering Has (And Hasn’t) Evolved Over Time

shiven_ramji

Shiv is an experienced product executive and builder obsessed with creating beautiful products. He is the President of Customer Identity at Okta, managing a $1B ARR business and overseeing the company’s product, data, security, and technology strategy and execution. Before Auth0 and Okta, Shiv was the SVP of Product at DigitalOcean, leading DigitalOcean’s products, pricing, and partnerships. Additionally, Shiv has held product leadership positions at global brands, including Amazon, NBCUniversal, LiveIntent, and The Nielsen Company. Shiv was the recipient of the 2023 Top Global CPO Award by the Products That Count community. 

Beyond his current corporate focus, Shiv is deeply committed to fostering entrepreneurship and innovation, particularly in Africa. He is an active angel investor and startup advisor and also serves on the boards of [Products That Count](https://productsthatcount.com/) and [Aiven.io](http://Aiven.io).

President, Auth0

Shiven Ramji

Bhawna Singh joined Auth0 as SVP of Engineering. Why she plans to focus on mentoring innovation.

Relying on Ask.com for quick answers or researching your next role at Glassdoor? You’re likely leaning on innovations [Bhawna Singh](https://auth0.com/blog/bhawna-singh-joins-auth0-leadership-team-as-senior-vice-president-of-engineering) helped make possible. With over twenty years of helping companies through tech transformations, scaling challenges, and participating in multiple acquisitions, Bhawna brings an understanding of how to deliver growth that serves end users and develops talent on the way to building revenue.

That experience is coming to Auth0 at a critical moment. While we’re seeking to strongly align our product and engineering teams, we’re also working through our recent acquisition by Okta — and we want to do that while sustaining our growth trajectory.

We sat down with Bhawna to learn more about how she grows talent through innovation, what brought her to Auth0, and why she’ll be applying the power of diversity of thought to the global identity market.

### Why join Auth0? 

Three things intrigued me. 

First, you, Eugenio [Pace], Matias [Woloski], were upfront and transparent about challenges. More importantly, though, Auth0’s mission and roadmap was compelling. 

Second, I really enjoy the people interaction that comes from working with a global team. But Auth0’s engineering talent spread across many countries presents an interesting time zone challenge.

Third, the technological challenges presented with Auth0’s high growth. Auth0 needs to work across 21 deployment regions to securely and reliably support billions of logins a month while continuously calling the team and technology to meet growth demands. This is an area where I can help and learn at the same time. Bottom line? I see the high growth and complexity of challenges ahead as an opportunity to make a larger impact.

### Now that you’re here, what are your short-term goals?

In the short term, hiring is my top priority. Even before Okta’s acquisition, Auth0 had big hiring goals. I am currently partnering with multiple teams and leaders on our hiring and onboarding strategy. At Auth0, we are solving hard problems around authentication, security, scale, and a product that needs to be highly available, along with continuous innovation in the identity space. So making sure new engineers understand that when they come to Auth0, they’re going to get to solve hard problems with leadership support (which means mentorship, team building, and securing proper funding) and strong cross-org alignment, specifically with product and process teams.

### Longer-term?

Mid-term, I’m looking to build Auth0’s engineering vision and roadmap to align our technology investments and product innovation plans. This will also play into our longer-term Okta + Auth0 vision. As a team, we are constantly innovating and making big bets. It is important that we build external awareness of key initiatives (watch for more engineering-specific content) to help continue attracting top talent and satisfying evolving customer needs.

### If I’m a new or current engineer at Auth0, what kind of leadership can I expect from you?

Table stakes for me are genuine empathy. But if I am going to ask you to rally behind me, there are really four core qualities that I look for in leaders, whether I am looking in the mirror or at leadership across an org.

1. **High-accountability.** Everyone is going to make mistakes. I hold myself highly accountable for what happens in my org. This helps build team integrity, trust, and collective ethics. The point is never to be mistake-free but to make sure we take the time to learn from our mistakes.
2. **Listening-based communication.** For a lot of people, listening is passive. For me, active listening means checking that you’ve effectively communicated what needs to be communicated and making sure it was received correctly. Information and feedback need to flow both ways, which is also key to building a transparent organization.
3. **Planning long-term.** As we look at our organization and tech stack, we need to invest in our long-term vision and strategy along with making short-term bets and wins. Aligning engineering with our vision and long-term goals means investing in people, investing in our technology, and strengthening innovation. 
4. **Investing in leaders.** The mentors I wanted and needed weren’t right there at the start of my career. If I could go back and change something in my own career, it would be to mentor sooner. Investing in developing team leadership through mentoring, coaching, or providing access to additional training and contacts can make a huge difference in the amount of creativity and innovation that comes out of an org. But more importantly, it helps keep the entire industry growing and innovating. I ensure that I am coaching my leaders to grow, and together we are building an organization inspired by learning and problem-solving. I also make every effort in connecting with underrepresented groups regularly and evaluate how effectively I help them to achieve their goals. If you’re on my team and would appreciate mentorship, I will either mentor you directly or connect you with someone within my network.

### What did it take to break into executive roles? Especially if you’re a woman or underrepresented person in tech, what five steps should you take to break in?

1. **Say yes to stretch assignments.** Mentors or coaches are usually telling you what’s happening, but if an opportunity comes your way, it means someone has vouched for you. Of course, you need to evaluate whether or not this assignment is right for you at this point in your life, but if you can, say “yes”. 
2. **Seek mentors — and trust them to identify your gaps.** We all have self-doubts, but I sometimes see women calling out “gaps” that I don’t really see as their weakness. Finding a mentor who can confirm your true gaps and strengths is critical. Then it’s important to do that homework to actively address the things you need to do in order to reach that goal.
3. **Get comfortable with taking risks and failing.** As an executive, the situations that come your way usually do not have a playbook. Being comfortable with taking risks, failing, and learning from the experience is the only path forward.  
4. **Network.** Look for peers (in addition to mentors) that you can lean on and ask for best practices. This is easier for some than others. Here are concrete steps that work: 
* **Talk to your manager and express interest in mentorship.** Your manager can lean in and help and/or provide recommendations and intros to other mentors.
* **Reach out to your People/Human Resources partner for mentorship.** They can connect you with internal mentors, in addition to external opportunities.
* **Identify your goals.** Work on self-awareness. Avoid an open-ended discussion. Identify two to three areas you’d like to work on. This will make it easier for your network to help you take action that matters. 

### Our security team talks about relying on “diversity of thought” to help secure our product and ensure a stronger security culture that protects our customers and the internet. How does diverse thinking help fuel an effective engineering team?

Security is part of engineering, and the teams collaborate closely to identify solutions grounded in the [Secure by Design approach](https://auth0.com/blog/why-auth0-is-shifting-left-on-security/). Diverse backgrounds bring diverse thoughts with multiple perspectives to get us to the right solution for all our customers. Auth0 was not created for just one company in the US or one company in another country. Our customer space requires a large global setup. One perspective just won’t work.

**Tell me about why you joined [Neythri Futures Fund](https://www.linkedin.com/company/neythri-futures-fund/) (NFF) as a founding Limited Partner.** 

The core reason we all came together to found the NFF was to fuel diversity at the top. We focus specifically on funding companies founded by women and underrepresented groups because we weren’t seeing women investors in this space. If you want to fuel diversity, you have to fund it.

**What makes a good ally?** 

We all feel we should know the answer here, but this is an evolving area. I am a continual learner in this space, so this means making sure I am listening and aware that I am going to make mistakes. Not intentionally, of course, but coming from a place of being comfortable with learning and listening hopefully makes it easier for others to point out my mistakes so I can learn from them. Immediately trying to fix everything is not the answer. The constant learning can’t stop with me. I need to pass it on to my team, leadership, and my network. We need to share what we learn to build collective awareness in this area.

### After being through more than five acquisitions, what kind of leadership does it take to move companies through mergers and acquisitions towards success for both employees and customers?

* **Aligning mission and core values.** How does the acquiree fit in/influence the mission?
* **Bringing people along through communication.** An acquisition is change management at a grand scale. Being clear about challenges and opportunities, especially for growth acquisitions, helps people bring the collaborative vision into reality.
* **Put together a plan for how you will bring people together — and actively communicate that plan.**
* **Understand that this is a complex process.** Know that there are areas that might not work out, while there are people who thrive on complex challenges. Actively choose to let those people lead and bring in those who are looking to work collaboratively. Frankly, I’m excited to be able to help Okta and Auth0 at this time.

## Learn more about identity and opportunities at Auth0

* If you’d like to learn more about how Auth0 can help speed your product to market, reach [out to our team](https://auth0.com/contact-us).
* If you’re interested in helping us solve complex problems, you’ll find [current listings here](https://auth0.com/careers/).

Auth0 Welcomes Bhawna Singh to the Team

auziros:jeana-tahnk

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

Senior Director, Global Communications

Jeana Tahnk

Former SVP of Engineering and CTO at Glassdoor and Ask.com bolsters management team

**BELLEVUE, Wash. – Oct. 7, 2021 –** The [Auth0 Identity Platform](https://auth0.com/), a product unit within Okta (NASDAQ: OKTA), today announced that [Bhawna Singh](https://www.linkedin.com/in/bhawnasingh/) has joined the company as Senior Vice President (SVP) of Engineering. With more than two decades of engineering and technology leadership, Singh will be instrumental in continuing to build and lead Auth0’s talented team of engineers in transforming technology and increasing value to its growing customer base.

Prior to joining Auth0, Singh held senior engineering and technology roles, including SVP of Engineering and CTO at Glassdoor, where she was responsible for technological innovation overseeing the company’s websites and mobile platforms, in addition to its software engineering data platform and machine learning teams. Before Glassdoor, Singh held engineering leadership roles at Ask.com, Sybase, and AT&T. As SVP of Engineering, Singh will lead the high growth of Auth0’s solutions, strengthen trust and reliability for their global customer base, and continue to invest in engineering excellence. 

“The technological complexity of identity, innovation of the company’s solutions, and transparent and inclusive workplace culture immediately drew me to Auth0,” said Singh. “I’m excited to join a global team filled with experts that continuously innovate and all share one common vision — secure access for all.”

“Identity is one of the most strategic investments an organization will make today, and as a company deeply passionate about our customers and dedicated to continuous improvement, Bhawna will play a critical role in helping us shape the future of identity and enabling our customers to accelerate innovation,” said Shiv Ramji, Chief Product Officer at Auth0. “With deeply experienced leadership in engineering and technology, Bhawna is an invaluable addition to Auth0, and we are honored she is joining us.”

To learn more about Singh and Auth0’s engineering team, visit [Auth0’s blog](https://auth0.com/blog/auth0-welcomes-bhawna-singh-to-the-team).

<include src="asides/AboutAuth0" />

### Media Contacts:
Global Communications<br />
Auth0<br />
[press@auth0.com](mailto:press@auth0.com)<br />

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

### Investor Contact:
Investor Relations<br />
[investor@okta.com](mailto:investor@okta.com)

Bhawna Singh Joins Auth0 Leadership Team as Senior Vice President of Engineering

Introducing these two new programs to bring new and diverse talent to our organizations.



Like many other technology companies, we are kicking off 2021 plans with a focus on bringing new and diverse talent to our organizations. This is why today, I am excited to announce two new programs we are kicking off this summer at Auth0: **The Summer Internship Program** and the **Engineering Launch Program**.

At Auth0, we are a company of builders who come to work every day to solve complex problems for our customers so that they can focus on the business problems that matter to them. For our customers, authentication and authorization are vital to every application. Implementing these in the right way is a hard problem for them, and it's only getting worse.

Identity is the only technology that sits at the intersection of convenience, privacy, and security. For their consumers, it is the place to make (or break) a good impression. This is what fuels our mission at Auth0 &mdash; to secure the world's identities so that innovators can innovate.

Today, I am excited to share two new programs in our global product delivery organization to attract aspiring developers, designers, data engineers, and students to join us in our mission **to enable easy and secure access to any application**. We have purposefully designed both programs with the following in mind: 

**Mentorship**: Program participants will benefit from ongoing support from leadership, a dedicated mentor, and a buddy for the entire program. Every engineer should feel encouraged, developed, and supported. Our commitment to growing our team, especially through mentorship, means we value and prioritize these relationships as part of our culture. 

**Meaningful Projects**: Our interns and ELP (Engineering Launch Program) participants will own meaningful projects and contribute to our roadmap. Their assignments will offer challenging and hands-on opportunities to learn about our products while delivering real customer value.

**Continuous Learning**: These roles will collaborate across teams to solve technical and non-technical challenges, get a well-rounded view of our business, diversify their skills, and stay ahead of the curve with a specialized curriculum to propel their careers. 

**Development**: We will challenge the cohorts to meet their personal and professional goals &mdash; while having fun along the way. In addition to project work and mentorship, they will learn from key members of the team through our Speaker Series, Lunch & Learns, and Coffee Chats. 

**Remote Culture**: Born as a globally-distributed organization out of necessity, Auth0 has tried and tested strategies for making remote work successful. With over half of our workforce working fully remotely before COVID-19, we've worked hard to establish a strong remote-friendly culture. Our unique culture will teach young minds to thrive as they sharpen their ability to excel in asynchronous work environments. 

## Introducing the Summer Internship Program

We are introducing our very first **summer internship** program. The internship program runs over the summer and is geared towards undergraduates looking to gain experience, solve real problems, and develop technical and soft skills. **The program is fully remote and open to anyone in the US**. 

![Summer Internship Program](https://images.ctfassets.net/23aumh6u8s0i/5T6FWeGLZ9qAYH5HqyVXvV/961fef91b8f1290167c2d9665ba657d2/summer-internship-program)

The internship assignments will be project-based and supported by a manager and mentor to maximize hands-on learning. Our internship program is going to offer students a unique experience:

* **Hackathons**: We'll kick off onboarding week with a Hackathon and close out the program with a second Hackathon.

* **Speaker series**: Twice a month, there will be a speaker series featuring leaders across Auth0. These sessions will have an interactive Q&A so that our interns and leaders get to learn about each other.
 
* **Learning and impact**: Our projects will be appropriately challenging, allow for cross-team collaboration, learning opportunities, and will make a direct impact on our 2021 roadmap.

* **Coffee chats**: These are weekly virtual coffee meetings with fellow Auziros. Mentors will facilitate these connections so that our interns can get an inside look at the day-to-day work of different departments.

* **Personal Development**: Fridays will be reserved for personal development towards their goals.

* **Lunch & Learn**: 45-minute sessions with key members from across Auth0 for a crash course on all things Identity. 

* **Project demos**: The program will finish off with a demo where interns will showcase their projects and outcomes to the entire company.

We have plans to expand this program beyond the US, and those will be unveiled later this year.

**Anyone who is an undergraduate student in the United States can apply for one of our 2021 summer virtual internships by visiting the [Auth0 careers page](https://auth0.com/careers/positions?title=interns)**. We have open intern positions in a wide array of fields, such as Data Engineering, Design, Security, and Software Engineering. Each internship career post will help you learn more about the projects that we have identified as ideal for our first intern class. [Check them out!](https://auth0.com/careers/positions?title=interns)

## Introducing the Engineering Launch Program (ELP)

We are also excited to introduce the **Engineering Launch Program**. This program is tailored for **new graduates and Bootcamp graduates**. The program participants will begin their 15-month program with a 3-month Foundations course to prepare them for success.

The Foundations course is a multi-faceted training curriculum that will effectively prepare new engineers to begin contributing in their development roles and warmly introduce them to our Auth0 and Engineering culture.  

![Engineering Launch Program](https://images.ctfassets.net/23aumh6u8s0i/5ccBubNErwBcVQHglzdE6J/cfbcb37430b4e30edb46ecebf000344e/engineering-launch-program)

The ELP will likely begin remotely until it is safe to return to [our headquarters in Bellevue, WA](https://goo.gl/maps/RCbP44EDSXWuiNek6). 

Undergraduate students and Bootcamp graduates with the right to work in the US, who are graduating this Spring, are all invited to [**apply today as a New Grad Software Engineer**](https://auth0.com/careers/job/software-engineer-new-grad-remote-bellevue:dc8674e2-7e11-49de-8ad9-0055c2af6571) to our Engineering Launch Program.

We are excited to open our doors to the next generation of talent and look forward to expanding these opportunities to our global applicants in the future. 

Happy coding, and stay healthy!

Shiv.

<include src="asides/AboutAuth0" />


Auth0 Launches Virtual Summer Internships and Junior Engineer Program

Damian Schenkelman

Damian was one of Auth0's earliest employees. He loves building products for developers and taking things from 0 to 1.
<br><br>
He played key roles in implementing product features and growing the engineering organization in the early stages, and later on defining Auth0's architecture for scale and creating new products. Today he helps shape Auth0's long term strategy and leads Auth0Lab, a small and amazing team doing research and development of forward-looking products.
<br><br>
He spends his spare time with family, and friends, exercising, and catching up on all things NBA.

VP R&D (Auth0Lab)

Providing transparency about the hiring process at Auth0 and the rationale behind it.



![hiring-1-screener](https://images.ctfassets.net/23aumh6u8s0i/23YdhsVbGWDveGLdXakBm/83a18a17dfce81d986c90f366301fe8c/hiring-1)

In March 2016, I had recently become the Director of Engineering at Auth0, and we were growing A LOT. This meant we had to spend a lot of time hiring.

We thought it would help if we explained what our process looked like, so we decided to write "How We Hire Engineers," a blog post that explained our process in detail. It:

1. Provided applicants with more information about our process.

2. Increased the number of applicants.

3. Served as a good indicator of a candidate's interest. If someone was applying to work at Auth0 and had read the blog post, that was usually a positive sign.

Since then, we have grown even more. We are over 650 people in more than 30 countries, and many people who join Auth0 tell us the blog post was a great asset. An update has been long overdue, so here it is!

## What We Look For

Before diving into the specific **steps**, we want to share what we look for in candidates. In the early days, we'd hire mostly generalists, but as we have grown, we have started to hire specialists for specific roles. However, there is a set of traits that we look for in all candidates, regardless of team and seniority. 

Great candidates have these traits based on [our values](https://auth0.com/careers/culture), our remote culture, and Auth0's natural tendency to grow and change as a company:

![hiring-2-values](https://images.ctfassets.net/23aumh6u8s0i/3ydwAQ9fbSpdHN3efUJV94/5c0a82dc2258a59498fcdd307a0be851/hiring-2)
<p align="center"><i>Auth0 Values</i></p>

**High Agency**

Waiting for the ideal circumstances to make things happen is a "no-no". We continuously grow and evolve. [There are no "ideal circumstances"](https://twitter.com/shreyas/status/1276956836856393728). Great people cover the gap between where Auth0 is and where its processes are. They make things happen regardless of circumstances.

**Embrace Change**

We are a rapidly growing company. The 2019 challenges are very different from the 2020 ones and the ones we'll solve in 2021. Getting the right people in the right seats is very important, with reorgs every year common. We MUST hire people that not only "are OK with change" but "embrace change".

**Like Auth0**

Great candidates want to work at Auth0, not use technology X or solve very specific problem Y. They understand that priorities change and that learning and applying varied skills is a must to succeed.

**Fast Learner**

Because Auth0 is continuously growing, learning new skills fast is key. We look for candidates with a [growth mindset](https://hbr.org/2016/01/what-having-a-growth-mindset-actually-means) and can learn fast, take feedback, are self-aware, and (in the case of experienced candidates) have a career growth trajectory.

**Know How Computers Work**

We look for people that grok principles, not specific technologies. Even specialists should understand the concepts behind the technologies they know and be able to discuss other options in the space. This enables fast learning, good tradeoffs, and understanding the new.

**Great Communicators**

All teams in our engineering org have members across different countries. Having people that can effectively communicate (according to their seniority) is fundamental for us. This prevents misunderstandings and repetition, which helps avoid rework and being blocked.

**Team Players**

We want candidates who help their teammates out, serve as mentors, and are OK with doing the unglamorous work. Good candidates understand when it's necessary and when it contributes to the success of the team.

**Strong Sense of Ownership**

We want people who feel responsible for the team's success and the company and not just "their work". This is related to our "One Team, One Score" and "We Give a Shit" values. Ownership powers our use of the "You build it, you run it" model.

_Read on 👇 if you want to learn how we hire in a company that values those ☝️ traits._

![Start](https://images.ctfassets.net/23aumh6u8s0i/74X7F0qV8XChGLX88OhBzT/06c221dba16d79526c5994d8126b328a/hire-separator-b)

##Step 0: Apply

We list open job positions on the [Auth0 Engineering Jobs page](https://auth0.com/careers/positions?areas=Engineering). Candidates send a CV and optionally a cover letter or custom message. Either the hiring manager or a recruiter will review resumes. The question we ask is:

> _Does it seem like this person WANTS to work at Auth0?_

We'll check the application for a custom message/cover letter to see if it reflects an interest in the company and position. We also look at their resume and try to assess their relevant experience for the position.

<div class="alert alert-default"><strong>Tip:</strong> Candidates who send a specific, non-generic message to Auth0 and the role are more likely to get to the first interview and be hired.</div>

Each role has a set of associated time zones. Our engineering team is remote, and we try to make sure that members of a single team have at least 3 hours of overlap.

A candidate might be a good fit for a position they did not apply for. In that case, we will reach out to see if they are interested in that other position. 

<div class="alert alert-default"><strong>Tip:</strong> We have found that candidates who apply for three or more positions are very unlikely to get to an initial screener. It typically shows a lack of interest in a specific position, and most of the time, their messages are overly generic or non-existent.</div>

For less than 10% of candidates, if we think they are a "**strong yes**," we email them to set up an interview with the hiring manager. Otherwise, if we think a candidate could be a good fit, we move on to the Recruiter Screen.

## Step 1: Recruiter Screener

The screener is a Zoom conversation with someone from our recruiting team. The goal is for both the candidate to find out more about each other and us. This is not a technical interview, but mostly a high-level conversation about the candidate's experience, interest in Auth0 and the role, and expectations. We assess:

* Auth0 knowledge

* Remote work experience

* Recent experience, successes/challenges, fit for the role, etc.

* Authorization to work in the country the candidate resides

In this and all other conversations, we always make time for a candidate's questions.

<div class="alert alert-default"><strong>Tip: </strong> Ask questions! If you are looking to work at Auth0, it is only fair that you know what you are getting into :)</div>

## Step 2: The Interviews

There are three interview stages. Each one only takes place if the previous one went well.

1. **Hiring manager interview:** This can be a mix of technical, interpersonal skills, and behavioral questions. We often go through previous experience and assess whether the candidate's values and ours align.

2. **Technical interview(s)**: Either one or two technical interviews. Engineers from the team the candidate has applied to and engineers from other teams will participate as interviewers.

3. **Engineering leader interview**: A conversation with one of our Directors of Engineering to talk about the position, our values, direction, and culture.

Interviews in the first two stages involve a panel of two interviewers each. We want multiple Auziros to meet candidates and to give candidates the chance to meet multiple Auziros.

Over the years, we have kept our **"No Live Coding" policy**, which usually receives great feedback. We don't think a short live coding exercise gives us the right signals on the candidate's abilities. People get nervous, and it does not replicate real work conditions.

## Step 3: The Technical Exercises

This is a topic that gets revisited at Auth0 frequently. We are constantly asking ourselves how we can improve our process, make it more inclusive, and ensure that the length does not make us miss valuable candidates while also giving us a good understanding of the candidate's skills.

Over the years, we have done some experiments with exercise variants and other ways of assessing a candidate's ability to work on problems remotely. Still, we continue to prefer the current exercise format. We still believe this approach is the best one for us to use when hiring. We're trying to make sure that people will be successful at Auth0, rather than just assessing their engineering skills.

We conduct a number of exercises that are specific to the position and seniority. We aim for exercises to take 8-12 hours to complete, and we give candidates at most seven days to work on them. Each candidate approaches this differently and decides how to manage their schedule.

<div class="alert alert-default"><strong>Note: </strong> We are in the process of reviewing our exercise pool. The duration and time to work on them are likely to decrease in the near future.</div>

When the exercise starts, we:

1. Invite the candidates to a Slack channel with everyone involved in their hiring process.

2. Share the exercise and assign an exercise "go-to person": _This person is responsible for replying to the candidate and unblocking them, guiding them through the exercise, and work on defining scope, providing information about Auth0, etc._
 
3. Explain to candidates that they are free to ask questions and validate their thoughts on the channel.

<div class="alert alert-default"><strong>Tip: </strong> The more senior the position the candidate is applying for, the fewer guardrails the problem is likely to have, as we are looking to see how senior candidates arrive at ideas to solve open-ended problems.</div>

Everyone in the channel, especially the "go-to person," guides candidates by going deeper into the requirements or highlighting problems that might lie ahead. We do our best to adjust to each schedule, such as replying late at night and/or on weekends, as we know this requires time from both parties. It's a pretty interactive process!

![hiring-3-feedback](https://images.ctfassets.net/23aumh6u8s0i/5wCeoL8LiuE86e8OZdgCAB/cbe35e466380ce79ad9a1a01e062a46b/hiring-3)
<p align="center"><i>Anonymized exercise conversation</i></p>

<div class="alert alert-default"><strong>Tip: </strong> The skills we assess are coding, research ability, written communication, autonomy, expectation management, attention to detail, and customer orientation.</div>

## Step 4: Demo
After the candidate finishes the exercise, we set up a 1-hour [Zoom](https://zoom.us/). Candidates walk us through their design, explain how they arrived at it, and demo the working solution using any means they prefer.
 
During and after the demo, we will ask questions and exchange thoughts. Again, the goal is to simulate as much as possible the experience of doing a demo at Auth0 during an internal Demo Day or Sprint Review session.

![Finish](https://images.ctfassets.net/23aumh6u8s0i/4juVEtuqO61q8qEsefw6zi/6114861fdec2d4b4b3c325fbd41b5f07/hire-separator-a)

## Measuring

We strongly believe that measuring the application process allows us to improve how we do things. We use these metrics to estimate how long filling a position will take and how many candidates we need to attract to fill some roles.

These are the numbers for a recent search to find a Senior Engineer to work in an IAM (Identity and Access Management) team:

![hiring-4-aplication](https://images.ctfassets.net/23aumh6u8s0i/31cbyI61BD9VL0FjZfacSf/2e75531787ba5f7bd205144d60868ecd/hiring-4)
<p align="center"><i>Funnel for a Senior Engineer position</i></p>

## Wrapping Up
Since the initial blog post was written four years ago, a lot of things have changed, but many have remained the same. We have experimented with lots of alternatives, received feedback from candidates, experienced pain points, and learned valuable lessons that helped us improve our process.

As a company, we are always looking to experiment and improve. Our hiring process is just one of the many things that we apply that approach to.

I hope this blog post has been useful to you. If, after reading this, you agree with our values, the traits that we look for, and our way of working, apply to be part of our [engineering team](https://auth0.com/careers/positions?areas=Engineering). 

You should now have a good idea of what to expect.


How We Hire Engineers - Volume 2

jenny-obrien

I'm a former business journalist who's fascinated by the intersection of tech and business strategy — in particular how the right solution can transform an idea into reality. I specialize in ROI, data privacy, and identity.

Business Content Manager

Jenny O'Brien

Extreme situation provides a reminder to reinforce identity best practices



Late Wednesday afternoon, news broke that high-profile twitter accounts from politicians and tech celebrities including President Barack Obama, Democratic candidate Joe Biden, Tesla CEO Elon Musk, Amazon CEO Jeff Bezos, and Apple had been hacked. Fake posts rolled out from dozens of accounts successfully convincing some twitter followers to send BitCoin with the expectation of matching funds.

Twitter responded by locking down the impacted accounts and removing the fake tweets. For a while, Twitter [even suspended the ability to tweet or reset passwords](https://www.theverge.com/2020/7/15/21326372/twitter-hack-bitcoin-scam-new-tweets-shut-off-verified-accounts#:~:text=Twitter%20completely%20disabled%20the%20ability,tweet%20out%20a%20bitcoin%20scam.) for many accounts. 

In other words, they locked down identity.
![twitter-support-tweet](https://images.ctfassets.net/23aumh6u8s0i/618YIlHfCmK8hPopjM9CTy/e2faa0b42d1b9645606d65a0ce24ada8/twitter-support-tweet)

The [Twitter support](https://twitter.com/TwitterSupport) team set a great example for incident communications, providing regular and consistent updates on the situation. While Twitter worked to remedy the situation, those with the ability to tweet (and those who regained it later in the evening) started considering possibilities and suggesting remedies.

The precise details of what happened, why, and how will likely continue to come out over the next several weeks, but twitter now says that the attack likely occurred due to a “[coordinated attack of social engineering](https://nypost.com/2020/07/16/twitter-blames-coordinated-social-engineering-attack-for-hack/)” on twitter employees with some suggesting now that it might be an insider attack motivated by bribes or even a false flag attack targeting more sensitive information. Cryptoforhealth via an [Instagram post](https://www.bbc.com/news/technology-53425822) claimed responsibility saying it was a “charity grab” and noted that the scammed funds would find their way to “the right place.”

While it’s still early days, we noticed that when the Twitterverse regained the ability to communicate, speculation on the source of the problem centered on the precise place twitter secured first &mdash; identity.

## Worst-Case Scenario Mitigated by Twitter’s ‘Panic Button’

As more details emerged about the targeting of an internal system, Twitter’s ex-CISO [Michael Coates](https://twitter.com/questCNN/status/1283857299476488205) appeared on [CNN](https://twitter.com/questCNN/status/1283857299476488205) to explain the layers of controls that Twitter had put in place, including “logging, data science analysis, minimum privilege, all these things you would expect in these systems. 

This is the worst-case scenario for any company: the exploitation of an insider to abuse a privileged internal tool used to help customers. One of the things that is obvious is that Twitter had a plan, which is the key for any successful incident response. They had a “panic button” that could be used to lock their systems down. And they had a team that was able to provide high-quality communications with the outside world consistently.

## Take This Moment to Review Your Identity Best Practices

While it does look like Twitter did a lot of things right now seems like a good time to reinforce some identity best practices. Please remember that this Twitter hack was an extreme situation, but these are some basics you should have covered.

1. **Access control matters.** Think through who within your company really needs to have access to critical customer data. Do they need permanent access or only when they need to perform certain functions? How is this tracked? How can your revoke access?

    **Live the principle of least privilege on these sensitive systems.** Restrict access to only who is truly necessary and step-up the authentication for any sensitive actions. Then regularly audit who has access to make sure the list is never out-of-date.

2. **Implement notifications (ideally, both email and phone push notifications) for every critical operation in the account lifecycle (email change, password reset, turn off two-factor authentication, account linking).** Rather than picking and choosing, if it’s critical, it’s best just to protect it. 

3. **Use the same API for email change on both internal and public-facing tools.**  They got into the worker account and made changes. If they had gotten into the public-facing account, it would have triggered notifications. If you use the same API (same code, same workflows) for both, then email change would have triggered the notifications.


Twitter hacked: Impacts of Identity and Social Engineering



<div class="alert alert-success alert-icon">
 <i class="icon-budicon-500"></i>
 <strong>Hey there! We wrote a new and updated version of this blog post that you can find in here: <a href="https://auth0.com/blog/how-we-hire-engineers-volume-2/">How We Hire Engineers - Volume 2</a>.</strong>
</div>

## tl;dr
![hiring process](https://images.ctfassets.net/23aumh6u8s0i/6ApT1NXbLHkKaWGHS7Gowd/79923b7341f0de0f83803dda0802070e/hiring-process2)

## The Full Version
Hiring is a key aspect of helping Auth0 grow. We are doing great, there are lots of things we want to get done in the short term and building a team that can handle this growth is paramount for continuing success.

There are many blog posts explaining why [startups shouldn't handle hiring like big companies do](https://zachholman.com/posts/startup-interviewing-is-fucked/). And we totally agree with this: we want to invest time to take the decision of making a new person part of our team.

For this reason, we have a hiring process that requires a lot of involvement from both us and candidates.

![Hiring Engineers at Auth0](https://images.ctfassets.net/23aumh6u8s0i/5ckgOQZKiLUC4vzja2GQg5/a1f504a47a6a6e05c4195767b8b003ac/how-we-hire-1)

### In The Beginning
Usually, conversations start when we get an email at [jobs+engineer@auth0.com](mailto:jobs+engineer@auth0.com). This is a very early stage and we have no information other than a CV and the email's contents.
The first thing we look for is:
>Does it seem like the person WANTS to work at Auth0?

This is a very important point as we believe it is important to have teammates that are passionate about the job they are doing. One of the things we do at this stage is check:
>Do the email contents reflect an interest in the company and position or is this just a template that gets sent to a bunch of potential employers?

After that, we take a look at the CV to _try_ to assess relevant experience and think if the candidate could do the job. Whether we think **strong yes** or are in doubt, we will move to the next step.

## The Screener

The next thing to do is learn more about the candidate. To do this we send them a short screener -- an idea we got from [this intercom post](https://blog.intercom.io/how-we-hire-engineers-part-1/)-- with questions that look like this (they might vary a bit depending on the specific position):

1. What's your proudest professional achievement? It can be a personal project or something you did at work/school. Just a short paragraph is fine, but we’d love to know why you're proud of it.
2. Tell us about an article/blog post/GitHub repo you found recently, why you liked it, and why we should check it out.
3. Tell us about a feature of Auth0 you really like, and why.

We also ask them to put together a small [webtask](https://webtask.io/) hack, something that should take a couple of hours.

Although there are some people that think that investing time to answer this email is not worthwhile, more often we tend to get really interesting responses. These responses are useful to learn things about the candidate, such as:

* The kind of topics this person is interested in.
* The things they know and like about Auth0: we are a company with a lot of available content, so there's lots of room to share knowledge here.
* An initial impression at their coding skills.

>If we were in doubt about a candidate, this is a chance to impress us.

We also value creativity. For example, one candidate created a pair of webtasks that played tic-tac-toe against each other using different heuristics. Another candidate, who we hired, [created a service](https://github.com/radekk/webtask-mfa-monitor) to monitor the status of Multi-Factor Authentication settings among different services.

## The Interviews

Assuming that everything went well, I have a call with candidates. The goal is to:

* Go through past work experience
* Explain the position to the candidate and gauge their interest
* Understand what they like to do and which [team](https://auth0.com/careers/positions?areas=Engineering) would be a good fit for them
* Evaluate the technical experience (more on "how?" below)

Up next, we do another call with the engineering lead for the position (e.g. frontend, backend, native, etc.). This is to validate the technical experience and to see if they would like to work with the candidate.

### No Live Coding

We believe it is really hard to assess technical knowledge with a short live coding exercise. We have all been there before: [it is VERY easy to get nervous](http://www.hanselman.com/blog/HowDoYouDealWithAnxietyWhenLiveCodingInTechnicalInterviews.aspx), it's very hard to define a problem that is actually related to the job and solvable in a short amount of time, etc.

What we do is talk. We go over situations that we have faced at Auth0 and have discussions about their implementation. It doesn't require any specific tool knowledge, it is all very conceptual and the idea is to give candidates room to ask questions about what they don't understand and go over pros and cons of each possible solution.

We believe this has worked well so far. Being in an interview is enough to make people nervous even without requiring live coding. Most candidates have expressed relief when being explained that they are not going to have to do that. We actually try to state that at the beginning of the interview, as it seems to relax them.

We know that this way of evaluating knowledge is not perfect and are continuously improving based on feedback, but we need a way to try to determine if this person is someone we want to invest more time on for the technical exercise.

## The Technical Exercise

After the two interviews, we move on to the technical exercise. This consists of:

1. Setting up a slack channel with everyone involved in the hiring process. We invite candidates using [this slack bot](https://github.com/auth0/webtask-scripts/blob/master/slack/invite.js).
2. Providing the exercise (which varies depending on the specific position)
3. Explaining candidates that they are free to ask questions and validate their thoughts in the channel

We want the exercise to actually be related to what candidates will be doing on the job. Because of that, we use a task that either was in our backlog or still is.

It takes between 8 and 12 hours to complete, and we give ~7 days to do so. Each person approaches this differently and is in charge of managing their schedule.

What we do is guide them, by going deeper into the requirements or highlighting problems that might lie ahead. We do our best to adjust to each schedule, such as replying on late nights and weekends as we know this requires time from both parties. It is a pretty interactive process!

This is where we learn a lot about the candidate, and it's not only their coding skills. We also look at things like:

* Are they autonomous?
* Are they good at researching things they don't know?
* How do they manage expectations?
* Do they incorporate our feedback into their solution? How do they take it?
* Does the solution make life easier for customers or does it "just work"?
* Are they detail oriented?

## Demo

After the exercise is finished we setup a 1 hour call.

During the first half, a 30-minute demo is held to go over the solution's implementation. This is a good point to go over anything that wasn't previously covered in chat. During and after the demo we will ask questions and exchange thoughts. Again, the goal is to simulate as much as possible the day-to-day experience at Auth0.

![Hiring Engineers](https://images.ctfassets.net/23aumh6u8s0i/6af3LOPIcR1K3ZzSWXYYWv/67d345f2690d70d7f909fef9b4a44392/how-we-hire-2)

## Some Stats

We all know hiring is hard. We actually measure how hard it is. For example, for a particular job posting, out of 126 candidates we hired 5 of them. The following image shows a summary of the stages for that posting:

![Hiring process statistics](https://images.ctfassets.net/23aumh6u8s0i/65QP8qFMKXB7MtDrqC6uwV/fc21598b69ffa0f7f4c91461dadba875/posting-chart)

## Wrapping Up

This is what works for us now, but we know there's room for improvement. We continuously adjust the technical discussions and exercises based on feedback from candidates. In fact, one of the reasons for publishing this post is that some candidates wanted to know about our hiring process before they went through it.

<include src="TweetQuote" quoteText="We all know hiring is hard. At Auth0 we want to be transparent about our recruiting process."/>

At Auth0 we value transparency, and to practice what we preach we want to be transparent about our recruiting process. So if at any time you want to [be part of Auth0's engineering team](https://auth0.com/careers/positions?areas=Engineering), you now have an idea of what to expect. 😉


How We Hire Engineers

ankue_chauhan

I'm an interactive designer based in Vallauris, France. My aim is to work on great ideas with good people.

Product Designer

Ankur P Chauhan

We work, not only as designers or engineers but as peers in building something great together.


As designers working in software, we need to work hand-in-hand with the people who bring ideas to life. Yet, so often we tend to fall in the trap of placing artificial walls in front of these otherwise perfect opportunities to collaborate. I don’t think there is a one size fits all solution to bridging this gap but here’s my experience on approaching this at [Auth0](https://www.auth0.com/). <br /><br />
**Caveat:** At [Auth0](https://www.auth0.com/), designers are part of remote teams, with people working in various timezones scattered across the world. Read more about that [here](https://medium.com/auth0-design/designing-remotely-at-auth0-5d9fb8499e29). <br /><br />
![Image_hero](https://images.ctfassets.net/23aumh6u8s0i/73h3xvCkkdGmdPrG4vB4fC/8ffa19ee362681ab00fa34df661a7816/hero)
And as designers working on the product itself, we work in the form of triads. Or in lay terms — a tech lead, a product manager and a product designer. Most teams include an agile practitioner and/or an engineering manager for guidance. But the work-to-be-done is primarily shaped by the triad itself.<br /><br />

When I first started as a product designer, here at [Auth0](https://www.auth0.com/), many questions popped into my head. How does the product work and fit into our customers’ workflow? How will I provide the most benefit to the team and the triad? What do I care to invest time in learning, and how will that shape how I integrate into the team? And is the dashboard the most common way our customers interact with [Auth0](https://www.auth0.com/)?

![Image_1](https://images.ctfassets.net/23aumh6u8s0i/53pDOHpDtflqN9kbjFYHjN/51295037ae1ce7ffeec3f962016bcc5a/image_1)

## Solving the Problems of Working on a Developer-Friendly Product
It’s natural to gravitate to working with the product manager on the team, as that is a more natural order of things. But considering the technical nature of the product, it felt key to also work closely with the technical lead on my team. This was strategic to help me answer some of the more complex questions. How fast you bridge this gap will vary depending on how technical you are willing to get. But no matter what interests you as a designer, you can still gain from this type of collaboration.<br /><br />

This was a tricky path, since [Auth0](https://www.auth0.com/) at its core, is solving the **complex problem of identity**. And we’re focusing on the people that actually build software applications — the innovators. With this in mind, it can be difficult to break down everything you need to learn. Learning about identity, building for platforms, and [Auth0](https://www.auth0.com/) itself can quickly become overwhelming. And you might feel the need to get up to speed quickly to provide the team some benefit.<br /><br />

![Image_2](https://images.ctfassets.net/23aumh6u8s0i/5xJuRIzMCwyqPowbiSfJuG/b7b737923dbc6725e52b39283a821d14/image_2)

## Finding the Right Ways to Collaborate
So my first thoughts were: it would be nice to start chipping away at these little walls built between product and engineering. I started by having regular check-ins with the technical lead on my team. He had been working at [Auth0](https://www.auth0.com/) for some time in many different roles and teams, so it was a great learning experience.<br /><br />

_Quick aside: [Auth0](https://www.auth0.com/) helps to figure out what career path you want to move towards, isn’t that neat? It’s a combination of conversations about what direction you want to move in (whether in your direct field or not) and career-building activities._<br /><br />

**Coming back now —**<br /><br />

These initial check-ins helped bridge goals and get a shared alignment on them. They were also increasingly helpful to start building trust and empathy for the different roles. Empathy is obviously important to designers but it can be magical when used internally among teams. I followed this up by getting more involved in technical meetings and scheduling regular monthly check-ins with all the engineers on the team and joining stand-ups, among other, engineering-led ceremonies.<br /><br />

This is something that can be fruitful but doesn’t come naturally. As a designer, you need heads-down time to get your work done and devoting time for regular check-ins with engineers and joining technical, engineering-led meetings might seem like wasteful activity. However, it’s something necessary to help build context quickly. I learned that most of the engineers on the team cared deeply about the product, as well as, the experience of using it, all thanks to being mindful to take the time.<br /><br />

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

## Diving Deeper Into Bridging the Gaps
As mentioned earlier, unearthing this required a lot of effort and time on my part. It’s not something that is evident, especially, when you’re halfway across the world. The most important lesson I gained from these conversations is that it’s important to build relationships to learn from. For example— using the time with an engineer to discuss your ideas and them punching holes in it can be helpful, if you keep in mind that you’re working to the same eventual goal. This can help you work better by being held accountable for your role and being transparent when something doesn’t work. This is great for getting validation at every step of your process for building products too.<br /><br />

Expanding these sessions into more collaborative experiences was an easy next step. We would discuss a feature, the technical lead would write the proposal for it, while I would simultaneously put together some rough mockups. This step felt key to sharing a vision of the feature itself; you made a decision together and not in a silo. The shared responsibility among everyone makes this better. This allowed the entire team to become more involved in user journey activities. A few months down and we’re trying to do more product-focused work together and keep making decisions together. An engineer from the team is even interested in moving towards a product-focused role.<br /><br />

![Image_4](https://images.ctfassets.net/23aumh6u8s0i/4DJJoRrM3RzNGD7vN13wNl/dbd6adafae477b7ca32e10d9b6629b98/image_4)

## Speaking the Same Language so You Never Have to Hand off Designs
As a designer, you either learn development on the side or not at all. What’s great about this collaboration is that it fixes the gaps, wherever they are. By having engineers walk you through what the API design might look like or what the data model is, helps immensely. After all, that is a large part of the user experience that you, the designer, are responsible for. In any product, this way of thinking helps to make certain decisions about the experience and informs the interface. Are we querying to the database at some point? Maybe we need to show a loading state for the content because the frontend is already loaded. What if there’s a network error? How do we signal this to the user? All of these technical questions are great for designers to build a product that is able to answer them for the user.<br /><br />

What it also enables is a common language. As a designer, you get better at communicating with your peers in the terms they understand and vice-versa. This is extremely beneficial, as you can, have discussions earlier in the process and inform your design work by any constraints that are required. Partly because you now have the tools to understand the technical side of things and partly because you will have constraints defined earlier, rather than later during what is traditionally known as a design-developer handoff. The more you continue collaborating, the less you’ll need something like a design-developer handoff.<br /><br />

![Image_5](https://images.ctfassets.net/23aumh6u8s0i/ivVx0VUydPKQ3YDLZsUmM/cd8ff243a69f5ab65b7dec0302057eac/image_5)

## You Just Can’t Fix Everything…
We use a famous quote by Henry Ford at Auth0 but I’m going to refrain from using that one. I’ll use this one instead.

> # _“Failure is the opportunity to begin again more intelligently.”_ 
> # — Henry Ford

This entire process is slow, difficult and prone to errors because there is no tailored fit. I’ve had to invest time in setting up multiple video calls. Otherwise, it’s hard to get everyone’s individual perspective on the work. There is also a steep learning curve around the identity space and learning the technical arc of the product itself. Yet, the key has been to keep building a relationship with the members of the engineering team. Things get a lot smoother, even if they aren’t perfect. The dynamics of your team are constantly changing and this changes how you work with people. For this, I’d recommend reading a bit more about team dynamics and how hard that can be. I think transparency, communication, and feedback will still be topics for that.

### Key Takeaways
The few ways I’ve found to make this collaboration better:
1. Start conversations with engineers, they’ll be more than happy to help.
2. There’s a great deal of knowledge to go around, learn from it.
3. Join technical meetings and try to be more vocal with questions in these.
4. Start involving engineers in collaborative activities for product work, this helps bring in ideas.
5. Build things together, engineers bring the technical context and designers bind that into a simple journey.
6. Build relationships with these remote humans, you’ll cherish your time working wherever you are.
7. Don’t be afraid because things start getting technical, as designers, we have the ability to make things simpler to understand.
8. Be open when you don’t know things, this is the only way to get better.

## Conclusion
These key takeaways sum up the experience of working at Auth0 in a product team. We work, not only as designers or engineers but as peers in building something great together. Remote work can sometimes feel awkward because of the lack of real-world interaction. However, if designers take the leap to involve ourselves in parts outside of design, the outcome is definitely great. It’s less about passing the buck and having shared ownership of the product.<br /><br />

For me — I’ve come to learn so much, not only about Auth0 but about identity by crossing over this bridge. This path continues to be fruitful for learning and carving out further distinct areas of growth. Collaborating with engineers not only enables me, as a designer, to understand and work efficiently but also helps other designers bring these ideas to their respective teams. On the design team, we’ve had many great discussions and action items come from these design-engineering workflows. I hope this helps you get ideas for collaborating with your engineering counterparts!
And if you find yourself really wanting to join a company that believes in a shared roadmap for identity between design and engineering— Auth0 is looking for product designers. Find out more at our jobs page here.<br /><br />

Thanks for reading along!


Designing impactful products by collaborating with engineers.

pablo-casas

I am responsible for the creation of AI and machine learning models in different areas of Auth0, like Support, Marketing, and Anomaly Detection for Product. Learning and teaching about data is my passion! Recently, I published the open-source “Data Science Live Book”, which you can read at http://livebook.datascienceheroes.com. You can also find me teaching Data Science at Universidad Tecnológica Nacional de Argentina.

Sr. Data Scientist / AI

Pablo Casas

Learn how the Auth0 data team combines R and Python to leverage data engineering and machine learning solutions.



The Data team is responsible for crunching, reporting, and serving data. The team also does data integrations with other systems, creating machine learning, and deep learning models.

With this post, we intend to share our favorite tools, which are proven to run with thousands of millions of data. 
Scaling processes in real-world scenarios is a hot topic among new people coming to data.

## R or Python?

Well... both!

![R and Python logos](https://images.ctfassets.net/23aumh6u8s0i/32tvQ9ZJWzVodIJd3k6sMI/18dc59e9b71fda2d15edca0c83503cbd/r-python)

[R](https://www.r-project.org/about.html) is a GNU project, thought as a statistical data language originally developed at Bell Laboratories around 1996.

[Python](https://www.python.org/), developed in 1991 by Guido van Rossum, is a general-purpose language with a focus on code readability.

Both R and Python are highly extensible through packages.

We mainly use R for our data processes and ML projects, and Python to do the integrations and Deep Learning projects.

Our stack is R with [RStudio](https://rstudio.com), and Python 3 with [Jupyter](https://jupyter.org/) notebooks.

RStudio is an open-source and vast IDE capable of browsing data and objects created during the session, plots, debugging code, among many other options. It also provides an enterprise-ready solution.

Jupyter is also an open-source IDE aimed to interface Julia, Python, and R. Today's is widely used for data scientists to share their analysis. Recently Google creates "Colab", a Jupyter notebook environment capable of running in the google drive cloud.

## So is R Capable of Running on Production?

Yes. 

We run several heavy data preparations and predictive models every day, every hour, and every few minutes.

## How Do We Run R and Python Tasks on Production?

We use [Airflow](https://airflow.apache.org/) as an orchestrator, an open-source project created by Airbnb.

Airflow is an incredible and robust project which allows us to schedule processes, assign priorities, rules, detailed log, etc.

For development, we still use the form: `Rscript my_awesome_script.R`.

Airflow is a Python-based task scheduler that allows us to run chained processes, with many complex dependencies, monitoring the current state of all of them and firing alerts if anything goes wrong to Slack. This is ideal for running import jobs to populate the Data Warehouse with fresh data every day.

## Do We Have a Data Warehouse?

Yes, and it's huge! 

It's mounted on Amazon Redshift, a suitable option if scaling is a priority. Visit their [website](https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html) to learn more about it.

R connects directly to Amazon Redshift thanks to the [rauth0 package](https://github.com/auth0/rauth0), which uses the [redshiftTools](https://blog.datascienceheroes.com/redshifttools-v1-0-0-cran-release) package, developed by [Pablo Seibelt](https://auth0.com/blog/authors/pablo-seibelt/).

Generally, data is uploaded from R to Amazon Redshift using `redshiftTools`. This data can be either plain files or from data frames created during the R session.

We use Python to import and export unstructured data since R does not have useful libraries currently to handle it. 

We have experimented with JSON libraries in R but the result is much worse than using Python in this scenario. For example, using [RJSONIO](https://rdrr.io/cran/RJSONIO/man/fromJSON.html) the dataset is automatically transformed into an R Data Frame, with little control of how the transformation is done. This is only useful for very simple JSON data structures and is very difficult to manipulate in R, compared to Python where this is much easier and more natural.

<include src="TweetQuote" quoteText="Auth0 uses Python to import and export unstructured data."/>

### How do we deal with data preparation using R?

We have two scenarios, data preparation for data engineering, and data preparation for machine learning/AI. 

One of the biggest strengths of R is the [tidyverse](https://www.tidyverse.org/packages) package, which is a set of packages developed by lots of ninja developers, some of them working at RStudio Inc company. They provide a common API and a shared philosophy for working with data. We will cover an example in the next section.

The tidyverse, especially the [dplyr](https://dplyr.tidyverse.org) package, contains a set of functions that make the exploratory data analysis and data preparation quite comfortable.

For certain tasks in crunching data prep and visualization, we use the [funModeling](https://blog.datascienceheroes.com/exploratory-data-analysis-data-preparation-with-funmodeling/) package. It was the seed for an open-source book I published some time ago: [Data Science Live Book](http://livebook.datascienceheroes.com/). It contains some good practices we follow related to deploying models on production, dealing with missing data, handling outliers, and more.

<include src="TweetQuote" quoteText="One of the biggest strengths of R is the tidyverse package, which is a set of packages developed by lots of ninja developers."/>

## Does R Scale?

One of the key points of `dplyr` is it can be run on databases, thanks to another package with a pretty similar name: [dbplyr](https://dbplyr.tidyverse.org/). 

This way, we write R syntax (`dplyr`) and it is "automagically" converted to SQL syntax and it then runs on production.

There are some cases in which these conversions from R to SQL are not made automatically. For such cases, we are still able to do a mix of SQL syntax in R.

For example, following dplyr syntax:

```sql
flights %>%
  group_by(month, day) %>%
  summarise(delay = mean(dep_delay)) 
```

Generates:

```sql
SELECT `month`, `day`, AVG(`dep_delay`) AS `delay`
FROM `nycflights13::flights`
GROUP BY `month`, `day`
```

This way, `dbplyr` makes transparent for the R user working with objects in RAM or a foreign database.

Not many people know, but many key pieces of R are written in C++ (concretely, the [Rcpp](http://adv-r.had.co.nz/Rcpp.html) package).

### How do we share the results?

Mostly in [Tableau](https://www.tableau.com/). We have some integrations with [Salesforce](https://www.salesforce.com). 

In addition, we do have some reports deployed in [Shiny](https://shiny.rstudio.com). Especially the ones that need complex customer interaction.
Shiny allows custom reports to be built using simple R code without having to learn Javascript, Python or other frontend and backend languages. Through the use of a "reactive" interface, the user can input parameters that the Shiny application can use to react and redraw any reports. In contrast with tools like Tableau, Domo, PowerBI, etc. which are more "drag and drop", the programmatic nature of Shiny apps allow them to do almost anything the developer can conceive in their imagination, which might be more difficult or impossible in other tools.

For ad hoc reports (HTML), we use [R markdown](https://rmarkdown.rstudio.com) which shares some functionality with to jupyter notebooks. It allows a script to be created with an analysis that ends in a dashboard, PDF report, web-based reports, and also books!

## Machine Learning / AI

We use both R and Python. 

For Machine Learning projects, we use mainly the [`caret`](https://topepo.github.io/caret/index.html) package in R. It provides a high-level interface to many machine learning algorithms, as well as common tasks in data preparation, model evaluation, and hyper-tuning parameter.

For Deep Learning, we use Python, specifically the libraries [Keras](https://keras.io) with [TensorFlow](https://www.tensorflow.org/) as the backend. Keras is an API to build with just a bunch of lines of code, many of the most complex neural networks. It can easily scale by training them on the cloud, in services like AWS.

Nowadays we are also doing some experiments with the [fastai](https://www.fast.ai/) library for NLP problems. 

## Summing Up!

The open-source languages are leading the data path. R and Python have strong communities, and there are free and top-notch resources to learn.

Here we wanted to share the not-so-common approach of using R for data engineering tasks, what are our favorite and Python libraries, with a focus on sharing the results, explaining some of the practices we do every day.

We think the most important stages in a data project are the data analysis and data preparation. Choosing the right approach can save a lot of time and make the project to scale.

We hope this post encourages you to try some of the suggested technologies and rock your data projects!

<include src="asides/AboutAuth0" />

---


How the Auth0 Data Team Uses R and Python

kapehe-jorgenson

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

R&D Content Engineer

Kapehe Jorgenson

Platform Engineer Dorrin Poorkay on the challenge of scaling and the benefits of calm leadership



Platform Engineer [Dorrin Poorkay](https://www.linkedin.com/in/dorrin-poorkay-94552b82/) came to [Auth0](https://auth0.com/) after working as an infrastructure engineer for a local startup facing rapid growth where she handled [Amazon Web Services (AWS)](https://aws.amazon.com/) infrastructure. She also maintained the cloud infrastructure (OpenStack) at the [University of Louisville](http://louisville.edu/), where she also earned her degree in computer science and engineering.

Sitting down with Dorrin was not your typical "let's meet in a conference room" because Auth0's a globally distributed company. We kept in touch via Slack, Google Docs, and Zoom. I learned more about her path to Auth0, what it’s really like to be a platform engineer, and her favorite programming language — all while being on the other side of the United States from each other.

![Photo of Dorrin Poorkay](https://images.ctfassets.net/23aumh6u8s0i/chaGa7c9KKM8i2ZOja0i2/6a6360c8eee3f36061e8a1c6cccb186e/dorrin-poorkay-2)

**On the daily life of a platform engineer at Auth0:**

Platform engineers design and build the underlying infrastructure for applications to run on. Given that we’re responsible for the foundation of our entire product, a lot goes on in a typical day of platform engineers.

Some days I'm on-call and responding to incidents — those days are chaotic, but fun! Other days I work on building new infrastructure, automating our current one, and making improvements.

I always start my day with coffee and aim to be productive right from the start. Over the years, I’ve found I’m most productive after my first cup of coffee and again late at night. I try to structure my day by scheduling meetings during my "downtime" (when I’m least productive) and snoozing Slack and my phone to minimize distractions.

During my on-call week, things are a bit different as I have to be alert and respond to pages quickly, but I adjust by planning for the interruption beforehand and setting expectations. When I am on-call, each day is unique. The flow of my day depends on what happens. Sometimes you wake up at 3:00 a.m. to a page. Most of the time our incidents are short but if incidents are long (say a few hours) then your teammates will fill in for you to get some rest and sleep. It balances out nicely. While most of our incidents do not mean “widespread outage”, we proactively monitor all of our systems and can be paged preemptively before our customers can experience issues.

Whether on-call or not, a light lunch and an hour of exercise are also included in my daily routine. I also find time to learn about topics that I am passionate about. For example, these days I spend most of my time programming in [Go](https://golang.org/) which I enjoy immensely.

<include src="TweetQuote" quoteText="On being a platform engineer at Auth0: Some days I'm on-call and responding to incidents - those days are chaotic, but fun! -Dorrin Poorkay"/>

**On moving up to the challenge of scaling and maintaining a service that can’t have any downtime:**

When I came to Auth0, I was really looking for a challenge.

I started my career with a few internships during college and a few weeks before finals I landed my first job at a local startup. It was extremely fast-paced and as chaotic as small startups can be. I thoroughly enjoyed it until it was time for me to move on to a more challenging job.

What attracted me to Auth0 was the engineering talent, specifically evident in the engineers I spoke to [during the Auth0 interview process](https://auth0.com/blog/how-we-hire-engineers/), the [Auth0 blog](https://auth0.com/blog/), and, of course, the [identity platform](https://auth0.com/docs/getting-started/overview) product, but the big attraction was the challenge of scaling and maintaining a service that can’t have any downtime.

Working at a startup at a much smaller scale had its own challenges but things like writing postmortems, doing root cause analysis, measuring SLAs of services were not part of my daily job. Auth0 has a unique challenge of "can't be down at all.". We serve billions of authentication requests and none of them can fail. Banks, airlines, news websites, or anyone using Auth0 expect a very high Service Level Agreement (SLA) because our service is critical to the success of theirs.

**On keeping up with rapid changes in the engineering field:**

Engineering changes quickly. I keep up by reading — lots and lots of reading. I try to read a few articles every day. The tech industry moves very quickly, you have to keep up. I also implement new technologies I’m curious about in my personal projects. Although when there is not a lot of time to do personal projects, reading is still the best substitute.

I get a lot of my exposure to the tech industry's ins and outs from [Hacker News](https://news.ycombinator.com/), [my twitter feed](https://twitter.com/fseekme) and different Slack workspaces. In terms of books, I've been reading [Advanced Programming in the UNIX Environment](https://www.amazon.com/Advanced-Programming-UNIX-Environment-3rd/dp/0321637739). It might seem like it's not necessarily knowledge in the world of cloud, containers and serverless but it's a great read that continues to be helpful in my day-to-day job.

<include src="TweetQuote" quoteText="The tech industry moves very quickly, you have to keep up. -Dorrin Poorkay, Platform Engineer for Auth0"/>

**On her favorite project for Auth0 (so far):**

We had [another record growth year in 2018](https://auth0.com/blog/auth0-announces-record-year/) and are on track to continue that rapid growth. That means we’re always looking at ways to scale our systems to meet customer needs while we improve our products and services. Our product and engineering teams are also continuing to expand — we have to develop more tooling and services around our platform and infrastructure to keep up with our growth. My favorite projects (so far) aim to solve many of these challenges with code by blending programming and infrastructure knowledge.

**On what it’s like to work remotely from Louisville, KY and its great tech community:**

Most people think of fried chicken and bourbon when they hear Kentucky. While it is true that Kentucky has great chicken and bourbon, it also has great coffee shops, micro-breweries, and co-working spaces. Those places are usually where you see remote workers hacking away at their laptops.

I was born and raised in a big city, so it took a while to adjust to life in Louisville. I’d describe it as a big city with a small city feel. We have a close-knit tech community which has its own Slack workspace. We also have a lot of tech meetups around town. So if you’re working remote and looking to socialize with other software engineers, there’s plenty to do here!

->![Louisville, Kentucky](https://images.ctfassets.net/23aumh6u8s0i/5X808xp71KOaN6J34cZ69b/f70ed2c326fbe15bb0532245e6c14adf/louisville-kentucky-2)<-

Check out two of our local [meetup](https://www.meetup.com/) groups:

* [Kubernetes and Cloud Native Computing Louisville](https://www.meetup.com/Kubernetes-and-Cloud-Native-Computing-Louisville/)
* [Louisville AWS User Group](https://www.meetup.com/Louisville-AWS-Users-Group/)

**On the importance of calm leadership:**

During my on-boarding, I joined an incident call (we collaborate via video chat on incidents to facilitate communication). My fellow colleagues were on the call, but I noticed our Chief Technology and Product Officer and co-founder, [Matias Woloski](https://auth0.com/blog/authors/matias-woloski/) was also on the call. Even though he was incident-commanding and aware of the urgency, he remained calm. To me, this shows how Auth0 leadership contributes to a culture of openness where engineers are not afraid to touch production, make mistakes, ask questions, and be confident in taking ownership.

**On her favorite Auth0 value:**

That would have to be: [We are obsessed with delivering customer value](https://auth0.com/blog/our-culture-and-values-at-auth0/).

Most of what we do is for customers. Even though as platform/infrastructure engineers we don’t write code directly for the product, we still put a lot of emphasis on how a tool we’re implementing, a change we’re making, or infrastructure improvements affect customers.

**On being a woman in tech:**

Growing up my mom highlighted the importance of a role model. Being a surgeon, my mom was already a strong woman in a male dominant field. Because of her, nothing felt unachievable to me. I was encouraged to take classes like math and physics in school; I was very good at it. My grandfather also highlighted the importance of "allies" to me. An ally is basically an advocate that [boosts and draws attention to an oppressed group’s own voices](https://www.huffpost.com/entry/what-does-it-mean-to-be-a-male-ally_b_596d49d8e4b05561da5a5a05). He encouraged us, especially his daughters and granddaughters, to be career and science driven. I'd like to extend this analogy and say I find that having such role models and allies is beneficial to women in tech.

I have been privileged to work with great people over the years and my exposure to negativity has been small. Unfortunately, that's not the same experience for everyone. We need more allies, education, awareness, support, and empathy as we still fight discrimination and bias. This year, UI Engineer [Dasha Nikitina](https://www.linkedin.com/in/darianikitina/), R&D Content Engineer [Kapehe Jorgenson](https://auth0.com/blog/authors/kapehe-jorgenson/), and I will be attending [Women Who Code (WWC)](https://women.dev/) this Saturday, April 13th, in San Francisco. Come meet us at the Auth0 booth!

**On the advice Dorrin would give to someone interested in this field:**

First is to try to understand the reason behind your task. Why are you typing this command or writing code this way? This thinking gives you a deeper understanding of the tech you’re using. It also helps you with troubleshooting problems that might arise in the future, and for me personally, it brings a lot of joy to know the ins and outs of what I’m doing.

Second is to keep looking if you haven’t found the right place! There are so many companies with different cultures, tech stacks and standards that you can find a company that matches all your values.

**Join the Auth0 Team**

As you've learned, we are growing rapidly at Auth0. We have multiple engineering job openings available in our [career page](https://auth0.com/careers). You can learn more about our hiring and interview process through our [How We Hire Engineers](https://auth0.com/blog/how-we-hire-engineers/) post. If you have any questions or feedback, please let us know in the comments below!

---


Meet the Experts: Dorrin Poorkay

jorge-fatta

Jorge is a Software Engineer that enjoys building tools for colleagues. He manages the Developer Tools team at Auth0. This team works on improving development workflow through tools and automation. He likes to spend time with family, playing football, or preparing and drinking all possible forms of coffee.

Engineering Manager

Jorge Fatta

Helping engineers stay focused on building features that solve the hard problems of identity for customers.



Auth0 is continuously growing. To share a couple of examples, we just hit a new milestone: [_2.5B+ monthly logins securely authenticated_](https://twitter.com/auth0/status/1101216297206059009) and we [_ended 2018 with a nearly 80 percent increase in both sales and new customers_](https://auth0.com/blog/auth0-closes-year-of-impressive-growth-in-2018/).


We are growing and scaling the organization at a really fast pace, and engineering is no exception. This presents some interesting and fun challenges:

1. Promoting and developing the **culture** that fuels this endeavor.
2. **Hiring** and retaining great engineers.
3. Minimizing duplicate work and time to be **productive** as new people come in.

This blog post is focused on how Auth0 is addressing part of that last challenge; by building a dedicated team to unleash the potential in Auth0 developers to deliver business value with confidence.

## Developer Tools Team at Auth0

In the same way that Auth0's goal is to make identity simple for developers, the Developer Tools team goal is to let our engineers fully focus on development and providing value for our customers. We want to provide the best tools to keep our developers happy and engaged shipping new features instead of struggling every day with exhausting and repetitive tasks that could be automated.

We defined the mindset we want to adopt to develop our tools and outlined a roadmap with the following vision:

> Provide toolchains that Auth0 engineering teams can use to improve their workflow, automate manual tasks, simplify complex processes, and implement a set of company-wide standards.

### What we do

1. Work closely with the engineering teams to understand their pain points, provide tools and guidance.
2. Investigate existing tools and develop new ones to solve their needs:

    * Development Environment tools.
    * Change Management tools.
    * Debugging and Performance tools.
    * Incident Response tools.
    * Work with the [_SRE team_](https://auth0.com/blog/progressive-service-architecture-at-auth0/) to integrate site reliability tools into the platform.

1. Recommended patterns & practices:

    * Identify patterns currently in use across our organization.
    * Provide developer tools for Scaffolding and Code Snippets.
    * Promote the adoption and tooling for the best engineering practices, e.g.: [_contract testing_](https://martinfowler.com/bliki/ContractTest.html).

### What we don’t do

1. While we provide general guidance, we don’t do consultancy, i.e.: we neither do work at a particular team's requests to tackle specific issues, provide advice on demand, or do an investigation by request nor develop customized solutions to solve a specific team's needs.
2. We don’t provide advice or work on particular issues on demand: our tools are developed following a *product* approach.
3. We don’t embed team members on another team to build tooling. We might do it for discovery, but development happens within the Development Tools team.
4. We don’t debug and profile internal services, we provide the toolchain for that.
5. We don’t do [_SRE (Site Reliability Engineering)_](https://auth0.com/blog/progressive-service-architecture-at-auth0/), we might provide tooling that could improve the experience during their analysis.
6. We don’t investigate a random tool or technology on demand. We do it if it is related to reducing developer pain.

<include src="TweetQuote" quoteText="Learn how our engineers stay focused on solving the hard problems of identity for our customers."/>

## Tools Development Mindset

We are approaching the development of the tools as internal **products**, guided by these principles:

1. **Ownership**: We own the tools that we ship, following a “*You Build It, You Run It*” principle.

    * We operate what we build: taking care of the CI/CD, incident response, etc.
    * We take care of not just the coding but also keeping the *product* running in good shape.

1. **Extensibility**: We develop these tools taking extensibility into account from scratch.

    * For example, any engineer should be able to easily extend* *the* CLI *that we provide to interact with Auth0’s local development environment.

1. **Internal Collaboration**: We engage our users to **contribute** with the tool evolution, collecting their feedback and welcoming their contributions to the code and documentation (via pull requests on git repositories).

We aim to follow an **iterative** process to develop our tools (just like our Product Engineering teams), working closely with our internal customers.


> The process adopted by our team suits the lean startup cycle model.

->![Jeff Patton & Associates: lean startup cycle model](https://images.ctfassets.net/23aumh6u8s0i/4TRZnZXwjpgNp5gtf4u168/b8ab189eea4a634cdbadfcf67b5c12be/lean-startup-model)<-

*[*_Lean Startup Model_*](https://www.jpattonassociates.com/common-agile-int-for-startups/lean-startup-model/)* by *[*_Jeff Patton_*](https://www.jpattonassociates.com/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/).*

<include src="TweetQuote" quoteText="The Auth0 Developer Tools team shares three key principles to develop a tools-development mindset that helped them create successful internal products for developers."/>

## Our Tools

Some of the tools that we currently maintain and regularly work on had a great impact and adoption rates within the organization but were built prior to adopting the _internal dev tools as product_ mindset mentioned above. It was originally hard for us to *learn *from the tools once released without any kind of usage metrics. For that reason, we focused on existing solutions by:

* Improving **documentation**, both user guides and internal playbooks concisely describing deployment, troubleshooting, and **contribution** guidelines.
* Instrumenting **usage and performance** metrics to **measure** the impact of our iterative improvements.

### Vivaldi

->![Containers on a dock](https://images.ctfassets.net/23aumh6u8s0i/5d1b2HI9Jjwld4HEksBQff/ec3bdb6bf8883d78cf39f907bb6f65bf/containers-on-a-dock)<-

*Photo by *[*_Guillaume Bolduc_*](https://unsplash.com/photos/uBe2mknURG4)* on *[*_Unsplash_*](https://unsplash.com/)*.*


**Vivaldi** is the tool on which we have invested most of our efforts so far. Named after the Italian musical composer, it is a [_Docker_](https://www.docker.com/) container-based development environment that allows engineers to run a local Auth0 on their machine.
Through a command line interface (CLI), Vivaldi provides commands to quickly interact with our service instances running locally in order to:

* Update dependencies.
* Run tests.
* Attach a debugger.
* Run diagnosis tools.
* Execute performance profilers.

->![Vivaldi: Docker container-based development environment](https://images.ctfassets.net/23aumh6u8s0i/1NlLXfq8I0vpBm5KL3cI5l/30cd621072a76bcd0406151786f49246/vivaldi)<-

The initial version of the tool had a **great impact on the development cycle** and was **widely adopted**. Before *Vivaldi*, developers needed to manually spin up the services they were working on, fighting with dependencies with their local environment. Now they can rely on an isolated and replicable environment, being able to spin up the entire services cluster relatively quickly.

As our teams and number of services grow, we are now actively working with teams to better implement a fast development loop without relying too much on running all Auth0 services locally. We are already planning the next generation of Vivaldi, which will support future growth in a scalable way.

### Slack Bots

->![Droid giving you a helping hand](https://images.ctfassets.net/23aumh6u8s0i/H5W70I4X8Ot6NSsj0VHyv/fadc300cf5495e31413a4ef43f2128d7/droid-giving-you-a-helping-hand)<-

*Photo by *[*_Franck V._*](https://unsplash.com/photos/jIBMSMs4_kA)* on *[*_Unsplash_*](https://unsplash.com/)*.*

We developed an internal Slack bot platform called _Gynoid_ during a hackathon and it was quickly adopted by our engineering organization. The platform is customized to satisfy the needs of our developers:

* To build Slack bots easily: just create a JavaScript file, add metadata, and you are done!.
* To install Slack bots straight from a GitHub repository.
* To extend existing bots from different sources: one bot, multiple functions, different repositories.
    * We call these extensions Droids. To install new extensions, we have a Gynoid that serves as a wrapper for this library. Our _Gynoid Droid_ is responsible for registering and extending our bots directly from Slack.

A notable Droid is one that serves as a _concierge_ for any Slack channel, properly named @concierge. It works like this:

* A channel that needs a person on duty to address direct questions invites `@concierge` to the channel.

->![Inviting the concierge Slack bot to a channel](https://images.ctfassets.net/23aumh6u8s0i/762YoyCbXhOlyM9zQAr24/469fe557035293e641012aa2bc03c672/invite-concierge-slack-bot)<-

* A teammate is assigned the role of `@concierge`.

->![Assigning the concierge role to a teammate](https://images.ctfassets.net/23aumh6u8s0i/2u1bJjRFdCbJWf48k9t1Ot/3fb1c5c67e6d6819df21f09564896e18/assign-concierge-slack-bot)<-


* When someone needs to ask anything to a team, for example, they visit the team's channel and ask the question directly to `@concierge`.

->![Asking a question to Slack bot concierge](https://images.ctfassets.net/23aumh6u8s0i/3Gtm4wdoomqbMJas4rzjGf/a1249a2842972eae97cc08b29328a28d/asking-question-concierge)<-

* The teammate with the role of `@concierge` is sent a direct message through Slackbot with the concierge request.

->![Slack bot concierge sending a direct message to teammate](https://images.ctfassets.net/23aumh6u8s0i/4nPgWa3KasUha1YjLcAmos/641263ac54adb338d5906ee7d410673b/concierge-slack-bot-direct-message)<-

* The concierge has now the responsibility to research and to address the request directly. If the request is outside of the scope of the team, the request is redirected to the appropriate channel

The concierge droid helps us avoid unnecessary noise in Slack &mdash; especially since it is widely used within our company as a good substitute for `@here` and `@channel` when asking questions. It's very useful when you have an "on-call" rotation in your team and people need to reach the teammate on call through a Slack channel.

## Roadmap

We are currently working on the next major version of our main tools, focusing on:

* **Scalability improvements**: Vivaldi, our Docker-based development environment, will run an increasing number of services without compromising the developer machine resources.
* **Robustness**: Gynoid, our slack bots platform, will have end-to-end tests and its dependencies will be upgraded to the latest stable versions, allowing our team and contributors from other teams to introduce changes or develop new *droids* with confidence.

Additionally, we’re in the early stages (discovery, viability analysis, and ideation) for a **unified internal CLI** (command-line interface): we already have multiple CLIs that provide different types of functionality. As the number of CLIs keeps growing, it will become hard to keep track of them.

Some teams will decide to use a different tech stack, which may require different runtime dependencies and a distinct CLI to better manage it. However, we could create a unified CLI, customizable and extensible to meet the needs of different tech stacks. Having a unified CLI will help internal toolchains scale while staying maintainable.

## Conclusion

We aim to provide an optimal developer experience, unified across the engineering organization. To do this we take ownership of the toolchains, iterate to improve them and encourage teams to use these tools that have already proven their value on making developers more productive.

We dedicate our Developer Tools team efforts to the discovery, building, maintenance, and promotion of reusable solutions so that the rest of the engineers don’t have to struggle with repetitive tasks, walk through slow development cycles, or constantly switch contexts to take care of maintenance tasks that can be automated.

We want Auth0 engineers to be focused on building new features that solve the hard problems of identity for our customers.

<include src="asides/AboutAuth0" />


Auth0 Internal Dev Tools: Unleashing Engineering Potential

auziros:bobby-johnson

Bobby is a full-stack developer, advocate, and evangelist at Auth0. He is a passionate engineer with an interest in learning and teaching new technologies, using open source software, and engaging the greater software development community. His experience ranges from building line-of-business applications for financial professionals with Russell Investments and Milliman to distributed social content apps with Cheezeburger and Steller.

Developer Advocate Engineer

Bobby Johnson

Learn about the four-year-long journey Auth0 took to deliver the tools needed by both field engineers and our customers to implement last mile identity solutions quickly.



Previously, we wrote about the emerging pattern of [Serverless Extensibility](https://auth0.com/blog/why-is-serverless-extensibility-better-than-webhooks/). Examples of the concept are popping up in many of the services you use daily like [Twilio](https://www.twilio.com/functions) and here at [Auth0](https://auth0.com/). In this post, I will talk about challenges our customers were facing with our Auth0 Identity product, and how this led us down the path toward implementing the [extensibility](https://auth0.com/extensibility) pattern in a variety of features.

## The problem

![NASA Engineers working on MAVEN](https://images.ctfassets.net/23aumh6u8s0i/3KQXnuCX6H4EROaqBq3hRh/e3e24c8007258b4f7b45f0aef852cebd/engineers_working_on_the_high-gain_antenna_of_the_MAVEN_spacecraft)

*Placed into the public domain by [NASA](http://mars.jpl.nasa.gov/multimedia/images/?s=1) using [Creative Commons](https://creativecommons.org/publicdomain/zero/1.0/)*

In the early days at Auth0, there were two groups: Core and Field Engineering. Core focused on the core functionality of the authentication product, and the field engineers helped customers use the product in their applications. The company was discovering what customers needed in the product.

Our customers' focus was on the authentication transaction. A lot of interesting features can attach to the process of someone trying to login:

- Profile Enrichment
- Progressive Profiling
- Authorization
- Claims Transformation

Customers will come up with an unlimited supply of feature requests. We could not possibly build every feature at once.

Moreover, sometimes building features into the core product for customers is not the right approach. We needed a way to try ideas out. An idea may sound great, but in practice be problematic. Investing core engineering resources to these ideas is very expensive.

> **"The primary use case for extensibility at Auth0 was to empower field engineers to work on the last mile solutions for the customer without involving core engineering."**<br />
> Eugenio Pace - Co-Founder, CEO

If every interaction with a customer involved identifying an idea, putting it in the backlog and coming back to them at a later date, it would add friction to the process and turn customers away.

For example, we had customers who wanted to do profile enrichment. They used services like [FullContact](https://www.fullcontact.com/) to look up a new user and grab related information about them such as their company, role, and social media accounts. FullContact is just one service as there are several others. We had prospects that were depending on these capabilities to have confidence in using us as a platform, and without it would not become customers.

## Custom code extensibility

![NASA's "Webb-cam" Captures Engineers at Work on Webb at Johnson Space Center](https://images.ctfassets.net/23aumh6u8s0i/6UpPFk1QXmAs5xequW3Wpj/23c899dfcde145fb664480ffddd2cd9f/34827899312_571fa2a976_k)

*[NASA](https://www.flickr.com/photos/gsfc/34827899312) licensed under [Creative Commons 2.0](https://creativecommons.org/licenses/by/2.0/)*

To solve this problem, we introduced a method of adding custom code into the platform that could be defined by customers. The inspiration for custom code extensibility as a solution came from spreadsheets. Excel has significant functionality out of the box, but you can always add a function, macro or calculation that better reflects your goal. Moreover, you can write them yourself directly in Excel, removing the dependency on Microsoft engineers.

> **"We wanted a similar experience for our users. A user should be able to log in to the dashboard, write a small amount of node.js code that executes later during authorization transactions."**<br />
> Eugenio Pace - Co-Founder, CEO

Like Excel, we wanted to offer users a really simple experience for customizing our product through code. We believed a user should be able to write their logic in an editor, debug it in place, and make it live in production, all without having to stand up a service. This differed from the prevalent approach at the time for dealing with customization through webhooks, which were hosted by the user.

We quickly implemented an MVP to prove out the concept. It created a process boundary between the core Auth0 stack and the customer's code. It primarily prevented well behaved, well-intentioned code from accidentally bringing down the authorization service or other sandboxed code.

Although the MVP had its limitations, it proved that the user experience for customization could be greatly improved, aligning well with our philosophy of "Identity made simple for developers."

## Evolving customization features

![NASA engineers cleaning mirror with carbon dioxide snow](https://images.ctfassets.net/23aumh6u8s0i/2NQmBSwzenRP0r4HFvU0hZ/1b0447fd2fa9bc307d91d3772f94f6c9/17402277412_5e2834517c_k)

*[NASA](https://www.flickr.com/photos/gsfc/17402277412) licensed under [Creative Commons 2.0](https://creativecommons.org/licenses/by/2.0/)*

Custom code extensibility is exposed in our customer dashboard in three ways: Auth0 Rules, Hooks, and Extensions.

**[Auth0 Rules](https://auth0.com/docs/rules/current)** were the first publically available use case where our customers could easily add custom functionality to their authorization flow directly in the dashboard. Rules execute after authentication but before authorization. We offer a gallery of Rule templates that make it easy for customers to address common scenarios out of the box. Because Rules are code though, customers can easily customize the logic further to meet their specific needs.

A customer clicks a button to add a new Rule, selects one from a set of standard templates which they can customize with a simple editor right in their browser. When saved, the Rule is active on their account for all authentication requests.

![Rules UI](https://images.ctfassets.net/23aumh6u8s0i/A8nlyZBGaECLAhpZ2k9CK/892d84cff88e39e3a51a370ba302964b/rules)

Rules allow you to easily customize and extend Auth0's capabilities. They can be chained together for modular coding and can be turned on and off individually.

Rules were really powerful but were limited only to login. Once customers got a taste of rules, they started to ask us for more places where they can customize the product, and so Hooks were born.

**[Auth0 Hooks](https://auth0.com/docs/hooks)** allow you to customize the behavior of Auth0 using custom code that is executed against several extensibility points. Not only can you introduce customization during the client credentials exchange, but also pre and post user registration. Hooks also take advantage of a more feature rich editor.

![Hooks UI](https://images.ctfassets.net/23aumh6u8s0i/5z6VxLuwFqfKdKRba9vA6W/f63a755d3c63187999e262867c1fdff0/hooks)

While both Auth0 Rules and Hooks give you fine-grained control of the authentication pipeline, **[Auth0 Extensions](https://auth0.com/docs/extensions)** are mini-applications that extend the Auth0 identity product with 3rd party integrations.

They do not directly tie to any specific event in the system. Instead, they can invoke any Auth0 API, can configure the customer tenant, deploy Hooks or Rules on installation and even have an associated user interface. They are extremely powerful and opened up many use cases.

![Extensions UI](https://images.ctfassets.net/23aumh6u8s0i/3z6SONf0xAGkS2UBQavAUL/ce74f139ed89bb283121f9f69abe7482/extensions)

Auth0 Extensions are written using the Webtasks infrastructure. Customers can select an Extension from our gallery and provide a set of configuration options to begin using one.

This is just the beginning. We're constantly looking to enable richer and richer customization in our product, and you'll continue to see us opening new doors as we learn.

## The impact on our sales engineers and customers

![NASA engineers celebrating curiosity](https://images.ctfassets.net/23aumh6u8s0i/5pFHSx1biEJCYLFEKsuh6g/c75c5def4fcb853016d4d68e853ea9e7/celebrating_curiosity)

*Placed into the public domain by [NASA](https://commons.wikimedia.org/wiki/File:Celebrating_Curiosity.jpg) using [Creative Commons](https://creativecommons.org/publicdomain/zero/1.0/)*

Adding extensibility to the identity product opened up a window of customization where field engineers could work independently from core engineering. They could deliver customizations very quickly without waiting weeks or even days, enabling many successful sales engagements.

> **"In some cases, we were able to deliver demos where we implemented feature requests in the demo during the meeting. It was amazing for field engineers and our customers."**<br />
> Eugenio Pace - Co-Founder, CEO

Putting extensibility into the hands of customers also gives us great insights into where the market is going. If we see an extension being implemented again and again through the use of custom code, that is a validation of that feature and an opportunity to add in the core product.

Multi-Factor Authentication came about this way. MFA was not a switch on the dashboard initially. It was merely a rule you applied to your account. Over time, our customers' usage of this rule indicated MFA was an important feature to have in the core product.

For more examples, take a look at our [rules repository](https://github.com/auth0/rules) on Github. Every single one comes from a real-world customer use case.

> **"Every event in the life cycle of the user can be expressed through code and in that way we can support any backend out there in a flash. No matter how customers encrypt or hash passwords; whatever they do is supported because they can provide the details using custom code."**<br />
> Sandrino Di Mattia - Engineering Lead

## The impact on our business

![Happy Employees](https://images.ctfassets.net/23aumh6u8s0i/3tb9Pbddo96TUGVZMxu68U/39443eb09615ed15655b82f45bc54862/culture-2)

Not only did we make our customers happier, opening up customization provided us a direct return on revenue. Looking at our data, we found our customer retention increased up to 10x for those users that took advantage of customizing. Not only that, but our largest deals depend on these customizations even today, bringing 70% of our cloud revenue.

## Summary
In the past four years, we've been exploring how to better enable our users to customize and extend our SaaS. On our journey, we discovered the Serverless Extensibility pattern provided a great solution. We found that allowing extensions to be authored in-line provided tremendous value both to our customers and to the business. It allowed us to close more deals and deliver customer features much more quickly and cheaply than before. 

_I would like to thank [Eugenio Pace](https://twitter.com/eugenio_pace), [Sandrino Di Mattia](https://twitter.com/sandrinodm) and [Tomasz Janczuk](https://twitter.com/tjanczuk) for taking time out of their busy schedules to be interviewed for this post._

<include src="asides/AboutAuth0" />


Our Journey toward SaaS Customization and Extensibility at Auth0

tim-ferrell

I enjoy meeting the complex technical challenges that Auth0 faces with the support that I get through the company's unique culture and distributed workforce. It’s truly empowering.

Engineer

Tim Ferrell

Learn about the engineering principles, technology, and goals behind the gRPC system by setting up a service.

Creating a Node gRPC Service Using Mali

37590801?s=460&v=4

Howdy! 🤠 I do technology research at Auth0 with a focus on security and identity and develop apps to showcase the advantages or pitfalls of such technology. I also contribute to the development of our SDKs, documentation, and design systems, such as <a target='_blank' rel='noopener noreferrer' href='https://github.com/auth0/cosmos'><strong>Cosmos</strong></a>.<br /><br />The majority of my engineering work revolves around AWS, React, and Node, but my research and content development involves a wide range of topics such as Golang, performance, and cryptography. Additionally, I am one of the core maintainers of this blog. Running a blog at scale with <strong>over 600,000 unique visitors per month</strong> is quite challenging!<br /><br />I was an Auth0 customer before I became an employee, and I've always loved how much easier it is to implement authentication with Auth0. Curious to try it out? <a href='https://auth0.com/signup' data-amp-replace='CLIENT_ID' data-amp-addparams='anonId=CLIENT_ID(cid-scope-cookie-fallback-name)'><strong>Sign up for a free account</strong></a> ⚡️.

Staff Developer Advocate

Dan Arias

Create modular and reusable components that can be shared across projects by building a component library with React and Storybook.



At Auth0, we want our customers to be successful using our [authentication solutions](https://auth0.com/b2c-customer-identity-management). The Customer Success Infrastructure Team builds customer-facing and internal tools that help us achieve that goal. One of the technologies that have enabled them to have rapid iterations in user interface development is [React](https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/).

[![Authenticate React using Auth0](https://images.ctfassets.net/23aumh6u8s0i/6I21NcoVBzBDHBnSxXfaZw/49c51ce5e8389783b607cd5312811480/react-auth0-banner)](https://auth0.com/authenticate/react/)

This team builds a variety of different projects such as the software that runs our [Auth0 Support Center](https://support.auth0.com/) and other internal tools that power internal support workflows. In addition to React, they develop their projects using [Node.js](https://nodejs.org/en/), [hapi.js](https://hapijs.com/), and [Redux](https://redux.js.org/). It is a JavaScript-heavy team and that is driven by building quality features quickly.

![Auth0 Customer Success Infrastructure Team](https://images.ctfassets.net/23aumh6u8s0i/1TZtO3xXdNrGdS2nshJank/3ab11dc08159450bbd3af27ae27d3785/auth0-customer-success-team)

> Would you like to be part of a Team like this? We are currently hiring engineers to [join the Customer Success Infrastructure team](https://auth0.com/careers/positions?areas=Customer%20Success)!

[Guillermo Rodas](https://twitter.com/glrodasz) is one of the Engineers of the Customer Success Infrastructure Team. He recently led a project initiative known as _Support Center Components_ that solved a problem centered around having duplicate React components in our customer-facing and internal tools site.

In this blog post, through Guillermo's insight, we are going to explore how the Account Center Team is using [React and Storybook](https://storybook.js.org/basics/guide-react/) to optimize UI development and promote consistent branding by creating a component library that can be shared across different projects.

## Don't Repeat Yourself (DRY)

[Auth0 Support Center](https://support.auth0.com/), a customer-facing site, and Customer Success Tools, an internal site, have similar elements on their interfaces. For example, despite having a different business context in each interface, the _Quota Utilization_ feature in both interfaces uses the same structure to report data to the user.

![Two identical React component defined in different codebases](https://images.ctfassets.net/23aumh6u8s0i/1lutGPjqyYNHccPBpXxf3z/ba96df5eb6edb898634676ced807c5ad/support-center-vs-cs-tools-component)

The problem that we had was that this structure was being implemented as a React component separately for each interface instead of sharing the implementation. The development team was duplicating components to solve the same problem. This approach inherently created pain points for developers as _Quota Utilization_ was just one of a few other features that had overlapping front-end architectures within our sites.

Having duplicate code is not ideal. One version of the code may be more up-to-date than another version, creating something similar to a race condition around code versioning. If a bug is found, it would need to be fixed in every place that shares the code while [hoping that the developer can remember them all](https://stackoverflow.com/a/2490897). An inconsistent bug fixing process could multiply bugs and create havoc in a codebase.

> "If you see patterns in your code, that is an [indication it is prime for DRYing](https://americanexpress.io/clean-code-dirty-code/). Sometimes this means standing back from the screen until you can’t read the text and literally looking for patterns." [(Donavon West, American Express Developer Relations)](https://twitter.com/donavon)

The solution for this code duplication problem was to make the code DRY (Don't Repeat Yourself). We needed to write the presentational component once and then have each feature/interface implement it from a single source of truth: a component library.

As explained by [Mark Perkins](https://twitter.com/allmarkedupa) from [Clearleft](https://clearleft.com/) on their insightful post [_On Building Component Libraries_](https://clearleft.com/posts/on-building-component-libraries), a component library is an effective and robust format for delivering documented code and design patterns to developers and clients. React lends itself to the architecting of a component library since it involves the process of thinking and building in a "componentised manner", as coined by Mark.

<include src="TweetQuote" quoteText='react lends itself to the architecting of a component library since it involves the process of thinking and building in a "componentised manner", as coined by @allmarkedup from @clearleft'/>

![Graphic of example web component library](https://images.ctfassets.net/23aumh6u8s0i/7b4rPdBjXGdnxv24ty2Vzc/7aa292937b5eb827ea725d4010561686/component-library)

[Source](https://blog.hichroma.com/beyond-bootstrap-moving-from-ui-toolkit-to-component-library-f0a34f05e98b)

## Integrating a Component Library

Implementing the concept of a component library within our workflow was an architectural decision that required us to further strategize our component and feature development process.

For example, when creating a component, we started asking the following questions:

- How to categorize the component within a library? Should we have categories at all?
- How should a prototype of the component be presented? Should a blank page with mock data be used?
- Should different states of the component be presented on its prototype?

It was critical to be able to answer these questions visually and in an organized manner to help us iterate cleanly through our feature development process. This process typically consists of:

- Creating an MVP (Minimum Viable Product) or POC (Proof of Concept).
- Getting feedback on the MVP/POC.
- Integrating feedback through development iterations.

Through that process, we are constantly showing how the user interface presents data through its components and defining the states of a component based on the data that it can present. We needed a tool that could let us:

- Create our components independent from any specific feature integration.
- Preview our components and their different states.
- Let us categorize each component into families for easier lookup.
- Host our components in a central location to create the concept of a library.

With React, we could already define components. We needed something to preview, categorize, and host them. Fortunately, we were able to fulfill all those requirements using one single tool: Storybook.

<include src="TweetQuote" quoteText="Don't reinvent the  &lt;Wheel /&gt;. To create modular and reusable components that can be shared across projects, build a component library with React and Storybook."/>

![Meme - I believe in code reuse... CTRL-C, CTRL-V](https://images.ctfassets.net/23aumh6u8s0i/2J67xmm28v3y1IGGkdHtmh/094c27a7ffdb0f2ff51d89c771ad3184/believe-in-code-reuse)

[Source](https://hermesespinola.wordpress.com/2016/11/24/code-reusability-dont-reinvent-the-wheel/)

## Storybook: Let Your Components Tell a Story

[Storybook](https://storybook.js.org/) is a UI development environment for UI components. It acts as a board where we can stage our components and visualize them in different states and interact with them as if they were on a live application. This is all done in isolation since Storybook runs outside of our app. Storybook has its own Webpack setup that is very similar to the one from `create-react-app` but can be configured to meet our needs. The platform also comes with a built-in dev server to help us preview our components locally.

![React Storybook component preview](https://images.ctfassets.net/23aumh6u8s0i/7aBehDlHBJczkWVH02PVSd/1449412c3d8c1e9ddc70e599c539c864/storybook-demo)

As we have described, we already had a working project when we decided to use Storybook to create a component library. However, because of its independent architecture, adding Storybook to our existing project did not create any burden or changes to our existing codebase.

We added it like any other `npm` package and then imported our existing components into its platform. However, it did require us to think differently about the creation, maintenance, and sustainment of our components moving forward &mdash; an integrative process we call "storybook-driven development."

With Storybook, we have been able to build our React components gradually in isolation without having to worry about having the final component version or environment ready from the start. It has doubled as a staging and planning tool for us.

<include src="TweetQuote" quoteText="Storybook and React let us plan, stage, and build components gradually. It's a living style guide."/>

## Documenting and Testing Pain Points

Our Customer Success Infrastructure team had a second problem: documenting and testing all the different scenarios of each project feature. In our projects, we have tests with high coverage that are run through a [continuous integration pipeline configured in Heroku](https://devcenter.heroku.com/articles/heroku-ci).

In Guillermo's words:

> "We have strong tests along with continuous integration because we want to have nice weekends without worrying about our production builds failing. The most common phrase in a [Pull Request (PR)](https://help.github.com/articles/about-pull-requests/) is: Please add the tests."

Aside from testing, we place high value in documenting code. It's our legacy for anyone who will be working with our codebase in the future. Fortunately, having a component library like Storybook allows us to document components visually and declaratively. Storybook provides a developer with all the information needed to understand the structure and state of a component.

Testing is hard. For most developers, testing is a sad story. Well, not anymore! With modern and powerful tools, our testing story is a happy one.

In React, there are different aspects of UI Testing. We categorize them as follows along with their tooling:

- Structural Testing:
  - [Enzyme](https://github.com/airbnb/enzyme)
  - [Jest Snapshot Testing](https://jestjs.io/docs/en/snapshot-testing)
- Interaction Testing:
  - Enzyme
- CSS/Styles Testing:
  - Image comparison to do regression testing
  - Jest Snapshot using inline styles
  - Other tools like [BackstopJS](https://garris.github.io/BackstopJS/), [PhantomCSS](https://github.com/HuddleEng/PhantomCSS), [Gemini](https://gemini-testing.github.io/), and [Happo](https://github.com/Galooshi/happo)
- Manual Testing

Storybook integrates with Jest Snapshot through an add-on called [`StoryShots`](https://github.com/storybooks/storybook/tree/master/addons/storyshots/storyshots-core). `StoryShots` adds automatic Jest Snapshot Testing to our codebase by using our existing Storybook stories as the input for Jest Snapshot Testing.

With our Heroku CI pipeline configured, each time someone makes a PR with a new component against our Storybook, this automated testing is triggered and a visual preview of our app is created. This lets us perform structural and style testing much faster.

## Sharing our Engineering Knowledge

We are happy to share what our engineering process looks like in detail and how it has positively impacted our developer experience in creating, testing, and documenting user interfaces.

You may stay in touch with us by following [@auth0 on Twitter](https://twitter.com/auth0), subscribing to our newsletter, or checking this blog back from time to time. We hope that you'll love the content that we are creating.

<include src="asides/AboutAuth0" />


Our Engineering Experience with React and Storybook

annybell-villarroel

Anny believes in a people-centric trust-based approach for security culture and awareness &mdash; one where we help people learn about cybersecurity in a fun way, and make them feel empowered, rather than afraid. She also leads the Madrid chapter for WoSEC &mdash; Women of Security.

Security Culture Manager

Annybell Villarroel

Let’s cover the top 10 cybersecurity takeaways of my social engineering training at Black Hat.



I took the ["Achieving Security Awareness Through Social Engineering Attacks"](https://www.blackhat.com/us-18/training/achieving-security-awareness-through-social-engineering-attacks.html) course at [Black Hat this year](https://www.blackhat.com/us-18/)!

<br />
<div style="display: flex; justify-content: center;">
  <blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">“Achieving Security Awareness Through Social Engineering Attacks” <a href="https://twitter.com/hashtag/BHUSA?src=hash&amp;ref_src=twsrc%5Etfw">#BHUSA</a> Training taught by <a href="https://twitter.com/jaysonstreet?ref_src=twsrc%5Etfw">@jaysonstreet</a> &amp; <a href="https://twitter.com/aprilwright?ref_src=twsrc%5Etfw">@aprilwright</a> will use current Red Team strategies to develop a better understanding of how attackers use SE <a href="https://t.co/yuojeClInS">https://t.co/yuojeClInS</a></p>&mdash; Black Hat (@BlackHatEvents) <a href="https://twitter.com/BlackHatEvents/status/1002976909268045827?ref_src=twsrc%5Etfw">June 2, 2018</a></blockquote>
  <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<br />

It was eye-opening, tremendously interesting, and fun! It was facilitated by [Jayson Street](https://twitter.com/jaysonstreet) and [April Wright](https://twitter.com/aprilwright). Jayson gets paid by companies to break into their own facilities through [Social Engineering](<https://en.wikipedia.org/wiki/Social_engineering_(security)>). He shared many amazing stories, like the time he [gained full access to a bank in Beirut in two and a half minutes](https://www.youtube.com/watch?v=UpX70KxGiVo&feature=youtu.be&t=434).

![Corgi dog meme, coding on computer](https://images.ctfassets.net/23aumh6u8s0i/60r47IT9a84TsaSpyvHB4h/1f15d9303d87cc13b35de378f41ae7fc/corgi-social-engineering-meme)

[Source](https://imgflip.com/meme/38390688/corgi-hacker?sort=latest)

Here’s a summary of what we discussed in the training, along with key takeaways:

## OSINT and Social Media

> “Information doesn’t have to be secret to the valuable” ~ CIA

One of the key elements of Social Engineering is [Open-source Intelligence (OSINT)](https://en.wikipedia.org/wiki/Open-source_intelligence), which is insight produced from data collected from publicly available sources. **If you don’t have proper privacy settings in your social media accounts, the information you put there is public**.

In class, we discussed the case of a guy named Travis who put pictures of his badge, passport, plane tickets, job title, workplace and even emails on Instagram.

We analyzed how someone that overposts on social media could be targeted, and it’s not a surprise that it’s relatively simple. We also talked about tools and techniques to get and find relevant information.

There was an exercise about drafting (not sending) a spear phishing email in 1 hour targeted at someone in our organization using OSINT. Nobody used their own workplace and nobody said where they worked, but we completed the task with good results.

**Takeaway #1:** Review your privacy settings and don’t post private information on social media.

<include src="TweetQuote" quoteText="Review your privacy settings and don’t post private information on social media. Open-source Intelligence tools could be used to mine your data and create phishing opportunities."/>

## WiFi Pineapple and Bash Bunny

As part of the training, they gave us [some interesting gadgets from Hak5](https://www.hak5.org/) including a [WiFi Pineapple](https://www.wifipineapple.com/) and a [Bash Bunny](https://wiki.bashbunny.com/#!index.md). They are tools meant to be used for penetration tests, and they have many pranks that can help with Security Awareness programs by showcasing their associated dangers in safe and controlled setups.

> We also got a [Packet Squirrel](https://www.hak5.org/gear/packet-squirrel) as an extra gift!

### WiFi Pineapple

The WiFi Pineapple is a [Wireless Auditing tool](https://www.tutorialspoint.com/wireless_security/wireless_security_tools.htm) that can work as a [Man-in-the-middle platform](https://en.wikipedia.org/wiki/Man-in-the-middle_attack). Among others, it allows the owner to intercept an open WiFi connection and inspect and modify HTTP traffic, redirect the user to a malicious site, or associate with past public WiFi connections and “pretend” to be one of them.

For example, if you’re near a Pineapple while your phone has WiFi turned on and is actively looking for connections, all of the sudden you may connect to the airport network you used 6 months ago and a site may ask you to pay for the service. They mention it on the [Silicon Valley TV Show](https://www.youtube.com/watch?v=9FckHMPBs_Q).

This is the picture of a WiFi Pineapple Tower because… Black Hat.

![WiFi Pineapple Tower at Black Hat Conference](https://images.ctfassets.net/23aumh6u8s0i/JCZHfzvkgBGa4Hp35EuBW/787cc9176b637d4189bab7e9d312a068/wifi-pineapple-tower)

**Takeaway #2:** Avoid open or public networks as much as possible, especially in crowded spaces. If you’re not in a trusted space, turn on WiFi only when you really need it.

<include src="TweetQuote" quoteText="Avoid open or public networks as much as possible, especially in crowded spaces. If you’re not in a trusted space, turn on WiFi only when you really need it."/>

### Bash Bunny

The Bash Bunny is a USB attack platform that can emulate trusted USB devices like Gigabit Ethernet, serial, flash storage and keyboards.

![Bash Bunny USB platform.](https://images.ctfassets.net/23aumh6u8s0i/2NNQP0gnYiYvYEEFuaHUsc/a78cb5ae090bb73827007b4051f99f01/bash-bunny)

We did a couple of experiments in the class: First, we used a “prank” payload that [rickrolls](https://en.wikipedia.org/wiki/Rickrolling) the target at a specific date and time. It took less than 20 seconds to deliver this payload.

Then we tested a “recon” payload and we could get the full terminal history, clipboard content, system users, [`ifconfig`](https://en.wikipedia.org/wiki/Ifconfig), WAN IP, and all installed applications. This took a little bit longer, but it was still fast and the computer was in sleep mode.

**Takeaway #3:** Don’t plug in random USB drives and be cautious when working on public spaces.

<include src="TweetQuote" quoteText="Don’t plug in random USB drives and be cautious when working on public spaces."/>

## Conclusion and Other Takeaways

We talked about other topics such as policies, security awareness programs, memes and the importance of repetition during training. These are the top 10 Takeaways of the experience:

1.  Review your privacy settings and don’t post private information on social media.

2.  Avoid open or public networks as much as possible, especially in crowded spaces. If you’re not in a trusted space, turn on WiFi only when you really need it.

3.  Don’t plug in random USB drives and be cautious when working on public spaces.

4.  Clickbait is widely used in social engineering, don’t trust it.

5.  Before running phishing campaigns, there should be policies and formal training in place.

6.  Although potentially controversial, hard to spot spear phishing emails create a more impactful “teachable moment” (as Jayson says).

7.  Certain topics of Security Awareness training should be tailored by role. An organization should have a site that groups all this information and internal security-focused newsletters could be useful as well.

8.  Controlled live demos with tools like the WiFi Pineapple and the Bash Bunny help raise security awareness.

9.  Prizes and gamification support these efforts.

10. It is important to always explain the purpose of the training, demo or campaign. We don’t ever want you to fail, we want to empower you and help make you one of our strongest lines of defense:

![Security training at Black Hat Conference](https://images.ctfassets.net/23aumh6u8s0i/386zANR8fvarMMfbzH9Mfg/5e492f230e1d8b29414d4eb3798ba793/teammate-empowerment)

<include src="TweetQuote" quoteText="Security training and awareness campaigns make people the best line of cybersecurity defense"/>

<include src="asides/AboutAuth0" />


Black Hat Training: Achieving Security Awareness Through Social Engineering Attacks

Industry thought leader Christian McCarrick brings more than 20 years of experience



BELLEVUE, Wash. -- July 30, 2018 -- [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced that [Christian McCarrick](https://www.linkedin.com/in/christianmccarrick/) has joined the company as Vice President of Engineering. As a technology veteran and renowned thought leader on software engineering and technology leadership, McCarrick will be responsible for driving innovation and growth within the engineering team; and working alongside CTO and Co-founder Matias Woloski to continue expanding the company’s Universal Identity Platform.

McCarrick has a 20+ year history in the software engineering industry, having previously served as SVP of Platform Engineering at Global Tel*Link. He also held senior leadership positions at Telmate, AltX, and Mobitor Corporation. McCarrick is a regular speaker at engineering leadership conferences and has recorded nearly 50 podcasts at [SimpleLeadership](http://simpleleadership.io/category/podcast/) on topics like scaling engineering teams, nurturing inclusive environments, building remote teams, and much more.

“Christian’s pedigree in software engineering and technology is extremely impressive, as is the knowledge he has accrued over his long and successful career,” said Eugenio Pace, CEO and Co-founder. “We know that Christian will be an incredible addition to our company from an engineering standpoint, but equally important, he embraces our company values and is a fantastic fit with our culture as well.”

“The more I interacted with Auth0, the more I recognized what a unique company it is. Not only is it growing at an exponential rate, but the way Auth0 differentiates itself from other identity platforms on the market is a large part of why I chose to come here,” said McCarrick. “I also resonate strongly with its emphasis on culture and values. I am thrilled to be part of this organization and look forward to contributing to future growth.”

<include src="asides/AboutAuth0" />

### **Media Contact:**

Jeana Tahnk<br>
Corporate Communications<br>
Auth0<br>
[jeana.tahnk@auth0.com](mailto:jeana.tahnk@auth0.com)

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


---


Auth0 Bolsters Executive Team with New VP of Engineering

saravana-kumar

Guest Author

Saravana Kumar

Learn how utilizing identity solutions like Auth0 allows your engineers to focus on what matters most to your company - developing your SaaS product's unique features.



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

---

**TL;DR**: In this article, we will explore some of the key technical considerations you have to make while building highly-scalable SaaS products. The idea is to show that it's better to use reliable PaaS (Platform as a Service) vendors available in the market instead of utilizing your valuable engineering resources on infrastructure requirements. As you will learn, this will make your engineers available to focus on what matters the most, the key features of your project.

<include src="TweetQuote" quoteText="Relying on battle-tested solutions allows your engineers to focus on what matters most to your company — the unique features of your SaaS products."/>

## Introduction

Before going into the details, I need to give you a short background of Document360, which will help you to understand the context of the article better.
 
[Document360 is a self-service knowledge base product](https://document360.io/) that helps you to create public or private product documentation. Take as an example [Auth0's own documentation](https://auth0.com/docs). Using Document360, you can easily build such product documentation.

![Document360 logo](https://images.ctfassets.net/23aumh6u8s0i/1EvAgNetdKQ85x3DI6FOtz/7c207131cb5d55a5cc6ad5b05cd9450d/document360_logo)
 
When the idea for Document360 was conceived at the end of 2017, one of the key decisions we have made was to build a solution to scale to unlimited users without any architectural changes. This means that the product has to serve 500 customers today and it shouldn't suffer big architectural changes to serve 500,000 customers in a few years down the line.
 
Architecturally, this requires a different level of thinking and infrastructure requirements when you are designing a system that's capable of 500 customers and 500k customers. You need to be careful you are not over-engineering the solution, which will end up being difficult to manage and very expensive.
 
For example, let's say you have the requirement to pick a video file from a storage location to do some processing (like creating a transcript) and to store the result in a third-party storage location. When you are looking at processing 5 video messages per day, the solution is pretty simple, but imagine if you are YouTube or Wistia and need to process 100,000+ videos per day. Then, this single piece of functionality will require significant architecture and infrastructure investment.
 
If you do not plan correctly and decide to build scalable components yourself, your valuable software engineering time will be spent on creating basic versions of those functionalities. The cloud Platform as a Service (PaaS) market has evolved significantly in the past 5-8 years and, today, there is a specialized offering for each piece of the puzzle. It might be a smart move to pick the required Lego blocks and assemble it together rather than building everything yourself.

## Core Services for Cloud Scaling

For Document360, there are five core pieces of the product that required cloud-scale thinking:

1. the Identity Management (user authentication) system;
2. an user-facing web application;
3. technical-writers-facing web application;
4. a search engine;
5. and data storage.

Before going into identity management, which is the core of this article, let's quickly take a brief look at the background about other scalable parts of the architecture.

### User-Facing and Technical-Writer-Facing Web Apps
 
These web applications are straightforward requirements. Both applications should be scalable, reliable, and fast to provide a great experience to both end customers and technical writers. We decided to use [Microsoft Azure Web Apps](https://azure.microsoft.com/en-gb/services/app-service/web/) as the core front-end facing technology with [Azure Traffic Manager](https://azure.microsoft.com/en-gb/services/traffic-manager/) to route the traffic to the closest location.

### Search Engine
 
For any self-service knowledge base product, a good search engine is the key. These days, people do not navigate through your structure, they will just go and hit that big search box to look out for answers. We need to make sure the search feature is robust and, again, scalable when 1000's of customers arrive. There is no point in building this in-house. As such, we decided to go with [Algolia as our search provider](https://www.algolia.com/).

### Data Storage
 
A document management product like Document360 is full of text documents, so we need a reliable storage (database) with fast read and write capabilities and that can also scale as we grow. For this feature, we decided to go with [MongoDB cloud as our data storage provider](https://www.mongodb.com/cloud).

## Identity and Access Management with Auth0

Now, let's get a bit deeper into the main part of this article: ["Identity Management as Service"](https://auth0.com/learn/cloud-identity-access-management/). Document360 got various types of users logging into the system. When you are building a public facing self-service knowledge base, your draft writers and editors need to safely login to the system to produce relevant content. In some scenarios, where the customer decided to keep their self-service knowledge base private to the organization, then the whole organizations need to securely login in.

![Managing Identity with Auth0](https://images.ctfassets.net/23aumh6u8s0i/56TDJXutAc7DPAGwcknHY9/0ce17a9352d60d4a5382acf67f55c2e4/p-dashboard-6fc11ba51b)

Out of the five core areas of Document360, getting the initial authentication part in a secure, reliable, and scalable part is the most important aspect. For this, we decided to go with [Auth0 to provide the initial login and user authentication for our product](https://auth0.com/).

There are few reasons why we decided to use Auth0 instead of custom building our own identity providers:

- **Enterprise-Ready**: Even though capturing credentials (username/password), validating them against your database, and issuing a validation token might look like a simple task, soon, everything get complicated when you look at the scale factor. It would have taken months for our developers to build [an identity solution with the B2C features that Auth0 provides](https://auth0.com/b2c-customer-identity-management). More than that, it would take years to reach the level of quality and security of what Auth0 can provide.
- **Hack-Proof**: These days, when you are building a SaaS product like Document360, you need to worry about the DDOS attack and identity hacking. Every now and then, there is something on the news saying that one of the top websites was hacked. As such, it's not worthing the risk for us to do it ourselves. A product like Auth0 deals with billions of identity validation every day will be [better equipped and more secure than any in-house solution that we come up with](https://auth0.com/security). Enabling functionalities like [breached password detection](https://auth0.com/breached-passwords) enables that our users data is secure..
- **Trivial to add more providers**: Initially, we are starting with a standard username/password for identity verification. However, our plan in later stages is to support more identity and [single sign on (SSO)](https://auth0.com/single-sign-on) capabilities. By using Auth0, we can rest assured that, when the time comes, we will be able to [easily support other identity providers like Azure Active Directory, LDAP, and social identities (like Facebook, Google, LinkedIn etc)](https://auth0.com/docs/identityproviders). With Auth0, this is more of a trivial configuration change rather than spending weeks building support for new identity providers.
- **Low cost**: If we put together the total investment required to build and manage an identity solution, we would be amazed. The effort and the investment will all add up pretty quickly because you will need specialized engineering resources blocked just for this feature and for the infrastructure requirement. By using Auth0, we save money by simply [paying based on our usage](https://auth0.com/pricing). That is, we pay more when we make more money.
- **Rules trigger on identity**: This is one of the cool features we take advantage of at Auth0. We have requirements like, whenever a new user signup, we need to notify the sales team. With Auth0, we achieved this by plugging in [the Zapier integration after a successful authentication](https://auth0.com/rules/zapier-new-user). This was trivial.
- **Single Sign On**: In the Document360 case, we have two different web portals. One for where the Technical writers produce knowledge base content and another one for user/customer facing website (public or private). When the customer decides to go private, then [a seamless Single Sign On experience](https://auth0.com/docs/sso/current) is required between both the portals. This is achieved seamlessly using Auth0.

<include src="TweetQuote" quoteText="By using Auth0, we save money by simply paying based on our usage. That is, we pay more when we make more money."/>

## Summary

If you are building a SaaS product today, you really shouldn't think about building things yourself. The modern way of building stuff is all about assembling the best solutions in the industry together and constructing a solid application. That's exactly what we have done in our case. The core parts of the business are running with the help of great products in the market and we act more or less like an orchestrator to assemble and create a beautiful music out of all these talents.

<include src="asides/AboutAuth0" />

## About the Author

Saravana Kumar is the Founder of [Document360](https://document360.io/), a  product that helps your team create, collaborate, and publish a self-service knowledge base for your software with ease.  Saravana is passionate about technology and he holds the famous Microsoft Most Valuable Professional title for 12 years in a row. He founded and scaled three other successful enterprise products ([BizTalk360](https://www.biztalk360.com/), [Serverless360](https://www.serverless360.com/) and [Atomic Scope](https://www.atomicscope.com/)) in the last 7 years.


Cloud-Scale Thinking from Day One for Your SaaS Products

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

Auth0 CISO Joan Pepin explains how making security easier makes things safer for users, but requires more planning from engineers to render security seamless.



**TL;DR:** Security vs. Convenience: To truly keep info safe you need to pull off both — here’s the why and the how.

---

In the security industry, everybody used to believe that to be secure, something couldn’t be convenient. Security and convenience functioned only in opposition. Making access hard was the best way to keep info safe.

But then we ran up against the human factor.

Since the first password breach — only a year after passwords were invented — we’ve been looking for ways to make passwords safer. First, we made them harder. Which means we added increasing levels of complexity to the the string of characters that served as an access key and made things even worse by demanding that passwords be changed at regular intervals.
This gave birth to the password on a Post-It Note that gets put up right beside the monitor.

For people who don’t want Post-Its everywhere, Amazon now sells a password diary. My review, which pointed out the security risks of this product, was voted “unhelpful” by 300 people. Apparently, many silent others disagreed with me. Amazon now carries multiple versions of the password diary, each of them with positive reviews in the hundreds.

<include src="TweetQuote" quoteText="@Auth0 Ciso Joan Pepin explains how making security easier makes it safer. @CloudCISO_Joan"/>

## The Argument for Easy

The proliferation of password diaries on Amazon is an understandable (if unwise) response to a technology landscape that is getting more diverse and more complicated daily. Consumers are demanding more customization and employees want the same kind of experience that they have on their consumer devices. We now have non-technical people accustomed to accessing very technical services throughout the course of their day — and they don’t want to remember five or more different passwords to get everything done.

Security teams can create systems and protocols — that’s a large part of what I do as Auth0’s CISO — but none of this keeps anything safe if people won’t use the systems as intended. So, if we know they are going to go around the procedures and protocols, why not make it easier for them to comply?

## NIST Simplifies Password Guidelines

After watching people try to respond to tortuously complex password requirements, NIST (the National Institute of Standards and Technology) revised [guidelines](https://auth0.com/blog/dont-pass-on-the-new-nist-password-guidelines/) last summer. As a non-regulatory division of the U.S. Dept. of Commerce, NIST only has power over standards for federal sites in the United States, but it exerts deep influence on corporate standards everywhere. Companies often use NIST as a basis for their own policies.

So NIST’s new take to digital identity offered a host of guidelines, including the recommendation to only change your password if you believe you’ve been compromised.

Ironically, asking people to create longer passwords that might be easier to remember and changing them infrequently increases security.

Making it easier, makes it safer.

Except that NIST also recommends multifactor authentication, which can appear inconvenient, if not hard.

## Multifactor’s Already Convenient (Really)

You need a strong gate between the rest of the world and your set of authenticated users. As I mentioned earlier, you need that gate to be convenient or your users will figure out a way around your protection.

On the outside, NIST’s recommendations for multifactor authentication looks like they’re reverting to the need for security to offer a challenge, but really, what is multifactor authentication?

Multifactor verification just requires that users demonstrate at least two of the “something you know” (like a password), “something you have” (like a phone), and “something you are” (like a fingerprint) drastically decreases the probability of a successful attack.

![If you’ve ever used an ATM, you’ve used multifactor authentication.](https://images.ctfassets.net/23aumh6u8s0i/3BDVo7QFcEHkagMSGqojTw/66a82eac8f085308b4eed786fe0ae995/atm)
<p>_If you’ve ever used an ATM, you’ve used multifactor authentication._</p>

Multifactor authentication has been around since the 1980s, when ATMs came into use. “Something you know” is your PIN number and the “something you have” is your ATM or debit card. That stereotypical grandmother that people like to mention in their examples has been using multifactor authentication since before some of us were born.

## Easier Requires More Engineering Effort

Security industry experts weren’t entirely wrong when we first worried about the danger of ease. Easy can be risky if enough thought hasn’t gone into the user experience.

An engineer has to do a lot of thinking to make things easy. Possible use cases, potential tech, interactions, and threat vectors like hacking, accidental use, and misconfiguration all require thorough consideration and planning.

Baby and pet cams are a prime example.

After setting one up over your WiFi your customers check in on their kid (or dog) from work through their laptop or phone.

Seems like a great feature, right?

Except now you’ve given end user the ability to access a live feed of a child over the internet. You need to think about how you’re going to secure that feature because if you just put a web server on the camera, Google will index it because Google indexes web servers. If someone knows how to do the search string, they can get all the babies in a single search.
Making this safe requires deliberate thought from an engineer.

Consumers and employees are starting to expect a seamless user experience tailored to their personal preferences, geographic location, and devices — all of which adds complexity engineering a flexible solution.

### Ease Satisfies End Users Need for a Positive Experience — and Security

As I mentioned during the Auth0 Security Meetup, I’m seeing a trend towards accountability from organizations and governments, but the driver of all that accountability is actually the end user.

Regulations like [GDPR](https://auth0.com/gdpr) give individuals the power to protect their personal data, while building in the expectation of swift breach notification.

Personal data protections are also under consideration in other countries.

While lawmakers may not always understand cybersecurity best practices, they do understand constituent expectations. A huge portion of a constituent’s life happens online — and they expect to be safe.

In situations where they aren’t protected, I expect consumers will start holding companies accountable. If governments fail to protect them, they will vote with their wallets.

<include src="TweetQuote" quoteText="Security industry experts weren’t entirely wrong when we first worried about the danger of ease. Easy can be risky if enough thought hasn’t gone into the user experience. @CloudCISO_Joan"/>

## Getting Expert Help with How

When you’re creating a new app, your main focus is largely on what your customers are going to do with it. How they get access can be an afterthought or something that can be viewed as easy, because setting up a database and making it talk to a login box can be done quickly.

It’s much harder to keep all that data safe.

One of the smartest things an engineer can do is to turn to someone who fends off hacks on a daily basis. Not a cryptography expert? Great. You’ve realized you shouldn’t waste your time on encryption.

Companies like GM have leveraged the skills of experts in transmission and tires and other products to create their now profitable cars. That same strategy can be effective in a digital situation. Apply your considerable skills to your product’s core and let expert third-parties (like Auth0) handle the authentication and authorization to help you create a safe and seamless end user experience.

<include src="asides/AboutAuth0" />


Security vs. Convenience

27396b3fa24389198ef5d3e7e410e9c4?size=60 avatar

27396b3fa24389198ef5d3e7e410e9c4?size=60

Former Auth0 Employee

Ricky Rauch

Our lessons in defining a cohesive design language <br /> across all our products.



For the past year, Auth0 has been growing at a fast pace and, naturally, so has the number of fronts that the Design Team has had to tackle.

In this post, we’ll explain what we've learned as we’ve implemented practices that help integrate design into our products, guarantee consistency, and optimize design choices.

![Auth0 design process](https://images.ctfassets.net/23aumh6u8s0i/5ekkYcvh13pEbE8iA9JwTi/105d9aae129b931385c61c0bf06f77fd/process)

## 1. Blueprints

The first practice we introduced was design from blueprints. A blueprint is just a monochrome draft of the final product, with as little focus on styling as possible.

![Design process blueprints](https://images.ctfassets.net/23aumh6u8s0i/5FuxxzraFKWNJlOWpEqNu8/7460f5608279a68310127f6904fe4263/blueprint)

We go through a lot of feedback from different company stakeholders, including engineers, marketers, analytics, and our own clients. By taking subjective factors like color and embellishment out of the process, blueprints help us get better feedback and achieve simpler solutions in a shorter length of time.

## 2. Frontend

### Asset production

We constantly review previous work when producing new assets to check for consistency and understand how they have evolved over time so we don’t repeat mistakes.

Our website is mapped out on a 1:1 scale with design files and is available to the whole team on Dropbox.

![Design process Dropbox usage](https://images.ctfassets.net/23aumh6u8s0i/1zAKxMtgDA21IoRLFBPvr9/c24b3209362d5ef65412e6f4fa91ddbd/dropbox)

Using Sketch has dramatically improved the way we create and export assets. We think it’s the best tool for the job because it was designed with the Web in mind.

### Mobile first

Most of the HTML and CSS at Auth0 it handled or refactored by a designer at some point. We’ve set [clear guidelines](https://github.com/auth0/code-conventions/blob/master/frontend/README.md) for front-end code, and we’ve chosen [Stylus](https://learnboost.github.io/stylus/) and [Jade](http://jade-lang.com/) to optimize our productivity. As a result, we write concise, clear code much faster.

Over the past year, we have started to migrate all of our pages as part of a mobile-first strategy.

The rationale behind this strategy starts with the design perspective: we set out to present only information that we can make available in a way that works on any device. This simplifies our approach to information architecture by getting rid of unnecessary elements and solving problems in the simplest way, which also reduces the potential for errors during development.

![Design process mobile first approach](https://images.ctfassets.net/23aumh6u8s0i/5g9IkjRDtYNOx42VQ8tdDj/cc277baee7dc60539557f462a3007177/mobile-first)

To maintain stability, we are making these changes progressively. Each page that gets a redesign gets a mobile-first refactor to go with it.

A key factor in preventing Responsive Design from getting messy was abstracting all of our media queries to a [Stylus mixin](https://github.com/auth0/styleguide/blob/master/lib/mixins/index.styl#L11) and keeping them as close as possible to their relevant selectors, making them harder to overlook and easier to maintain.

```css
.hero-cta
  color: blue;
  border-radius: 3px;
  padding: 10px 20px;
  max-width: 100%;

  +breakpoint("tablet")
    max-width: 620px;
    font-size: 18px;

  +breakpoint("desktop")
    max-width: 740px;
    font-size: 20px;
```
### Styleguide for consistency

Styleguide is one of our most important projects. Its aim is to help maintain the same look and feel across all of our products and to make our front-end code reusable, no matter the specifics of any project's codebase.

<a href="https://styleguide.auth0.com"><img src="https://images.ctfassets.net/23aumh6u8s0i/6MeGqjQoXZ6tRtmbTvBMEr/99c0ae67861c3baf3ad871b6bb4d095a/styleguide" class="expand" /></a>

Styleguide holds values, patterns, and specific components that repeat across pages, enabling designers and engineers quickly to reuse them on any product without worrying about markup or CSS.

![Design process consistency](https://images.ctfassets.net/23aumh6u8s0i/4sd8BnI6idcPWNOqsbZbGD/be684bd6cc03a3a2845bad9e670b4ff5/consistency)

- Elements like our [header](https://github.com/auth0/web-header), footer, and other components are easily maintained on different projects by sourcing them directly from [Styleguide](https://styleguide.auth0.com).

- By reducing complex html structures and patterns to Jade mixins available through [Styleguide](https://styleguide.auth0.com) and passing only content as parameters, we optimize development time.

![Design process icons](https://images.ctfassets.net/23aumh6u8s0i/4o7gHKzr7lrNkTwymz8Wh6/0c05df02c1c3ed39e6ce8bf653f003ab/icons)

- Company [colors](https://styleguide.auth0.com/#colors), [typography](https://styleguide.auth0.com/#typography), and [icons](https://styleguide.auth0.com/#icons) are kept consistent by using the same set of variables and files for every project.

- We use [semantic versioning](http://semver.org/) to enforce certain versions of Styleguide across projects. This helps maintain stability in our sites when we're doing heavy updates.

Today, we can include Styleguide using [Bower](http://bower.io/) or [Component](http://component.github.io/) or by linking [directly from the CDN](https://cdn.auth0.com/styleguide/latest/index.css).

If you are interested, [check the live version](https://styleguide.auth0.com) or [view the code on Github](https://github.com/auth0/styleguide).

## 3. Publish

### Deep testing

Once we reach the final step in producing a deliverable, we start a rough path of tests by using Heroku or Github pages as staging deployments. The whole point of this task is to have a last ride before publishing to the open when there is no take-back of the first impression statement.

Some of the things we review here:

Mobile rendering and response times on different real devices, browsers, and networks’ SEO optimizations (title on each page, description, sitemap…) and social sharing media elements like OpenGraph and Twitter Cards.

This method has always preceded the finest look and feel, in our experience.

![Design process cards](https://images.ctfassets.net/23aumh6u8s0i/6nqS5hbMqY2DJYVSHoBxq2/ddbb8f6d08b4fb9d91da159b8c793c45/cards)


And we’ll keep improving our test process to deliver no less than the best.

## Design meetings

Though we’re still a small group, there are already different kinds of designers on the team, some more adept in usability or visual design and some more focused on prototyping and code.

<blockquote class="instagram-media" data-instgrm-captioned data-instgrm-version="4" style=" background:#FFF; border:0; border-radius:3px; box-shadow:0 0 1px 0 rgba(0,0,0,0.5),0 1px 10px 0 rgba(0,0,0,0.15); margin: 1px; max-width:658px; padding:0; width:99.375%; width:-webkit-calc(100% - 2px); width:calc(100% - 2px);"><div style="padding:8px;"> <div style=" background:#F8F8F8; line-height:0; margin-top:40px; padding:50% 0; text-align:center; width:100%;"> <div style=" background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACwAAAAsCAMAAAApWqozAAAAGFBMVEUiIiI9PT0eHh4gIB4hIBkcHBwcHBwcHBydr+JQAAAACHRSTlMABA4YHyQsM5jtaMwAAADfSURBVDjL7ZVBEgMhCAQBAf//42xcNbpAqakcM0ftUmFAAIBE81IqBJdS3lS6zs3bIpB9WED3YYXFPmHRfT8sgyrCP1x8uEUxLMzNWElFOYCV6mHWWwMzdPEKHlhLw7NWJqkHc4uIZphavDzA2JPzUDsBZziNae2S6owH8xPmX8G7zzgKEOPUoYHvGz1TBCxMkd3kwNVbU0gKHkx+iZILf77IofhrY1nYFnB/lQPb79drWOyJVa/DAvg9B/rLB4cC+Nqgdz/TvBbBnr6GBReqn/nRmDgaQEej7WhonozjF+Y2I/fZou/qAAAAAElFTkSuQmCC); display:block; height:44px; margin:0 auto -44px; position:relative; top:-22px; width:44px;"></div></div> <p style=" margin:8px 0 0 0; padding:0 4px;"> <a href="https://instagram.com/p/2HXZopiTi7/" style=" color:#000; font-family:Arial,sans-serif; font-size:14px; font-style:normal; font-weight:normal; line-height:17px; text-decoration:none; word-wrap:break-word;" target="_top">Design Meeting @auth0</a></p> <p style=" color:#c9c8cd; font-family:Arial,sans-serif; font-size:14px; line-height:17px; margin-bottom:0; margin-top:8px; overflow:hidden; padding:8px 0 7px; text-align:center; text-overflow:ellipsis; white-space:nowrap;">A photo posted by Ricardo Rauch (@rickyrauch) on <time style=" font-family:Arial,sans-serif; font-size:14px; line-height:17px;" datetime="2015-04-30T22:01:28+00:00">Apr 30, 2015 at 3:01pm PDT</time></p></div></blockquote>
<script async defer src="//platform.instagram.com/en_US/embeds.js"></script>

We have established weekly design meetings as a simple “show and tell” exercise to feed off each other's work and be in the loop of what’s been going on during the week with other projects. This adds a big-picture perspective to all the work that's been done and complements daily feedback by showing the whole team the impact of design on our products.

![Design process sites](https://images.ctfassets.net/23aumh6u8s0i/n1DUnXF6UJuQEcWCVuE6H/5a471cd69e9cb94ad6f12041187e28ae/sites)

We’re always looking for ways to improve and optimize our process. We hope that some of our practices can prove useful for anyone interested in collaborating on product design, and if you have suggestions or thoughts, we’d be glad to hear them.

Finally, processes are nothing without a great team. I am humbled to work every day with these amazing people: [Victor Fernandez](http://twitter.com/vctrfrnndz), [Benjamin Flores](https://twitter.com/beneliflo_), and [Nicolás Garro](https://twitter.com/evilrabbit_)

If this sparked some interest, [we are hiring](https://auth0.com/careers).


"engineer"