DEV Community: Ramona Schwering

Let's Sketch Identity: Authentication vs. Authorization

Ramona Schwering — Wed, 24 Sep 2025 11:01:00 +0000

So, you are building an application and need a login form. In it, you’ll get the user's email and password, send them to an API, and... something happens. The user is logged in afterwards. But what is that something? How does your application decide who gets in and what they get to see?

This is the first article in a series called "Let's Sketch Identity." These blog posts will use my notes from when I started learning about identity concepts as a Developer Advocate. Think of them as my Identity Sketchbook, and join me on my journey back then! ❤️

In this series, I will show you the core ideas of modern identity using a simple, continuous story: no complex specifications, just clear, practical explanations for web developers. Today, I am starting with the two most important concepts: Authentication and Authorization. You can think of them as a Bouncer checking IDs at a door and a Clipboard listing your permissions.

What Is Authentication? The Bouncer Analogy

Do you know about the Persuadable Bouncer? It’s an exploitable four-panel comic series featuring a man in a suit blocking a door and allowing the entrance in the fourth panel. This is how I like to picture Authentication (and I just love to draw memes 😁). Okay, think of authentication like this: Authentication is the bouncer standing at the front door, e.g., of a venue. In real life, the venue is your application. To get in, you have to show your ID, which has your credentials.

Let's visualize this. In the first panel, we see our Bouncer blocking the door as a user presents their ID with their credentials. Once the Bouncer validates that ID, the lock clicks open, and as we see in the second panel, he finally opens the door.

And that’s it: You've been authenticated! The shorthand for this process is Authn.

At its core, authentication is proving that somebody or something is who they say they are. It's the lock on the door of your application. Talking about Authn in an Identity scenario usually means verifying credentials. These credentials come in all shapes and sizes; while a username and password combination is the classic example, they can also be a private and public key pair. Modern approaches even include passwordless authentication, which verifies a user’s identity with something other than a password, like a magic link sent to their email or a biometric trait like a fingerprint.

What Is Authorization? The Clipboard Analogy

Just because you are inside the room does not mean you can do whatever you want. This is where Authorization comes in, like the bouncer handing you a clipboard. Picture that clipboard as a checklist or ruleset explaining to you your permissions:

You see, the clipboard lists exactly what you are allowed to do. As you can see in the sketch, you might have permission to view rooms and make a guestbook entry, but the permission to change the AC settings is firmly crossed out. One crucial rule is that the bouncer will always check your ID before handing you the clipboard. You must first prove who you are before you can be given a list of things you can do.

My short take: Once a user enters the door, we must know what they can do. That's Authorization. Authorization checks whether somebody or something has access to a particular resource or is allowed to perform a specific action. The shorthand for Authorization is Authz.

How This Works in a Real-World Frontend Application

So, how does this story of the bouncer and the clipboard play out in a real web application? Let's walk through it.

A new user comes to your site and clicks on their "My Profile" link.
Your application’s bouncer stops them, sees they do not have a valid ID yet, and sends them to the login page.
The user provides their credentials (their ID). The system checks them and confirms their identity. Authentication is now successful.
Now that your application knows who the user is, it prepares their personal clipboard of permissions.
The user is sent to the "My Profile" page. They can see all their personal information, but the "Admin Panel" button is hidden. Why? Their clipboard says they do not have access to admin_panel permission. This is Authorization in action.

Understanding this difference is very important for you as a frontend developer, as it directly affects the UI you build daily. Some pseudo-codes show you how that logic might look inside a component. Does this look familiar to you?

// In some component that renders a navigation bar
function Navbar({ user }) {
  // The bouncer checks for an ID (Authentication)
  if (!user.isAuthenticated) {
    return <LoginButton />;
  }
  // If authenticated, the bouncer checks the clipboard (Authorization)
  return (
    <div>
      <WelcomeMessage user={user} />
      <ProfileLink />
      {/* Check the clipboard for a specific permission */}
      {user.hasPermission('access:admin_panel') &&
        <AdminPanelLink />
      }
      <LogoutButton />
    </div>
  );
}

However, no worries! This blog post will revolve around my sketch notes, so I have some prepared. Let’s take a look at this workflow:

You see, Authn and Authz are not the same thing. However, they belong together: Authentication is the first step (I’d even call it groundwork), so that Authz can take place. That makes sense, as you need to know your user before deciding on their permission, right?

