DEV Community: Robertino

February 2025 Updates: What's New in Auth0

Robertino — Wed, 12 Mar 2025 18:12:05 +0000

Original post published on Auth0 Blog. Written by Ana Cidre.

Discover the latest releases, updates, events, and all things developer-related from Auth0!

In the ever-evolving world of application development, managing identity is no small feat. But with the right tools, you can streamline your security and user management like never before. In this recap, we’ll dive into the latest updates from Auth0, showcasing how we’re enhancing your development experience with new features, integrations, and updates that bring both simplicity and power to the forefront.

Let’s explore the key updates you’ll want to know about and see how they can help you streamline your identity management, bolster security, and deliver more powerful, user-centric applications.

Updates You Don’t Want to Miss

Next.js SDK v4 (GA) Released

If you’re a Next.js developer, this update will significantly enhance your workflow. With Next.js SDK v4, now fully compatible with Next.js 15 and React 19, you can take advantage of cutting-edge features like:

Middleware-Based Authentication: A streamlined approach that makes authentication management easier and reduces maintenance.
Improved Security: Encrypted cookies replace outdated logic, bringing your app's security up to date.
Better Session Management: Features like rolling sessions and custom database support ensure a smoother user experience.

This update is designed to help you take full advantage of the latest web development advancements without sacrificing security or performance.

Advanced Customizations for Universal Login (Early Access)

For customers who want to take their Universal Login experience to the next level, we’ve launched Advanced Customizations for Universal Login (ACUL) in Early Access. ACUL enables you to create fully custom, client-rendered versions of each Universal Login screen. With ACUL, you get full control over every pixel of the login and signup screens.

Supported flows include Single Step Signup/Login, ID First Signup/Login with various authentication methods (password, passwordless, passkeys, etc.), and more.

This is just the beginning, with more features and a new configuration UI coming in the months ahead. Check out the online documentation for all the details, and start building today!

Okta Universal Logout Integration Now Supported in Auth0

For teams using Okta to manage their workforce identity, we’re rolling out Universal Logout integration with Auth0. This update means you no longer need to build a global token revocation endpoint. Instead, when Okta detects a change in risk, it will automatically revoke sessions and refresh tokens.

It’s a simple integration with minimal configuration, but the security benefits are huge, making it easier for you to ensure your applications are always up-to-date and protected.

Custom Token Exchange – Early Access

We’re thrilled to announce Custom Token Exchange in Early Access. This OAuth grant-type feature allows you to exchange security tokens for other tokens, such as access tokens and offers flexibility using Actions for custom logic.

This new feature enables advanced use cases like:

Migrating users to Auth0
Integrating external IDPs
Exchanging Auth0 tokens for different audiences

Custom Token Exchange provides the flexibility you need to handle sophisticated integrations where regular federation and OIDC flows aren’t feasible.

More cool features we have shipped to improve your experience:

Optimised TOTP Enrollment for Mobile Devices: We’ve made the process of enrolling in TOTP (Time-Based One-Time Password) on mobile devices more intuitive. Check out Auth0 Temporary OTP for more details!
Email OTP Verification – Email OTP(One Time Password) Verification: is now Generally Available (GA), providing an additional layer of security during signup and password reset. This feature requires Universal Login and can be enabled by changing the Verification Method from Verification Link to OTP in your connection settings.
Usage Metrics Dashboard for Auth0 FGA: We’re introducing the Usage Metrics Dashboard for Auth0 Fine-Grained Authorization (FGA). This new tool gives teams deep visibility into their authorization usage, enabling more efficient monitoring and management of monthly active users, total number of tuples, and monthly average requests per second.
New Private Cloud Region in India: We’ve expanded our Private Cloud availability by adding a new region in Hyderabad. This follows the Mumbai AWS region in India, providing additional flexibility, reduced latency, and improved data residency options for Auth0 customers in the region.

Deprecations

Node.js 12 and 16 Extensibility Runtimes Deprecation: We’re phasing out the Node.js 12 and 16 runtimes for extensibility integrations, such as Actions, Rules, Hooks, Custom Database Connections, and Custom Social Connections. If you’re using these runtimes, we strongly recommend migrating to Node.js 22, which is our recommended runtime for all new and existing extensibility integrations.

Unwarranted Session Removal After User Updates (Deprecated): In a bid to improve the user experience, we’ve deprecated the automatic invalidation of user sessions when performing database connection user updates with unchanged email or email_verified attributes. This change will ensure that the session invalidation behavior aligns more closely with the email verification flows.

Community and Events

Partnering with LangChain and LlamaIndex

As Generative AI (GenAI) applications become more powerful, securing these systems becomes essential. The "Auth for GenAI" initiative is here to help developers integrate strong authentication and authorization into their GenAI applications, ensuring sensitive data is protected when interacting with external APIs and data sources.

We’re thrilled to announce our partnerships with LangChain and LlamaIndex—two leading frameworks in the GenAI space. Together, we’re demonstrating how Auth0 can seamlessly integrate with these tools to secure your AI applications.

Key aspects of our collaboration include:

Framework-Specific SDKs to simplify the integration of Auth0’s authentication and authorization solutions.
Informative Developer Content that offers best practices, guides, and examples for secure GenAI app development.
Fine-Grained Access Control using Auth0 FGA (Fine-Grained Authorization), which ensures that AI applications can securely access external data sources and APIs.

This partnership is a great step toward building secure, scalable, and compliant AI applications. We’re excited to collaborate with LangChain and LlamaIndex, and provide developers with the tools and resources they need to build the next generation of secure AI-powered systems.

Together, we’re building the future of secure Generative AI. Let’s innovate and secure the AI applications of tomorrow!

Events

At Auth0, we’re passionate about engaging with the developer community and sharing insights at events worldwide. Whether we’re speaking at conferences, hosting workshops, or simply connecting with like-minded developers, we’re excited to be part of the conversations shaping the future of identity and security. Here’s a look at where we’ve been recently and where you can catch us next!

Where Were We?

In the past few weeks, we’ve had the privilege of attending some amazing events and meeting incredible developers:

JFokus – February 3-6
Developer Week – February 11-13
DevWorld Amsterdam – February 27-28

It’s been a blast connecting with the community, and if you joined us at any of these events, we hope you had a chance to chat with the team and explore what’s new with Auth0.

Looking ahead, we’ve got a busy schedule and can’t wait to meet more of you at these upcoming events:

All Things Open AI – March 17-18
Tech.eu Summit – March 25-26

Make sure to swing by our booth if you’ll be at any of these events, we’d love to talk all things identity, security, and the future of AI-powered applications!

That’s all for this month! We’re committed to keeping you updated with the latest and greatest features to help you build secure, scalable applications. Stay tuned for more in March!

The Power of Parquet

Robertino — Tue, 28 Jan 2025 13:09:04 +0000

Learn about what Parquet is and how its columnar storage and encoding techniques can help you.

Original post written by Jon Carl, Staff Software Engineer at Auth0.

Imagine you are tasked with choosing how to store a large analytical data set that needs to be easily queryable. Billions of rows with over 75 columns. What would you come up with?

Maybe you reach for a popular cloud database technology such as Amazon RedShift, Snowflake, or Google Cloud SQL. Maybe you think Microsoft Access is all you need. Maybe you decide the tried and true PostgreSQL is the best fit. Or maybe you opt for any of the other hundreds of databases out there.

Someone made the decision for you: each row will be a JSON object on a line in a gzipped file. Some files will have many lines and others will have few lines. To query the data you’ll need to use something that can scan many of these files and read all of the JSON. You still have some part in the decision by choosing what to use for querying. You settle on Amazon Athena which is built on top of Apache Presto and allows you to query the data using SQL.

You like the SQL interface, but using gzipped JSON files as the underlying storage is not exactly fast. If you could change the format, what would you choose?

At Auth0 we recently transitioned our edge logs from gzipped JSON to a format called Parquet. A little background on our data set: the network edge of Auth0 processes over 60 billion requests a month. The logs for these requests arrive from our edge networking partner in gzipped JSON files and is roughly 1 TB of data a day.

What is Parquet?

At its core, Apache Parquet is a file format which stores data in columns instead of rows. A parquet file is not meant to be read completely from beginning to end. Instead there is metadata at the end of the file which contains information that a reader can use to selectively read portions of the file they are interested in. The less data you have to read, the quicker your reading can be.

Example

Let’s look at an example: I want to calculate the 90th percentile of the request duration column in the data set.

JSON

With JSON, the query engine has to read each file in its entirety. For each row it has to read the JSON object at least until it finds the request duration column. Or maybe it has to read the entire JSON object before picking the column out. (This isn’t a JSON parsing blog post, so we won’t investigate further.)

Parquet

With Parquet, the query engine reads the metadata in each file. From there, the engine learns where the column values are stored in the file and reads only that data. This is not only faster than reading the entire file, it’s also cheaper in Athena which bills by bytes scanned.

You could also have Parquet store metadata in one file and reference multiple other files for column locations.

Encoding

Let’s look deeper at how Parquet uses different encoding techniques to make reads efficient.

Dictionary Encoding

When a column has many of the same values, a dictionary can be built and used to refer to those values. We have a status code column in our logs which refers to the status code returned to the client. Status codes are well known and fit well in a dictionary. The distinct values in the column are assigned an index and then that index is used to refer to the values.

When reading a column there is less to read, and when compressing the data there is less data. Thus, a higher level of compression is achieved. But dictionary encoding does not always make sense; if a column has high cardinality for example, it would not gain much from dictionary encoding.

Run Length Encoding (RLE)

Another option is Run Length Encoding (RLE), which can further reduce the size of the column. While dictionary encoding tackles distinct values, RLE tackles consecutive repeated values. When a column has consecutive repeated values, the number of repetitions is encoded followed by the value being repeated. The same status code example can be used here: across hundreds and thousands of rows, the status codes have low cardinality and thus consecutive repeated values are common.

As with dictionary encoding, this means less to read and high compression. RLE is also normally combined with dictionary encoding as they complement each other well.

Delta Encoding

The last encoding we will look at is delta encoding, which stores the deltas between consecutive values instead of their full form. We have a duration column which stores the duration of a request in milliseconds. Delta encoding would take the full value of the first item, and then every value after that would be the delta.

The smaller the deltas, the more effective delta encoding. Another example for delta encoding would be timestamps stored as millisecond precision 64-bit values. We have multiple requests coming per second, and would have a relatively small delta between values.

How Can You Get Started With Parquet?

As you can see, Parquet is much more than a format which stores data in columns with metadata. The way it encodes each column, how it uses types to store data more efficiently, or how it handles repeated values are all examples of how purposefully Parquet has been built. There was a lot of thought put into Parquet, and moving to it from JSON was amazing.

Parquet sounds great, and there are some really cool features to nerd out on, but how can you start using it today? The good news is you don’t need to know all of its inner workings. You don’t need to choose encodings, get into the nitty gritty of how columns are packaged and stored, or have a beefy fleet of DB machines. We started exploring Parquet using DuckDB and grew from there. We had a data set we would run multiple queries on and it was faster for us to first convert it to Parquet and then query it instead of continually querying JSON. For an example dataset it’s as simple as starting DuckDB in your command line and loading an example dataset:

COPY(
  SELECT * FROM
  read_json('https://github.com/grounded042/airports-dataset/raw/226a54bb19535ea8c5e6175a591446e67c4ab44c/airports.json')
) TO 'airports.parquet' (FORMAT PARQUET, COMPRESSION ZSTD);

To see the 20 countries with the most airports, you can use the following query:

SELECT COUNT(*) as count, iso_country FROM 'airports.parquet' GROUP BY iso_country ORDER BY count DESC LIMIT 20;

┌───────┬─────────────┐
│ count │ iso_country │
│ int64 │   varchar   │
├───────┼─────────────┤
│ 31567 │ US          │
│  7206 │ BR          │
│  3563 │ JP          │
│  3126 │ CA          │
│  2677 │ AU          │
│  2594 │ MX          │
│  1683 │ RU          │
│  1656 │ FR          │
│  1452 │ GB          │
│  1402 │ KR          │
│  1335 │ DE          │
│   942 │ AR          │
│   918 │ IT          │
│   731 │ CO          │
│   726 │ PH          │
│   713 │ CN          │
│   652 │ ZA          │
│   632 │ PG          │
│   625 │ IN          │
│   617 │ ID          │
├───────┴─────────────┤
│ 20 rows   2 columns │
└─────────────────────┘

Start small with your own JSON data and grow as needed. For us we grew into a Lambda which converts files as they land in S3, but we wouldn’t have gotten there without first exploring things via DuckDB.

To take things further, DuckDB has a great blog post which gives you first hand experience with Parquet: https://duckdb.org/2021/06/25/querying-parquet.html

What Are Modern Access Controls and How Are They Implemented?

Robertino — Mon, 27 Jan 2025 19:03:35 +0000

Original post written by Steve Jarvis, Principal Engineer at Auth0.

Examining the importance of access controls, models for authorization, and how to implement these core components of security.

What are Access Controls?

Access controls are the mechanisms that manage access to resources. To determine whether someone (or something, like another computer) has access to a resource, an access control system really needs to know two things: 1) who they are, and 2) what they’re allowed to do. These two verifications are generally separate considerations, namely authentication and authorization.

Access controls in the digital world are similar to those in the physical world. For example, before you board an airplane, someone at the airport verifies your identity by examining your passport (authentication) and boarding pass, which demonstrates your permission to be on the plane (authorization).

How Modern Access Control Works

Physical security is important, but for the rest of this article, we’ll focus on digital security.

Authentication

Before a system can make any decisions on access, it must verify a user’s identity. This verification often relies on an identity provider (IdP) that handles the process of authentication. Upon successful authentication, the IdP ultimately issues an assertion of the user’s identity.

For heightened security, there may be additional factors evaluated by the IdP during authentication, like geographic location, device characteristics, whether the request originates from a trusted network, or a second factor presented by the user.

With the help of a dedicated IdP, the application doesn’t need to worry about any of the authentication details, including the enforcement of multiple factors (MFA). The applications let the IdP do all the work and simply verify the final assertion—typically SAML or a JWT—to know the identity has been verified.

Authorization