But There Are Different Types of Clipboards!?

That simple .hasPermission('...') check in our code is powerful. However, it makes me think. How does the system decide on the user’s permissions in the first place? The bouncer's clipboard is not just a simple list. Let's take a quick look at the most common variations, as I depicted four types of clipboards in my sketches.

Role-Based Access Control (RBAC) assigns permissions to users based on their roles, such as “admin,” “editor,” or “viewer.” In the analogy I’m using in my sketches, this is like the “hat” the user wears. Instead of providing a single set of permissions, RBAC offers tailored permissions corresponding to each specific role.

Attribute-Based Access Control (ABAC) is an authorization model that determines access based on user attributes (or characteristics) rather than roles. It’s similar, but not the same as Policy-Based Access Control (PBAC): They are often considered the same, but are not. In our scene, these are the “tags” the user has on their conference badge, such as “Attendee”, “Speaker”, or the time when they check in. ABAC protects resources from unauthorized users and actions that do not align with the approved tags (which are basically attributes) established by an organization’s security policies.

Relationship-Based Access Control (ReBAC) handles access decisions based on a subject's relationships. Such a subject could be a user, device, or application. Or in our sketch, it’s visualized as a guest list, where only the family is added to. When a subject tries to access an event or a resource (in real life), the system evaluates the specific relationships tied to that subject to decide whether to grant access or not. In my analogy, it may look like this:

Last but not least, there’s Delegated Authorization. It allows a user to grant one application permission to access their data from another service, without sharing their password, just like someone presenting their ID and a document issued by someone else asking to let them enter the room on their behalf. The user would have to approve the access requested by the first party to be shared by the third party. This access is limited to the permissions that the user grants. For example, LinkedIn would only get access to our Gmail contacts, but not our inbox or calendar.

Conclusion

And that is it for my first sketch! The story is this straightforward:

Authentication (Authn) is the action done by the Bouncer: They check your ID to prove who you are.
Authorization (Authz) is the action of providing the Clipboard to the person, being the user. It lists what you can do once you are inside. And you can never get your clipboard until the bouncer has approved your ID.

Let's zoom out and look at the entire journey in a single picture to tie it all together. From the initial ID check by the Bouncer to the different kinds of Clipboards he uses, here is the full story from my Identity Sketchbook:

Great, your user is now authenticated and inside the application! ❤️ However, you might have already guessed, Identity does not stop here. How does the app remember them when they navigate from one page to another? They do not have to show their ID for every single click. How is their "clipboard" carried around with them?
In the next article, I will show you the answer: the Digital Passport, also known as the JSON Web Token (JWT). Stay tuned! 🔥

In the meantime, there's some interesting reads if you want to dive deeper:

Sketching AI Security: Identity and Security Challenges in AI Development

Ramona Schwering — Tue, 01 Jul 2025 17:09:43 +0000

Let's talk about AI. I know, it pops up everywhere, doesn't it? AI is a powerful tool, from helping us write code faster to building complex systems that handle critical business processes. Like any other tool, it introduces a complete set of challenges. Specifically, we must not forget about security when we develop with AI, especially when working with digital identities. Our identity and the identities of our users are our most precious data set, and they need to be protected. This is not just about protecting your users but also about securing the AI itself and the sensitive data it touches.

You might ask yourself: "What new identity challenges can AI introduce?" Or perhaps: "Are the old security practices still good enough?" The short answer is: No, not entirely. The AI landscape adds new layers of complexity, and we need to understand them to build truly robust and trustworthy systems. When we speak about AI development, we mean two main scenarios: either you are integrating AI features into existing, more traditional applications (think a chatbot in an e-commerce site, making it "AI-powered"), or you are building entirely new systems around AI agents that have greater autonomy and interact with many other services. Both scenarios bring unique demands to the table.

This is enough reason for me to educate myself and be prepared. I used to learn new concepts by drawing sketch notes, and with this article, I want to share them with you and invite you to learn about security in AI, too. Let’s sketch AI security! 🎨

New Faces, New IDs: Sketching the AI Identity Landscape

As a first step, I want to draw our environment. When you develop a traditional application, you primarily manage human identities: The users of your applications log in and grant them access based on who they are. Simple enough, right? However, with AI, things get a bit more interesting. We now have three main types of identities to consider:

Human Identities: These are still your users - developers interacting with AI tools, administrators managing AI models, or end-users consuming AI-powered features. The basics of strong authentication and authorization still apply here, but the attack surface might expand as AI tools become gateways to sensitive data.
Non-Human Identities: They are self-explanatory at first sight - all identities being non-human but still with a need to be secured. I would still distinguish them between “Machine identities” and “AI Agent Identities” because AIs are more "free spirits" than normal services and APIs. This means they are more like a robot with a brain, capable of making decisions. So, let’s zoom in:
- Machine Identities: Your backend services, CI/CD pipelines, and compute instances running AI models need identities to interact securely with other services. Think about your model training infrastructure or inference endpoints; they must authenticate to data sources and other APIs.
- AI Agent Identities: This is the truly new kid on the block! When you work with large language models (LLMs) or build multi-agent systems, these AI entities often need to act on behalf of users or other systems. They might access databases, send emails, or trigger other AI agents. How do you give an AI agent an identity? How do you control what it can do? This is a crucial area.

It is like adding more players to your team; each needs a clear name tag and specific permissions. If you fail to do this, you will have a security-free-for-all in your hands.

AI's Tricky Foes: A Sketched Look at New Security Risks

Next, as we know what to protect, let’s see what we’re up against. You already know about SQL injection, XSS, and all the "classic" web vulnerabilities. But AI brings its nasty surprises to the party.
The first source I love to look at is OWASP. OWASP (short for Open Web Application Security Project) is a volunteer project that helps us raise web security. They are most famous for their ranking of security risks, and along with this, they have rankings for the AI space too:

OWASP Machine Learning Security Top 10 lists the top 10 security issues of machine learning systems.
OWASP Top 10 for Large Language Model Applications reports the top 10 security issues for generative AI systems and applications.

Another organization focusing on AI security issues is MITRE, which has released ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems). ATLAS is a living knowledge base of adversary tactics and techniques against AI-enabled systems based on real-world attack observations. The NIST AI Risk Management Framework provides comprehensive guidance on managing AI risks throughout the lifecycle. Those resources draft a first picture of the biggest enemies we’re about to face.
Let's zoom in and examine some of your most critical new security challenges. This is like an expanded playground where new rules apply. This is how I envision, thus, draw them:

Prompt Injection: When Your AI Turns Against You

This is the most talked-about AI security vulnerability right now. Prompt injection happens when a malicious user crafts an input (a "prompt") that tricks an LLM into ignoring its original instructions or performing unintended actions.

Imagine an AI customer service bot that is supposed to give refunds. I would love to call it “social engineer the LLM” instead of the usual human being. A clever prompt could make it transfer money to the attacker instead. Or, consider an AI-assisted coding tool. A malicious prompt could introduce vulnerabilities into your code. It is like a puppet master pulling strings on your AI.

The challenge here is that the input is now code for the AI model. The line between data and instruction becomes very blurry. This is also how Credential Access often happens in AI applications; attackers use prompt injection to trick the AI into revealing credentials it has access to, or even to perform actions that expose them. Furthermore, Sensitive Information Disclosure can occur when an AI accidentally (or deliberately, via prompt injection) reveals private user data or confidential business information during its responses. How do you mitigate this? Input validation is a start, but it is not enough. You can consider techniques like instruction tuning, guardrails, and multi-stage prompts to sanitize inputs.

Insecure Plugin Design and Excessive Agency: Giving Your AI Too Much Power

This is a big one, especially with multi-agent systems and applications using external tools or plugins. What do I mean by “plugin” specifically? "You can extend the capabilities of an LLM by using plugins. Plugins are software components that are called by the LLM to perform specific tasks, such as calling an external service or accessing a resource. Basically, based on the interaction with the user, the LLM calls the plugin to perform some processing or retrieve data. Thus, we are using OWASP and MITRE terminology to define a plugin as a generic approach to extending the functionality of an LLM. Plugins can be implemented through specific LLM methods such as function_calls or tool_calls.

Insecure Plugin Design leads to vulnerabilities when these plugins are not correctly secured. Without the proper precautions, an attacker could exploit a plugin to perform unauthorized operations or access data they are not entitled to.