Once a user’s identity is established, the access control system evaluates what that user can or cannot do. This can be modeled with different types of access controls, but best practices today include role-based access control (RBAC), attribute-based access control (ABAC), and relationship-based access control (ReBAC). One thing all mature models have in common is a way to enforce least privilege, the set of permissions that allows the user to do what they need to do, but nothing more.

RBAC

RBAC assigns users to roles and roles to resource permissions. The system starts out simple and easy to establish, but as a system grows in scale and complexity, maintaining the right role assignments and permissions becomes more challenging.

This is because, as resources and levels of privilege are added to the model, an organization is faced with difficult tradeoffs between an explosion in the number of roles and assignments on one hand and too few, coarse, overly-permissive roles on the other.

ABAC

ABAC can be thought of as the next step beyond RBAC, once an organization has outgrown role-based access. In ABAC, all users and resources in the system are assigned attributes, and a set of rules defines the authorization policies between those attributes.

Defining attributes and the rules evaluating them requires a greater initial investment, but once established it can grow efficiently. Incorporating additional resources or new sets of permissions involves simply adding new attributes and rules, without the direct couplings that exist from user to role and role to resource, as in RBAC. That’s not to imply this growth is without challenges of its own, though, as correlating users, resources, and their attributes often requires data from multiple sources, and there still is overhead to manage the attributes.

ReBAC

ReBAC is authorization based on the relationships between a user, a resource, and that resource’s relationship to other resources. You can think of ReBAC as a superset of both RBAC and ABAC (as long as the attributes can be expressed as relationships), as you can also implement both in ReBAC.

ReBAC is an extremely powerful model, offering great granularity of control, but that granularity often comes at the cost of maintaining many objects and rules, as well as needing to do frequent authorization checks, which can result in a frustratingly slow user experience. Okta’s Fine Grained Authorization (FGA) addresses these challenges by making authorization changes fully programmable and scaling seamlessly to ensure low-latency, even at tens of thousands of authorizations per second across millions of resources.

Why Implement Access Controls?

Access controls are how we can ensure that only the right people have the expected access to protected resources. They’re the means to knowing who is allowed to perform which actions on what resources, with the end of knowing that your customer data, sensitive systems, and intellectual property are secure. Malicious actors are an ever-lurking threat in today’s world, constantly watching for opportunities to gain access to other systems. Strong access controls not only minimize the possibility that an untrusted, ill-intentioned user gains access, they also offer preparedness if such an event does happen. Additionally, access controls provide guardrails to help your employees and customers work confidently, demonstrate adherence to critical compliance frameworks, and the ability to respond efficiently in an audit.

Limit the Likelihood and Impact of Malicious Actors

In some of the worst cases, an untrusted user could gain access to the system. How do access controls help if a malicious user finds a foothold? Whether via a software vulnerability or a session takeover of a trusted user, the malicious user ends up operating behind some other identity in the system, with all the rights and privileges they have granted. The more tightly the authorization controls map to a minimal set of permissions, the greater chance the malicious user’s impact is also minimal.

Limit the Scope of Innocent Mistakes

It’s not all about blocking malicious use, though. We’ve probably all experienced a moment of panic when we’ve accidentally deleted a document, hit “send” on an email before we meant to, or had a cat jump on the keyboard while you were writing a DM to your boss. Without a mature access model focused on enforcing the least amount of privilege required, there’s the unnecessary risk that such an innocent mistake has an outsized impact.

Compliance and Audit

Many compliance frameworks include provisions about how to maintain access to resources. It’s important to demonstrate that access to resources is well-controlled, documented, and adheres to principles of least privilege.

Since our world is always changing, it’s also common to need regular updates to a system’s users and resources. A well-designed model can pay dividends in efficiency and accuracy in the long term, as additions, deletions, and changes need to be continually applied.

Implement Access Controls Now

A modern access control model is paramount for a modern business’ security, efficiency, and trustworthiness. The factors to consider in authentication and the ideal authorization model will vary for different organizations, but the need to implement a system that can grow and evolve is universal.

Okta can help establish mature access controls for your customers and workforce. If you’re building an access control solution for your workforce or business partners, learn more at Workforce Identity. If you’re building access controls for your customers, learn more at Customer Identity.

FAQ

Can Okta provide industry-leading ReBAC?
A: Check out Okta Fine Grained Authorization

Can Okta Workforce do both RBAC and ABAC?
A: Yes, it can.

Can these access models be maintained as infrastructure as code
A: Workforce Identity Cloud and Customer Identity Cloud offer Terraform providers:

What about the other authorization models, like Hierarchical, Discretionary Access Control, and Mandatory Access Control?
A: These models may work well in some contexts (for example, Mandatory Access Control is very popular in government environments). But for most use cases, they end up not meeting the principle of least privilege (with either too much or too little access permitted), being too complex to maintain, or are supplemental to one of the above primary models.

If you want to learn more about Access Control, just continue reading the post on the Auth0 Blog.

Test Authorization in ASP.NET Core Web APIs With the `user-jwts` Tool

Robertino — Fri, 23 Dec 2022 14:20:25 +0000

Original post written by Andrea Chiarelli for Auth0 Blog.

How to use the new user-jwts tool to test a protected ASP.NET Core Web API without involving an authorization server.

Testing a protected Web API is not an easy task. At the very least, you need to configure an authorization server, such as your Auth0 tenant, configure your app, and get specific access tokens for your authorization scenarios. This implies several back and forths between your development environment and the Auth0 dashboard (or any other authorization server backend), which may be time-consuming, error-prone, and require an Internet connection, of course. The user-jwts tool, included with the .NET CLI version 7.0, simplifies this Web API testing approach.

Meet the `user-jwts` Tool

The user-jwts tool allows you to generate tokens customized for your needs and test your ASP.NET Core Web API without the need for a real authorization server. It's a CLI tool integrated with the .NET CLI starting from version 7.0 of the .NET SDK, so make sure you have this version installed on your machine.

The tool simplifies the interactive testing process of your protected API. Its general syntax is as follows:

dotnet user-jwts [options] [command]

You can pass commands to the tool to specify how to manage your JWT tokens and options to work with projects or solutions. In the following sections, you will learn the main commands you may need for testing your ASP.NET Core Web API. For a complete reference to the commands and options available, check out the official documentation.

Set Up Your Project

You will learn how to use the user-jwts tool with a practical approach by testing a ready-to-use ASP.NET Core Web API. Download it by running the following command in a terminal window:

git clone https://github.com/auth0-blog/glossary-aspnet-core-webapi

You will find the project in the glossary-aspnet-core-webapi folder. Go to that folder and run the application with the following command:

dotnet run

Then, point your browser to the https://localhost:5001/swagger URL. You should get the following page:

The Web API provides a few endpoints that allow you to manage a glossary of terms. This is a slightly modified application coming from this article about using permissions with ASP.NET Core Web APIs.

You can perform the typical CRUD (Create, Retrieve, Update, Delete) operations on a list of term definitions. The endpoints are protected, and each operation requires an access token with different permissions:

The GET method on the /api/Glossary and the /api/Glossary/{term} endpoints requires an access token, but it doesn't care about specific permissions.
The POST and PUT methods on the /api/Glossary endpoint require an access token with create:term and update:term permissions.
The DELETE method on the /api/Glossary/{term} endpoint requires an access token with delete:term permission.