This can directly lead to Privilege Escalation, where an attacker gains higher permissions on your AI-powered application by exploiting a vulnerability, often through these insecure plugins or by exploiting the AI's Excessive Agency—meaning, the AI has more permissions than it actually needs. Imagine an AI agent with direct write access to your production database when it only needed read access to a specific table!
You must be very careful when designing and securing these interactions. It is about the AI's logic and the security around its tools. These vulnerabilities are clearly outlined in frameworks like the OWASP Top 10 for Large Language Model Applications, an excellent resource for deeper dives into AI security.

Data Poisoning: Corrupting the Source

AI models learn from data. What happens if that data is maliciously tampered with? This is data poisoning.

An attacker could inject insufficient data into your training sets, leading your AI model to learn incorrect, biased, or malicious behaviors. For example, poisoning a fraud detection model could cause it to miss certain types of fraud or flag legitimate transactions as fraudulent.
This is a supply chain attack on your AI model. To prevent this, you need robust data governance, strong access controls over your data pipelines, and rigorous data validation. Trust but verify, always! 🕵️‍♀️

Model Theft and Evasion Attacks

Your trained AI model is valuable intellectual property. Attackers might try to steal it or reverse-engineer its logic, which is model theft.

As an honorable mention, even if not mentioned in the sketch, evasion attacks are interesting in this scenario, too: They involve crafting inputs that cause a deployed AI model to make incorrect predictions without detection. For example, an attacker might modify an image slightly so that a facial recognition system fails to identify them.
In both cases, protecting your models involves secure deployment practices, API rate limiting, and potentially techniques like differential privacy during training to obscure model internals.

Building Bulletproof AI: Let's Draw Our Strategy

So, what can you do about all these new threats and identity complexities? It is not about throwing out your existing security practices but extending and adapting them for the AI age. This means a shift in mindset, putting identity and authorization at the core of your AI architecture, not as an afterthought. Let's break down a practical approach you can take to tackle these challenges and draw our sketches to build a first picture of a secure application.

Who Is Who?: Sketched Identity Management for All AI Players

First, consider a unified identity solution that can handle humans, machines, and AI agents.

This often means leveraging an Identity and Access Management (IAM) provider that supports various authentication methods (SSO, OAuth 2.0, mTLS) and fine-grained authorization. For the sake of completeness, this is the default way we handle non-AI identities:

For Human Users: Implement strong authentication (MFA!) and Role-Based Access Control (RBAC) to ensure users only access the AI tools and data they need.
For Machine-to-Machine Communication: Use client credentials, service accounts, or workload identities with the principle of least privilege. Machines should only have access to the specific resources required for their tasks.

This is where it gets interesting for AI agents. Treat AI agents like any other service and assign them unique machine identities.

Avoid giving your AI-powered application full power by default. Instead of providing an AI agent direct database access, make it go through a secure API that enforces its permissions. Here, a small but honorable nod to MCP is in order, which I’d cover in another article - or in this blog post, if you’re already interested. 🔥
- Let the application work on behalf of the user. When accessing sensitive data or performing actions, the application needs to act on behalf of the user, inheriting the user's permissions or, better yet, obtaining a delegation of those permissions, as is done with OAuth, for example. Implement an authorization layer specifically for your agents.

You can think of it like this: The AI agent asks for something, and your system checks if that agent is allowed to do that action for that specific user. To extend a little on that, it’s still important to keep the human in the loop as well, at least for high-risk operations or highly sensitive data. However, this is a topic for its own blog post, so I won’t go into details just now.

The Fortified Flow: Sketching Secure Data & Model Pipelines

Your data is the lifeline of your AI. Securing it end-to-end is non-negotiable: It shows up in rank 2 of the OWASP LLM top 10 and indirectly in rank 1, resulting from prompt injection, too. So, let’s sketch out the strategy for securing your data pipeline:

Secure Data Ingestion and Storage: Ensure all data used for training and inference is encrypted at rest and in transit. Implement strict access controls on your data lakes and databases. Make sure you are using only the data you actually need. If you specialize your application using fine-tuning or Retrieval Augmented Generation (RAG), be sure to provide only the minimum information you really need. If personal information is not needed, anonymize or delete it. This is a crucial step to prevent Sensitive Information Disclosure and reduce the attack surface.
Data Validation and Sanitization: Please always validate data rigorously before it is used for training. Look for anomalies, suspicious patterns, or potential signs of poisoning.
Training: Training is crucial and needs to be highlighted, see data poisoning.
Model Versioning and Auditing: Track every version of your model. Who trained it? What data was used? This provides an audit trail if a vulnerability is discovered later.
Secure Deployment: Deploy your AI models in isolated environments. Use containerization and orchestration platforms that provide built-in security features. Apply the principle of least privilege to your models' runtime environments. In my sketch notes, I depicted the protection of the data pipeline as seen below:

Blocking the Bad: Sketched Defenses Against AI Attacks

This is where you directly combat prompt injection, data poisoning, and model evasion.

Input Sanitization and Validation: While not a silver bullet, always validate and sanitize user inputs before they reach your LLMs or other AI models. Use allow-lists where possible. This is your first line of defense against prompt injection, which can lead to credential access or sensitive information disclosure.
Monitoring and Anomaly Detection inside your AI model: Monitor your AI systems closely. How do you think about monitoring for unusual behavior? If a model suddenly starts making wildly different predictions or consuming excessive resources, it could indicate an attack.
Instruction Tuning and Guardrails: For LLMs, reinforce desired behaviors through instruction tuning. Implement "guardrails", basically external mechanisms (could be another LLM, a rule-based system, or human review) that validate the AI's output before it reaches the end-user or triggers an action. This is like a bouncer for your AI's responses.
Output Validation: Always validate your AI's output. If an AI agent generates SQL queries, validate those queries before execution. If it produces code, scan that code for vulnerabilities. This helps prevent the AI from causing unintended consequences due to insecure outputs or even insecure plugin design. Imagine those steps as protective layers around the AI, building on one another. In a sketch, these direct defences would look like this:

One addition to note, which is important but didn’t fit the sketch: Please avoid using API keys to call external services. When an application uses an API key to access external functionality, such as an API, it exposes itself to potential security risks. This way, unauthorized users may send specific prompts and perform operations or access data they are not authorized to do. You can counter that: For example, you can use OAuth access tokens to restrict the application's permissions. This can reduce those risks significantly, as tokens can be scoped, short-lived, and tied to user context.

The big picture: Key Takeaways for AI Security

Developing with AI is exciting! 🔥 However, we cannot ignore the fact that AI introduces some challenges as well, especially for identity and security in general. By proactively managing identities for humans, machines, and AI agents, and by understanding and mitigating threats like prompt injection, data poisoning, sensitive information disclosure, and insecure plugin designs, you can build AI applications that are not only powerful but also incredibly secure. Let’s take a look at our result of the drawing, these are the full sketch notes:

Please keep it as a cheatsheet. And never forget: It is a journey, not a destination, so stay curious, keep learning, and make your AI bulletproof! As you probably know, I provided you with an overview in this article. While learning and crafting sketchnotes to document, I went into much more detail on any of these points. Are you interested in those sketch notes, too? Let me know, and I might turn this into a blog post series so we can sketch this journey together! ❤️

Your Sketchnote Kit: Essential Resources

Auth for GenAI by Auth0 ❤️
Samples, samples, samples on AI IRL 🔥
OWASP Top 10 for Large Language Model Applications
OWASP Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)
NIST AI Risk Management Framework
Auth0 Blog: Machine-to-Machine Authentication

Beyond the Lines: More to Explore

Angular vs. React vs. Vue

Ramona Schwering — Fri, 20 Dec 2024 16:00:00 +0000

Making decisions can be challenging, especially in our daily lives. As software engineers, we must make a crucial decision before working, whether on a side project or a larger scale: Which framework should we choose? This challenge is particularly daunting in JavaScript, with enough options to cause decision paralysis.

In this blog post, I will help you choose a framework by comparing the big three: Angular, React, and Vue. Prepare for an instructive comparison to evaluate how these frameworks measure up in creating practical, testable, secure, and high-performance web applications.

Let’s start with the following table as a TL;DR for everyone in a hurry:

Feature	Angular	React	Vue
Learning Curve	Steep	Moderate	Gentle
DOM Manipulation	Real DOM (=conventional)	Virtual DOM	Virtual DOM
Best for...	Large, complex enterprise apps	Flexible use, any size	Small to large apps, rapid prototyping
State Management	Services, NgRx	Redux, MobX, Context API	Vuex, Pinia
Built-in Security	Strong (XSS, CSRF, CSP)	Moderate (XSS)	Moderate (XSS)
Performance Optimization	AOT compilation, lazy loading	Virtual DOM, memorization	virtual DOM, Efficient reactivity system
Own Testing Tools	TestBed	React Testing Library	Vue Test Utils
Auth0 by Okta SDK	✅	✅	✅
MIT license	✅	✅	✅
Ecosystem Size	Large	Very Large	Growing
Update Frequency	Predictable (6-month cycle)	Frequent	Frequent
Used by	Google, Wix	Facebook, Uber	Alibaba, GitLab