The ASP.NET Core Web API application provides a Web UI for interacting with it, but in this article, we will use curl to make HTTP requests just to be consistent with the CLI nature of the user-jwts tool. Feel free to use the tool you prefer to make your HTTP requests.

If you try to call these endpoints without an access token, you will get an "unauthorized" response message. For example, assume you call the /api/Glossary endpoint as follows:

curl -i https://localhost:5001/api/glossary

You will get the following error message as a response:

HTTP/1.1 401 Unauthorized
Content-Length: 0
Date: Mon, 05 Dec 2022 09:28:37 GMT
Server: Kestrel
WWW-Authenticate: Bearer

This message tells you that you are not authorized to call that endpoint, and you must pass a bearer token as a credential (WWW-Authenticate: Bearer).

You can read this article to learn more about the different HTTP response messages you can receive from a protected web API.

How We Do Releases in Auth0’s New Private Platform

Robertino — Thu, 22 Dec 2022 19:58:43 +0000

Original post written by Cyril David for Auth0 Blog.

TL;DR: Releasing individual services today is largely a solved problem. The complexity arises when we need to factor in the combinations of services, the configs and secrets necessary for a given service version, and the underlying infrastructure supporting those services while ensuring quality, reproducibility, and determinism.

What’s in a Service?

When we talk about services, we largely focus on the code — but other things we might need to account for are:

Config and Secrets
Database related migrations
Related infrastructure dependencies for a particular service version
Implicit dependencies with other services

Introducing the Concept of a Release Manifest

Given these problem constraints, we introduced a release manifest concept, which we define as a versioned JSON file describing a point-in-time representation of the entire Auth0 product stack, which includes: all service versions and the infrastructure version it was deployed on.

Configs and secrets are also versioned for every release manifest, which are snapshotted in our config/secrets storage.

Just to make it more concrete, here’s a hypothetical snippet:

{
    "version": "v202221.99.0",
    "services": {
        "productpage": {
            "entity": {
                "name": "productpage",
                "default_vcs_branch": "main",
                "stacks": ["STACK_AUTH0"]
            },
            "artifact": {
                "version": "1.464.0",
                "vcs_revision": "dc62808d3a75a814a0748827d74e0936669dfec9",
                "vcs_url": "https://github.com/auth0/productpage",
                "reference": "sample.jfrog.io/docker/productpage:1.464.0",
                "metadata": {
                    "build_number": "464",
                    "build_started": "2022-05-24T18:52:34.753+0000",
                    "build_url": "https://samplebuilds.auth0.net/job/productpage/job/main/464/"
                }
            }
        },
        "reviews": {
            "entity": {
                "name": "reviews",
                "default_vcs_branch": "main",
                "stacks": ["STACK_AUTH0"]
            },
            "artifact": {
                "version": "1.31.0",
                "vcs_revision": "dc62808d3a75a814a0748827d74e0936669dfec9",
                "vcs_url": "https://github.com/auth0/reviews",
                "reference": "sample.jfrog.io/docker/reviews:1.31.0",
                "metadata": {
                    "build_number": "31",
                    "build_started": "2022-05-24T18:52:34.753+0000",
                    "build_url": "https://samplebuilds.auth0.net/job/reviews/job/main/31/"
                }
            }
        }
    }
}

A couple of notes:

The version v202221.99.0 is based on a year/week scheme (e.g., year2022, week 21) and just a monotonic minor version which represents an atomic change.
In this example, we only have two services called productpage (versioned 1.464.0) and reviews (versioned 1.31.0).
This file is committed within our central git ops repository, with a matching tag v202221.99.0 where the underlying infrastructure as code is also versioned for that specific point in time.
Config/secrets aren’t versioned in git — but instead are stored separately in our config/secrets storage where we have the ability to snapshot them based on a specific version (in this case, all secrets/config have the same version v202221.99.0attached as metadata).

With this construct defined, we now have a baseline primitive for ensuring the properties we set out to solve initially:

Quality — we can easily run our suites of system tests against a given version to ensure that our features work as expected.
Reproducibility — we can create as many different spaces for testing or for onboarding new customers.
Determinism — we’re guaranteed we have the same combination of service versions, config/secrets, database migrations, and infrastructure.

A Better Social Login: Transparency That Leads To Trust

Robertino — Mon, 19 Dec 2022 21:31:59 +0000

Original post written by Swalé Nunez for Auth0 Blog.

A Better Social Login: Transparency That Leads To Trust

Social logins have given developers an effortless way to address several of their onboarding challenges. With a simple integration that lets users sign up and sign in to applications using social accounts, developers remove considerable friction from the process. Auth0 eased the integration process further, letting developers choose which social login provider to use. The most prevalent, Facebook, was generally the default. That integration alone not only helped eliminate password management but also showed increases in conversion rates and overall user engagement. But removing friction and easing a developer’s job is just the first part of this journey. It’s also about user trust.

A Question of Trust

There has always been an element of trust involved in the social login relationship. But it’s changing. As the relationship between users and the applications they interact with has evolved, user expectations of that relationship have shifted as well. And trust is at the core of these expectations. A study by MalwareBytes Labs found that 95% of internet users don’t trust social media companies with their personal data. Those who responded to the survey showed distrust across all social media platforms. The same research found that 87% of respondents didn’t feel confident sharing their personal data online. The lack of user confidence and distrust is becoming evident in how often they make use of social logins today.

With users becoming more informed about data privacy and the need to become more active in protecting their online identity, they expect a privacy-first login that will give them more control over and transparency in their data. A report from PEW Research Center on Americans and their online privacy found that 84% of users stated they have little to no control over the data companies collect about them. As technology evolves and with the advent of blockchain technology, users are embracing the idea of having more control over their online identities, data, and transactions, and technology is evolving to help make this possible. Decentralized identity is one such approach.

A User-First Approach to Online Identity

Iuncta’s user-first approach to identity and access management is built on a model emphasizing transparency that leads to trust. It prioritizes user privacy and enables user control, all consistent with its user-centered design approach. Iuncta is a social login with transparent data sharing and access to zero-party data, so users are always aware of what data is being shared, when, and with whom. A social login that gives users the control they deserve, ensuring trust, offering privacy, and establishing peace of mind.

Iuncta’s decentralized identity implementation allows users to act as their own identity provider online, introducing a more transparent profile-data-sharing model. With its hybrid architecture, developers can quickly and easily offer enterprise-grade passwordless authentication with an intuitive consumer-ready experience that is supported by Iuncta’s mobile app. The Iuncta platform enables user identity on demand, streamlining onboarding and facilitating secure and effortless digital interactions between users and developers.

End-to-end authentication

The Iuncta solution manages the relationship between the developers and the users of their applications and is supported by a feature-rich cloud offering at the core of an end-to-end solution to consumer online identity management and licensing.

The key elements in Iuncta’s layered implementation include:

Developers (Client) – A minimalist module requires only a username for passwordless access.
Web API/Mobile SDK – A comprehensive list of tools for seamless integration into the Iuncta cloud service offering.
Cloud services – A feature-rich collection of core Iuncta ecosystem services. It is the control center for the extensive functionality list.
Mobile app – A clean and intuitive user interface designed to make user interaction with the Iuncta platform natural and effortless.