Once Upon a Time in Framework Land…

Are you still with me? Great! Let’s dive into the details with a brief history lesson about Angular, React, and Vue.

In 2010, AngularJS started gaining attention for its ability to create dynamic web applications. In 2016, there was a significant shift with the release of Angular 2, leading developers to drop the original name “AngularJS.” Angular 2 and higher are now simply known as Angular.

React was first released in 2013 and stood out due to its component-based architecture and virtual DOM. Vue entered the scene in 2014 and gained momentum with the release of Version 1 in October 2015. It offers a progressive approach to web development. Evan You created Vue as a leaner alternative to Angular.

Let’s move on from history and focus on how these frameworks work in real-world situations today. Whether you’re building a small startup MVP or a complex enterprise application, by the end of this article, you’ll clearly understand which framework is best for your needs. As an Auth0 developer advocate and former test automation engineer, I can’t help but bring insights on security and quality considerations with me.

State of JS 2024: A Key Insight into Popularity Trends

Before we get into details, let’s first look at the popularity of these frameworks. My favorite indicator in this regard is the “State of JavaScript survey” survey. The collective Devographics conducts it annually, with the latest iteration at the end of 2024—published just a few days ago, when this blog post was released. 🔥

There is one particular survey question I’d like to take a look at:

Front-end Frameworks Ratios Over Time

I want to focus on the aspects of “usage,” “retention” and “positivity” because, in my opinion, they’re the best indicators of popularity. Here are the key points:

React: Still the leader with an 82% usage rate, and still some high stats with 75% retention rate, and 69% positivity score. It’s like the popular kid everyone wants to hang out with.
Vue.js: The emerging star, claiming second place with a 51% usage rate, surpassing Angular for the first time. People’s satisfaction is catching up immensely in 2024, too: With 75% in retention (rank #3 overall) and 70% in positivity (rank #2 overall), it's overtaking React for the first time.
Angular: Now in third place with a 50% usage rate, 54% retention rate, and 37% positivity score.

The StackOverflow Developer Survey polled approximately 65,000 developers worldwide, revealing that 62% have used JavaScript in the past year. When asked about the frameworks they worked with or plan to use within the next year, 39.5% mentioned React, 15.4% mentioned Vue, and 17.1% mentioned Angular.

These numbers indicate the increasing popularity of these frameworks. React remains the top choice among developers, while Vue is rapidly gaining ground. Angular’s popularity is declining, and while it is still in good shape, it needs to assert itself against the competition.

It’s important to note that popularity alone doesn’t determine a framework’s value. Although popularity serves as a guide, other factors are more crucial. Let’s delve into a comprehensive overview of these frameworks and their respective advantages and disadvantages.

Angular: A Large-scale Framework

Angular is a comprehensive TypeScript framework with built-in routing, state management, and form-handling support. It is developed using TypeScript, which provides static typing and advanced tooling. Angular features two-way data binding and a robust dependency injection system. Angular’s Command Line Interface (CLI) also simplifies development by providing project scaffolding and component generation features.

Pros	Limitations
Complete solution out of the box, so no more `npm install all-the-things`	There is a steep learning curve, so prepare for late nights and caffeine-fueled (coding) sessions
It is fairly "trustworthy" (so to say) because Google backs it	Project size: It can be overkill for more minor projects
Extensive documentation	Performance needs careful optimization in complex apps, as it can be impacted by their complexity and the size of applications

React: The Flexible Library

React is a popular developer choice (see the State of JS 2023 survey) due to its flexibility, efficiency, and robust ecosystem. It introduces a component-based architecture for creating UIs and a Virtual DOM for optimized rendering.

JSX allows for HTML-like code in JavaScript, while Hooks offers a way to manage state and side effects in functional components. These features make React code concise and easy to understand, solidifying its position as a top choice among developers.

Pros	Limitations
Highly flexible and easy to integrate, React usually plays well with others	Frequent updates can lead to breaking changes. You need to be prepared to keep up with that pace and to relearn new concepts introduced alongside it.
The reusable components, in particular, decrease complexity and help maintain the codebase	JSX must be clarified for beginners. Learning React alone is relatively easy, but being introduced to JSX might be on a different level.
Excellent performance with virtual DOM: React doesn’t rely on the conventional DOM structure, which increases the performance and speed of web applications
Massive ecosystem and community support

Vue: The Progressive Framework

Vue.js, also known as Vue, is widely recognized for its approachable and versatile nature, making it a popular choice for web development. It is considered a progressive framework, allowing for flexible adoption.

Vue is praised for its reactivity system, which enables smooth, dynamic interfaces. It also offers single-file components for organized code and utilizes a virtual DOM for optimized performance. Additionally, its powerful CLI facilitates easy project setup.

Finally, Vue is driven entirely by the open-source community, which sets it apart from its contenders and is evident in its vast numbers of watchers, stars, and forks on GitHub.

Pros	Limitations
Its gentle learning curve makes it a perfect choice for beginners and seasoned developers. It doesn’t require prior skills. For example, you can use TypeScript, but it’s not mandatory. The documentation is excellent	Their ecosystem: Despite growing fast, it’s still smaller than React and Angular.
It offers excellent out-of-the-box performance and provides advantages regardless of project size. Google appears to favor lightweight projects	It may be less suited for large-scale apps, but it’s catching up fast!
Vue is backed by an open-source community, not a corporation, which makes it independent and trustworthy	The statement “Any corporation does not back Vue” implies that its maintenance is less reliable than corporate funding. However, you can support their contributors through GitHub sponsoring.

Security: The Non-Negotiable Factor

When it comes to security, no framework is entirely secure by default. As a developer, you are the final line of defense. While frameworks can assist in making your applications secure, it is essential to remain vigilant, adhere to best practices such as OWASP’s recommendations, keep your dependencies current, and stay updated on CVEs and security news. With that in mind, let’s examine how each framework supports you in this effort.

Angular takes the lead with its robust built-in protections. It automatically sanitizes and escapes untrusted values, guarding against XSS attacks right out of the gate. Its HttpClient comes with CSRF protection and plays nice with the Content Security Policy (CSP).
React takes a more hands-off approach. It escapes values by default before rendering, which helps ward off XSS attacks, and its virtual DOM can act as an additional barrier. However, React leaves CSRF protection up to you and your backend setup.
Vue sits somewhere in the middle. Like React, it automatically escapes content to prevent XSS, and its compiler will warn you about potentially unsafe practices. But again, for CSRF protection, you’re on your own.

Remember, security isn’t a feature — it’s a fundamental requirement. Regardless of your chosen framework, always keep it at the forefront of your development process.

Let Auth0 Support You with Your App Security

I know you saw it coming. In this context, being on the Auth0 blog, I cannot resist doing the obligatory shoutout. Regardless of your chosen framework, Auth0 provides SDKs for all three frameworks, so you can significantly strengthen your security measures with Auth0 if you need a login, authentication, or authorization workflow.

Integrating Auth0 can significantly enhance your app’s security. Auth0 offers robust authentication and authorization features, simplifying the implementation of complex security elements such as multi-factor authentication (MFA), single sign-on (SSO), and even Passkeys that may be challenging to build from scratch.

Using Auth0 alongside your chosen framework is like having a dedicated team of security professionals protecting your app. Implementing our SDKs enables you to focus on creating excellent features while Auth0 keeps malicious users at bay. In short, it’s a win-win situation.

Testing: The Developer’s Safety Net

As a former test automation engineer, I want to bring the testing perspective into the discussion. A well-crafted testing strategy is crucial. In addition, testability and level of support are significant factors in choosing a framework. Let’s examine what testing utilities each framework offers.

Angular provides TestBed, which allows for the creation of isolated testing modules and simplifies mocking dependencies and testing components individually.
React offers a flexible testing approach with the React Testing Library, encouraging developers to test components as users interact.
Vue has Vue Test Utils, which balances Angular’s structured approach and React’s flexibility, enabling easy component mounting and interaction simulation.

Apart from that, there is a lot of common ground regarding testing. All three contenders support the testing tools that many of you use and love, whether it is Jest, Jasmine, and Mocha for unit testing or Cypress, Playwright, and — of course — Selenium for end-to-end testing, among others. A shallow learning curve will be ahead if you want to use these testing tools.

Best practices are the same for all frameworks. A well-rounded testing strategy includes unit, integration, and end-to-end tests. It’s essential to rely solely on unit tests. To learn more, you can read another article I wrote on choosing testing types. Our friends at Browserstack have also written a great article on how each framework performs with a strong focus on testing.

Summing Up the Similarities and Differences

You’ve now learned what each framework represents and which key feature it brings. Angular, React, and Vue are all designed to build dynamic, modern web applications, particularly single-page applications. They each use components to create reusable and modular user interface elements.
All three frameworks perform strongly through various optimization techniques, such as Angular’s ahead-of-time (AOT) compilation and React’s and Vue’s virtual DOM. Additionally, they all have large, active communities that offer extensive documentation, third-party libraries, and a wealth of online resources. Lastly, all three frameworks/libraries are open-source and licensed under the MIT license, allowing for freedom of use in both commercial and personal projects.

A Close-Up of the Differences

Regarding differences, you already found my short “TL;DR table” at the beginning of this article. Let’s take that table but fill it with life. I’ll add all the information from before, plus some I might have left out. For example, they all bring state management — only in different flavors. Let’s go:

Feature	Angular	React	Vue
Learning Curve	Due to its nature and focus on TypeScript, Angular has a steep learning curve. It’s most suitable for developers with experience in large-scale applications	There is a moderate learning curve. JSX and integrating additional libraries can present challenges, but once learned, React’s component-based approach is straightforward	Vue is easy for beginners with its gentle learning curve and precise documentation
DOM Manipulation	Utilizes the conventional DOM, which updates the entire DOM tree when changes occur	It uses the Virtual DOM, which optimizes performance by only updating the changed parts of the DOM	It also uses the Virtual DOM, offering performance benefits similar to React
Best for	It is ideal for large, complex enterprise applications where a full-featured framework is necessary	React is suitable for projects of any size that require flexibility and high performance. Its adaptability makes it a good fit for a wide range of applications	Due to its simplicity and easy integration, it is best suited for small to large applications and rapid prototyping
Performance Optimization	Performance is good but can be affected by its complexity and size	Offers strong performance through its virtual DOM and efficient rendering process	It is known for its efficient reactivity system and generally good performance
State Management	It uses services and NgRx for state management to provide a robust, reactive solution	External libraries such as Redux, MobX, and the Context API are commonly used for state management, providing flexibility in selecting the appropriate tool	ses Vuex or Pinia for state management, providing a structured and integrated approach
Built-in Security	It offers robust security features, including protection against XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), and CSP (Content Security Policy)	It provides moderate security with built-in protection against XSS but requires additional measures for complete security	Like React, it provides moderate protection against XSS and requires extra precautions for
Auth0 SDK	✅ Angular SDK	✅ React SDK	✅ Vue SDK
MIT Licensed	✅	✅	✅
Specific Testing Tools and Support	It comes with TestBed, a built-in testing framework	Often uses the React Testing Library or Jest, focusing on testing components in isolation	Provides Vue Test Utils for testing Vue components, offering a straightforward way to handle unit tests
Ecosystem Size	It boasts a comprehensive ecosystem, including a wide range of official tools and libraries to meet enterprise requirements	Its vast ecosystem includes numerous third-party libraries, which provides high flexibility but sometimes results in a fragmented toolset	Features a growing ecosystem with a solid set of official tools and an expanding range of community-contributed libraries
Update Frequency	It follows a predictable 6-month release cycle, guaranteeing regular updates and long-term stability	Frequent updates: Many updates underscore the ongoing development and constant enhancements	Like React, Frequent updates of Vue reflect their active development and continuous improvement

Conclusion: Choosing Your Companion

This all sounds like a lot of information. So, what should you do about it? If you’re like me, you might already feel the decision paralysis. I feel you; let’s try to bring this to a close and find out which framework is winning the comparison. Without further ado, this is my take on when to choose which framework:

If you’re working on a large-scale application, value consistency, and catch type-related bugs early, go with Angular because it supports TypeScript and its comprehensive framework.
React is a good choice when you need flexibility and your team is comfortable setting up its architecture and testing practices.
Vue is ideal if you prefer a gentle learning curve and need a framework that can grow with your project's complexity.

Lastly, please note that the best framework allows you and your team to write clean, testable, and secure code. Regardless of your choice, you will have a fantastic community to support you. ❤️