Iuncta’s hybrid approach combines a consumer-friendly user experience with enterprise-grade security without lengthy development time. As an official Auth0 partner in its Marketplace, the integration only takes a button click and a few simple steps for developers. With an Iuncta partner account, developers get access to the complete list of web APIs and downloadable mobile SDKs, as well as a reference guide with documentation and code samples to enable customization.

Shhhh... Kubernetes Secrets Are Not Really Secret!

Robertino — Fri, 16 Dec 2022 13:19:17 +0000

Original post written by Deepu K Sasidharan for Auth0 Blog.

Learn how to setup secure secrets on Kubernetes using Sealed Secrets, External Secrets Operator, and Secrets Store CSI driver.

Kubernetes has become an inevitable part of the modern software infrastructure. Hence managing sensitive data on Kubernetes is also an essential aspect of modern software engineering so that you can put the security back into DevSecOps. Kubernetes offers a way to store sensitive data using the Secret object. While it's better than nothing, it is not really a secret, as it is just base64 encoded strings that anyone with access to the cluster or the code can decode.

Caution:
Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. Additionally, anyone authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access, such as the ability to create a Deployment.
— Kubernetes docs

The problem of reading secrets from the cluster can be fixed using proper RBAC configuration and by securing the API server, check out How to Secure Your Kubernetes Clusters With Best Practices to learn more about RBAC and cluster API security. Securing secrets on the source code is the bigger problem. Everyone who has access to the repositories containing those secret definitions can also decode them. This makes it quite tricky to manage Kubernetes secrets in Git, like every other resource.

Let's see how to setup more secure secrets using the;

Sealed Secrets,
External Secrets Operator,
Secrets Store CSI driver.

You would need a Kubernetes cluster to run the samples. I used k3d to create a local cluster. You can also use kind or minikube for this purpose.

Sealed Secrets

Sealed Secrets is an open-source Kubernetes controller and a client-side CLI tool from Bitnami that aims to solve the "storing secrets in Git" part of the problem, using asymmetric crypto encryption. Sealed Secrets with an RBAC configuration preventing non-admins from reading secrets is an excellent solution for the entire problem.

It works as below;

Encrypt the secret on the developer machine using a public key and the kubeseal CLI. This encodes the encrypted secret into a Kubernetes Custom Resource Definition (CRD)
Deploy the CRD to the target cluster
The Sealed Secret controller decrypts the secret using a private key on the target cluster to produce a standard Kubernetes secret.

The private key is only available to the Sealed Secrets controller on the cluster, and the public key is available to the developers. This way, only the cluster can decrypt the secrets, and the developers can only encrypt them.

Get Started with Jetpack Compose Authentication

Robertino — Wed, 14 Dec 2022 21:25:46 +0000

Original post written by Joey deVilla for Auth0 Blog.

Learn how to build a basic app using Android’s Jetpack Compose UI toolkit.

With nearly 3 billion users, almost 70% of the mobile OS market share, and the majority share of all user-facing operating systems worldwide, Android is the number one operating system in use today. As an Android developer, you have access to the world’s largest customer base, and sooner or later, you’ll write an app that requires the user to log in and out. One of the goals of this tutorial is to show you how to use Auth0 to add authentication to an Android app. You’ll also become familiar with the Auth0 dashboard and learn how to use it to register applications and manage users.

Platforms evolve, and Android is no exception. However, when a platform the size of Android fundamentally changes how you do things, developers who embrace the change early gain a significant advantage. This change is happening now with Jetpack Compose. This tutorial’s secondary goal is to give you an “early adopter” advantage by building a simple login/logout user interface with Jetpack Compose.

Look for the 🛠 emoji if you’d like to skim through the content while focusing on the build and execution steps.

Jetpack Compose

Released in July 2021, Jetpack Compose (often shortened to Compose) is a UI toolkit that thoroughly updates the process of building Android apps. Instead of XML, you use declarative Kotlin code to specify how the UI should look and behave under different states. You don’t have to worry about how the UI moves between those states — Compose takes care of that for you. You'll find Compose familiar if you’re acquainted with declarative web frameworks like React, Angular, or Vue.

The Jetpack Compose approach is a significant departure from Android’s original XML UI toolkit, modeled after old desktop UI frameworks and dates back to 2008. You use a mechanism such as findViewById() or view binding to connect UI elements to code. This imperative approach is simple but requires you to define how the program moves between states and how the UI should look and behave in those states.

Jetpack Compose is built with Kotlin, takes advantage of the features and design philosophy of Kotlin language, and is designed for use in applications written in Kotlin. With Compose, you no longer have to context-switch to XML when designing your app’s UI; you now do everything in Kotlin.

What You’ll Build

You’ll use Auth0 and Jetpack Compose to build a single-screen Android app that allows users to log in and out. I’ve purposely kept it as simple as possible to keep the focus on authentication.

When you launch the completed app, you’ll see a greeting and a Log In button:

Pressing the Log In button takes the user to the Auth0 Universal Login screen. It appears in a web browser view embedded in your app. Here’s what it looks like in an emulator...

...and here’s what it looks like on a device:

When you use Auth0 to add login/logout capability to your apps, you delegate authentication to an Auth0-hosted login page. You've probably seen this in Google web applications such as Gmail and YouTube. These services redirect you to log in using accounts.google.com. After logging in, Google returns you to the web application as a logged-in user.

If you’re worried that using Auth0’s Universal Login means that your app’s login screen will be stuck with the default Auth0 “look and feel,” I have good news for you: you can customize it to match your app or organization’s brand identity.

The Universal Login page saves you from having to code an authentication system. It gives your applications a self-contained login box with several features to provide a great user experience.

If the user enters an invalid email address/password combination, it displays an error message and gives them another chance to log in:

There are two ways to exit the Universal Login screen. There’s the “unhappy path,” where the user presses the Cancel button at the upper left corner of the screen, which dismisses the Universal Login screen and returns them to the opening screen.

The “happy path” out of the Universal Login appears when the user enters a valid email address/password combination. When this happens, Auth0 authenticates the user, the embedded web view and Universal Login will disappear, and control will return to the app, which will now look like this:

Here’s what changed after the user logged in:

The title text at the top of the screen now says, “You’re logged in!”
The name, email address, and photo associated with the user’s account appear onscreen.
A Log Out button appears below the user’s photo.

As you might expect, the user logs out by pressing the Log Out button, which returns them to a slightly different version of the initial screen:

What You’ll Need

You’ll need the following to build the app:

1. An Auth0 account

The app uses Auth0 to authenticate users, meaning you need an Auth0 account. You can sign up for a free account, which lets you add login/logout to 10 applications, with support for 7,000 users and unlimited logins — plenty for your prototyping, development, and testing needs.

2. An Android development setup

To develop applications for Android, make sure you have the following, in the order given below:

Any computer running Linux, macOS, or Windows from 2013 or later with at least 8 GB RAM. When it comes to RAM, more is generally better.
Java SE Developer Kit (JDK), version 11 or later. You can find out which version is on your computer by opening a command-line interface and entering java --version.
Android Studio, version 2021.2.1 Patch 2 (also known as “Chipmunk”) or later. Jetpack Compose is a recent development, so you should use the most recent stable version of Android Studio.
At least one Android SDK (Software Development Kit) platform. You can confirm that you have one (and install one if you don’t) in Android Studio. Open Tools → SDK Manager. You’ll see a list of Android SDK platforms. Select the current SDK (Android 12.0 (S) at the time of writing), click the Apply button, and click the OK button in the confirmation dialog that appears. Wait for the SDK platform to install and click the Finish button when installation is complete.
An Android device, real or virtual:
- Using a real device: Connect the device to your computer with a USB cable. Make sure that your device has Developer Options and USB debugging enabled.
- Using a virtual device: Using Android Studio, you can build a virtual device (emulator) that runs on your computer. Here’s my recipe for a virtual device that simulates a current-model inexpensive Android phone:
  1. Open Tools → AVD Manager (AVD is short for “Android Virtual Device”). The Your Virtual Devices window will appear. Click the Create Virtual Device... button.
  2. The Select Hardware window will appear. In the Phone category, select Pixel 3a and click the Next button.
  3. The System Image window will appear, and you’ll see a list of Android versions. Select S (API 31, also known as Android 12.0). If you see a Download link beside R, click it, wait for the OS to download, then click the Finish button. Then click the Next button.
  4. The Android Virtual Device (AVD) window will appear. The AVD Name field should contain Pixel 3a API 31, the two rows below it should have the titles Pixel 3a (a reasonable “representative” phone, released three years ago at the time of writing) and S, and in the Startup orientation section, Portrait should be selected. Click the Finish button.
  5. You will be back at the Your Virtual Devices window. The list will now contain Pixel 3a API 31, and that device will be available to you when you run the app.

3. A little familiarity with Android/Kotlin development.

If you’re new to Android development or the Kotlin programming language, you might find Android Basics in Kotlin to be a good introduction.

Extending CIAM to Enable Modern Healthcare Applications

Robertino — Tue, 13 Dec 2022 13:28:10 +0000

Original post written by Alexa Jacky for Auth0 blog.

Customizing identity flows by stacking no-code integrations allows dev teams to innovate efficiently.

As healthcare delivery models evolve and digital information unlocks new possibilities, a vast array of ecosystem participants face pressure to:

Build and manage consolidated patient portals that link patients, patient advocates, and extended healthcare teams and that extend across multiple service providers.
Empower patients with convenient self-service options and quicker access to appointment information, test results, diagnoses, forms, documentation, and their healthcare providers.
Provide rapid virtual care and assistance, overcoming distance and time constraints and increasing accessibility of healthcare (and related) services.

From established healthcare providers to newcomers aspiring to dominate entirely new markets, the organizations best positioned to succeed will be those that are best able to implement fundamental identity capabilities and extend beyond the identity basics.

All the while — and in everything they do — healthcare organizations have to comply with complex regulatory requirements (e.g., HIPAA, GDPR), which vary by jurisdiction and are often layered (i.e., state laws versus federal laws).

But with developer resources already in short supply and with a healthcare organization's primary applications rightfully commanding the lion's share of attention, engineering organizations need to satisfy identity requirements as quickly — and with as little custom code to write or maintain — as possible.

For example, Jay Anslow, Senior Software Engineer at Babylon Health, shared with us that, "We estimated that it would take a team of eight staff at least a year to meet our new requirements with a home-built solution. As well as the cost of having that team, it would have delayed our timeline, so we wouldn't have been able to get our functionality out the door as quickly."

Identity Enables the Healthcare Ecosystem

Identity, particularly as it relates to securing sensitive data and complying with privacy regulations, has been a foundation of healthcare since long before the digital revolution — but as healthcare delivery organizations (HDOs) embraced new information formats and leveraged the Internet for collaboration, communications, service delivery, and other functions, customer identity and access management (CIAM) systems became essential elements of healthcare organizations' technology stacks.

On top of the transition that was already happening, the COVID-19 pandemic "caused a seven to ten-year acceleration in consumer and digital trends," according to Richard Schwabacher, Senior VP of Digital Health and Chief Digital Officer at BioReference. The result is that "Securing, transmitting, and authorizing patient access to health information digitally is now critical to the practice of medicine and core to what is needed from a modern digital health solution."

And CIAM is vital to this functionality. Out of the box, leading CIAM solutions include many features that can help healthcare organizations meet new needs, allowing even small engineering teams to:

Create patient-centric experiences, built around each individual’s needs and preferences;
Enable a vast, interconnected, and growing healthcare ecosystem; and
Simultaneously meet security, privacy, and convenience needs, rather than trading off between these necessary elements.

But while out-of-the-box functionality is important, the real world is a complex and dynamic beast (as anyone who's ever done a year-over-year roadmap comparison understands). Being able to accommodate change and tailor identity to your unique needs — and doing both without drawing too heavily upon developers — is the difference between CIAM as a necessary component of your application stack and CIAM as an operational and competitive advantage.

Secure Secrets With Spring Cloud Config and Vault

Robertino — Tue, 15 Nov 2022 13:50:29 +0000

Original post written by Jimena Garbarino for Auth0 blog.

Storing secrets in your code is a bad idea. Learn how to use Spring Cloud Config and HashiCorp Vault to make your app more secure.

In 2013, GitHub released a search feature that allows users to scan code in all public repositories. A day after the release, however, they had to partially shut it down. It was speculated that the shutdown was because the feature allowed any user to search for all kinds of secrets stored in GitHub repositories. Later, in 2014, data on 50,000 Uber drivers were stolen. It seems someone got access to the company’s database using login credentials found in a GitHub public repository. Hashicorp Vault, a tool for managing secrets and encrypting data in transit, was first announced in 2015, and Spring Vault, the integration of Spring with Vault, was first released in 2017.

It seems like a long time ago, right? Secrets leakage seems to remain pervasive and constant, happening to all kinds of developers—as explained by this study from NC State University. Exposed secrets lead to cyber-attacks, data loss or corruption, sensitive data breaches, and crypto-jacking (cryptocurrency mining using a victim’s cloud computer power). With tools like Hashicorp’s Vault and Spring Cloud Vault, the risk can be reduced.

Nowadays, it is widely recommended never to store secret values in code. Therefore, this tutorial will demonstrate the following alternatives:

Using environment variables for Spring Boot secrets
Secrets encryption with Spring Cloud Config
Secrets management with HashiCorp’s Vault
Using Spring Cloud Vault

This tutorial was created with the following frameworks and tools:

‣ Java OpenJDK 17

‣ Okta CLI 0.10.0

‣ Docker 20.10.12

‣ HTTPie 3.2.1

‣ Vault 1.12.0

Use Environment Variables for Secrets; A Precursor to Spring Vault

Spring Boot applications can bind property values from environment variables. To demonstrate, create a vault-demo-app with OpenID Connect (OIDC) authentication using the Spring Initializr. Then add web, okta, and cloud-config-client dependencies, some of which will be required later in the tutorial:

https start.spring.io/starter.zip \
  bootVersion==2.7.4 \
  dependencies==web,okta,cloud-config-client \
  groupId==com.okta.developer \
  artifactId==vault-demo-app  \
  name=="Spring Boot Application" \
  description=="Demo project of a Spring Boot application with Vault protected secrets" \
  packageName==com.okta.developer.vault > vault-demo-app.zip

Unzip the file and open the project. Modify its src/main/java/.../Application.java class to add the / HTTP endpoint:

package com.okta.developer.vault;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.security.core.annotation.AuthenticationPrincipal;
import org.springframework.security.oauth2.core.oidc.user.OidcUser;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @GetMapping("/")
    String hello(@AuthenticationPrincipal OidcUser user) {
        return String.format("Welcome, %s", user.getFullName());
    }

}

Disable the cloud configuration for the first run. Edit application.properties and add the following value:

spring.cloud.config.enabled=false

OpenID Connect authentication with Okta

In a command line session, go to the vault-demo-app root folder.

Before you begin, you’ll need a free Okta developer account. Install the Okta CLI and run okta register to sign up for a new account. If you already have an account, run okta login. Then, run okta apps create. Select the default app name, or change it as you see fit. Choose Web and press Enter.

Select Okta Spring Boot Starter. Accept the default Redirect URI values provided for you. That is a Login Redirect of http://localhost:8080/login/oauth2/code/okta and a Logout Redirect of http://localhost:8080.

What does the Okta CLI do?

The Okta CLI will create an OIDC Web App in your Okta Org. It will add the redirect URIs you specified and grant access to the Everyone group. You will see output like the following when it’s finished:

Okta application configuration has been written to: 
  /path/to/app/src/main/resources/application.properties

Open src/main/resources/application.properties to see the issuer and credentials for your app.

okta.oauth2.issuer=https://dev-133337.okta.com/oauth2/default
okta.oauth2.client-id=0oab8eb55Kb9jdMIr5d6
okta.oauth2.client-secret=NEVER-SHOW-SECRETS

> NOTE: You can also use the Okta Admin Console to create your app. See Create a Spring Boot App for more information.

Instead of storing Okta credentials in application.properties as part of the project code, Spring Boot allows you to bind properties from environment variables. You can see this in action by starting your application with the Maven command below:

OKTA_OAUTH2_ISSUER={yourOktaIssuerURI} \
OKTA_OAUTH2_CLIENT_ID={yourOktaClientId} \
OKTA_OAUTH2_CLIENT_SECRET={yourOktaClientSecret} \
./mvnw spring-boot:run

NOTE: Copy the values of yourOktaIssuerURI, yourOktaClientId, and yourOktaClientSecret as you will need them for configuration in the next sections. You can also just keep at hand yourOktaClientId and retrieve the configuration with okta apps config --app {yourOktaClientId}.

In an incognito window, go to http://localhost:8080. Here, you should see the Okta login page:

In the application logs, you’ll see the security filter chain initializes an OAuth 2.0 authentication flow on startup:

2022-09-07 08:50:09.460  INFO 20676 --- [           main] o.s.s.web.DefaultSecurityFilterChain     : Will secure any request with
[org.springframework.security.web.session.DisableEncodeUrlFilter@6b4a4e40,
org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@46a8c2b4,
org.springframework.security.web.context.SecurityContextPersistenceFilter@640d604,
org.springframework.security.web.header.HeaderWriterFilter@7b96de8d,
org.springframework.security.web.csrf.CsrfFilter@2a0b901c,
org.springframework.security.web.authentication.logout.LogoutFilter@38ac8968,
org.springframework.security.oauth2.client.web.OAuth2AuthorizationRequestRedirectFilter@7739aac4,
org.springframework.security.oauth2.client.web.OAuth2AuthorizationRequestRedirectFilter@36c07c75,
org.springframework.security.oauth2.client.web.OAuth2LoginAuthenticationFilter@353c6da1,
org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter@7e61e25c,
org.springframework.security.web.authentication.ui.DefaultLogoutPageGeneratingFilter@4f664bee,
org.springframework.security.oauth2.server.resource.web.BearerTokenAuthenticationFilter@21b51e59,
org.springframework.security.web.savedrequest.RequestCacheAwareFilter@5438fa43,
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@512abf25,
org.springframework.security.web.authentication.AnonymousAuthenticationFilter@76563ae7,
org.springframework.security.oauth2.client.web.OAuth2AuthorizationCodeGrantFilter@3e14d390,
org.springframework.security.web.session.SessionManagementFilter@4dc52559,
org.springframework.security.web.access.ExceptionTranslationFilter@51ac12ac,
org.springframework.security.web.access.intercept.FilterSecurityInterceptor@2407a36c]

Using environment variables for passing secrets to containerized applications is now considered bad practice because the environment can be inspected or logged in a number of cases. So, let’s move on to using Spring Cloud Config server for secrets storage.

Auth0 SDK for Single Page Applications v2.0 released!

Robertino — Fri, 11 Nov 2022 13:23:16 +0000

Original post written by Juan Cruz Martinez for Auth0 blog.

Let's explore the main features of the new Auth0 SDK for SPA release.

The Auth0 team released the new Auth0 Single Page App SDK v2.0, and it's now available in the npm registry. It is a major new release with a focus on development and user experience.

The new release makes an important step towards improving usability and reducing the footprint (size) of the SDK.

Quick Start with the New SDK

You can follow the quick start guide if you build a new application or connect your SPA with Auth0 using the SDK for the first time.

If you use frameworks such as React, Angular, or Vue, you can use framework-specific libraries instead. You can learn more about specific frameworks in our SPA guides section.

All of the mentioned improvements will be available in the next beta versions of our framework-specific SDKs. Be sure to keep an eye on them to be notified when their beta versions are available.

Migrating from v1.x

With the improvements from v1.x, it was necessary to introduce some breaking changes. We will cover the most impactful changes in this post, but we recommend reviewing the migration guide for the details of all breaking changes and their corresponding migration path.

Reduced Bundle Size by 60%

Auth0 SPA SDK V1.x shipped with built-in polyfills to compensate for the lack of native support on some browsers for features such as:

As the above APIs are now available for most browsers, we believe there's no more need to include those polyfills. Primarily users of IE11 would require them, and with Microsoft dropping support for IE11, we believe it makes sense to capitalize on the gains and drop support for IE11 as of V2.

By removing these polyfills, and with some small improvements on our side, we reduced the bundle size by an outstanding 60%.

Such a reduction will allow for faster download and processing times for application users.

What's New in .NET 7 for Authentication and Authorization

Robertino — Thu, 10 Nov 2022 14:29:23 +0000

Original post written by Andrea Chiarelli for Auth0 blog.

Let’s explore the new .NET 7 features for improving and simplifying authentication and authorization support in .NET applications.

The release of .NET 7 continues the simplification effort that began with .NET 5. Following this line, the new release provides .NET developers with a few features related to authentication and authorization that make .NET developers' lives a bit easier. Let's take a quick look at those features, which range from simplifications in authentication configuration to the addition of new authorization test tools, to improvements to Blazor's authentication support.

Default Authentication Scheme

When you configure authentication for your application, you need to register the authentication service through AddAuthentication(). For example, the following is the code needed to configure JwtBearer as the authentication scheme in an ASP.NET Core Web API:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
     .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
     {
         options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";
         options.TokenValidationParameters = 
           new Microsoft.IdentityModel.Tokens.TokenValidationParameters
         {
             ValidAudience = builder.Configuration["Auth0:Audience"],
             ValidIssuer = $"{builder.Configuration["Auth0:Domain"]}"
         };
     });

Although you are defining just one authentication scheme (JwtBearerDefaults.AuthenticationScheme), the AddAuthentication() method requires that you specify the default scheme to use when it is not specified in your API endpoints (see this document for more details on multiple authentication schemes in ASP.NET Core).

Starting with .NET 7, the default scheme is no longer required when you define just one authentication scheme. It is automatically inferred by the framework. In practice, you can write the previous code as follows:

builder.Services.AddAuthentication() //👈 no default scheme specified
     .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
     {
         options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";
         options.TokenValidationParameters = 
           new Microsoft.IdentityModel.Tokens.TokenValidationParameters
         {
             ValidAudience = builder.Configuration["Auth0:Audience"],
             ValidIssuer = $"{builder.Configuration["Auth0:Domain"]}"
         };
     });

In case you need to restore the old behavior for any reason, you can disable the new feature using the following statement:

AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme", true);

Simplified Configuration

One of the recurrent critiques of .NET authentication and authorization is its complexity (see this thread and this one, for example). Actually, .NET provides developers with an articulate system for managing authentication and authorization. This system is great for the flexibility it offers, but it may be hard for a beginner to digest all the details. It may be hard even for a more experienced developer who is not used to dealing with the identity features every day.

To overcome this issue, the .NET team started an initiative aiming at simplifying the authentication and authorization configuration. The .NET 7 release introduces the first step in this direction, bringing you a simplified approach to configure ASP.NET Core Web APIs authorization based on access tokens in JWT format.

Check out this article to learn how to protect your ASP.NET Core Web API.

If you ever had secured an ASP.NET Core Web API with Auth0, the following code should look familiar to you:

using Microsoft.AspNetCore.Authentication.JwtBearer;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
     .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
     {
         options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";
         options.TokenValidationParameters = 
           new Microsoft.IdentityModel.Tokens.TokenValidationParameters
         {
             ValidAudience = builder.Configuration["Auth0:Audience"],
             ValidIssuer = $"{builder.Configuration["Auth0:Domain"]}"
         };
     });

builder.Services.AddAuthorization();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

Now, you can directly rely on the built-in configuration system to define your Web API's authorization options. In fact, in addition to default authentication schemes, .NET 7 automatically loads the options to configure the authentication service from the new Authentication section of the appsettings.json configuration file. With this new feature, the code shown earlier becomes as follows:

using Microsoft.AspNetCore.Authentication.JwtBearer;

var builder = WebApplication.CreateBuilder(args);

builder.Authentication.AddJwtBearer(); //👈 new feature

builder.Services.AddAuthorization();

var app = builder.Build();

All the configuration settings are moved to the appsetting.json file as follows:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  //👇 new section
  "Authentication": {
    "Schemes": {
      "Bearer": {
        "ValidAudiences": [ "YOUR_AUDIENCE" ],
        "ValidIssuer": "YOUR_AUTH0_DOMAIN"
      }
    }
  }
  //👆 new section
}

The new Authentication section keeps the configuration settings for any authentication scheme supported by your application, although currently only the JwtBearer scheme is supported.

Notice that now you don't need anymore to call UseAuthentication() and UseAuthorization(). The framework takes care of automatically adding the required middleware to the request pipeline.

Authorization Policies for Specific Endpoints

ASP.NET Core allows you to specify policies to make more accurate authorization decisions based on the access token content or other advanced criteria. Usually, these policies are defined globally at the application level and attached to the endpoint definitions the policy applies to.

Take a look at this article to learn how to use policies to protect ASP.NET Core Web APIs, for example.

Defining policies globally is pretty good for reuse. However, sometimes you may need just a specific policy for one endpoint. In this case, you can specify your policy directly on the endpoint definition.

The following is an example of how you can use this new feature:

app.MapGet("/api/special-endpoint", () => "A special endpoint!")
    .RequireAuthorization(p => p.RequireClaim("scope", "api:special"));

DEV Community: Robertino

February 2025 Updates: What's New in Auth0

Updates You Don’t Want to Miss

Next.js SDK v4 (GA) Released

Advanced Customizations for Universal Login (Early Access)

Okta Universal Logout Integration Now Supported in Auth0

Custom Token Exchange – Early Access

More cool features we have shipped to improve your experience:

Deprecations

Community and Events

Partnering with LangChain and LlamaIndex

Events

Where Were We?

The Power of Parquet

Learn about what Parquet is and how its columnar storage and encoding techniques can help you.

What is Parquet?

Example

JSON

Parquet

Encoding

Dictionary Encoding

Run Length Encoding (RLE)

Delta Encoding

How Can You Get Started With Parquet?

What Are Modern Access Controls and How Are They Implemented?

What are Access Controls?

How Modern Access Control Works

Authentication

Authorization

RBAC

ABAC

ReBAC

Why Implement Access Controls?

Limit the Likelihood and Impact of Malicious Actors

Limit the Scope of Innocent Mistakes

Compliance and Audit

Implement Access Controls Now

FAQ

Test Authorization in ASP.NET Core Web APIs With the `user-jwts` Tool

How to use the new user-jwts tool to test a protected ASP.NET Core Web API without involving an authorization server.

Meet the user-jwts Tool

Set Up Your Project

How We Do Releases in Auth0’s New Private Platform

What’s in a Service?

Introducing the Concept of a Release Manifest

A Better Social Login: Transparency That Leads To Trust

A Better Social Login: Transparency That Leads To Trust

A Question of Trust

A User-First Approach to Online Identity

End-to-end authentication

Shhhh... Kubernetes Secrets Are Not Really Secret!

Learn how to setup secure secrets on Kubernetes using Sealed Secrets, External Secrets Operator, and Secrets Store CSI driver.

Sealed Secrets

Get Started with Jetpack Compose Authentication

Learn how to build a basic app using Android’s Jetpack Compose UI toolkit.

Jetpack Compose

What You’ll Build

What You’ll Need

1. An Auth0 account

2. An Android development setup

3. A little familiarity with Android/Kotlin development.

Extending CIAM to Enable Modern Healthcare Applications

Customizing identity flows by stacking no-code integrations allows dev teams to innovate efficiently.

Identity Enables the Healthcare Ecosystem

Secure Secrets With Spring Cloud Config and Vault

Storing secrets in your code is a bad idea. Learn how to use Spring Cloud Config and HashiCorp Vault to make your app more secure.

Use Environment Variables for Secrets; A Precursor to Spring Vault

OpenID Connect authentication with Okta

Auth0 SDK for Single Page Applications v2.0 released!

Let's explore the main features of the new Auth0 SDK for SPA release.

Quick Start with the New SDK

Migrating from v1.x

Reduced Bundle Size by 60%

What's New in .NET 7 for Authentication and Authorization

Let’s explore the new .NET 7 features for improving and simplifying authentication and authorization support in .NET applications.

Default Authentication Scheme

Simplified Configuration

Authorization Policies for Specific Endpoints

Meet the `user-jwts` Tool