What is an OAuth 2.0 and OpenID Connect Client?

For anyone in the security industry, especially developers who communicate in security lingo about OpenID Connect and OAuth 2.0 daily, the question and answer to “What is a client?” may seem self-evident. However, for many folks on the non-technical side of application security, the term “client” can feel fuzzy and involve overlapping and muddling concepts from other subject domains.

A common and understandable misconception is that folks new to security confuse “client” with an individual or paying customer. These misunderstandings can lead to miscommunication and frustrating times between parties. So, let’s clear that up today.

In this short post, we will explain clearly what a client is in the context of application security and how understanding the concept can help you better understand your current solution’s inner workings.

What is an Identity Provider?

Before we understand a Client, we need a general understanding of an Identity Provider. An Identity Provider is a service that can verify the identity of any calling party and provide proof of identity to other parties. A good real-world example is a government that provides individuals with government-issued identification cards, such as a Passport. The identity card is vital in itself and the trusted relationship it implies, given by the issuing government.

When implementing an Identity Provider, like Duende IdentityServer, you create a trust boundary with every party that can interact with it. In this case, you can think of OAuth and OpenID Connect tokens as your solution’s passport to access functionality. But who’s using these “passports”?

What is a Client?

Understanding that an Identity Provider issues tokens, who are these tokens issued to? Well, clients, of course.

A client is any application with a trusted relationship with the identity provider. The identity provider distinguishes the client by a unique identifier within a data storage system. Another essential point about clients is that they are logical constructs. So, when talking about clients, think less about technology, cloud infrastructure, and physical instances and more about how a client fits into an overall solution. Note that we said application and not a human user; users typically work through clients and can grant permissions to the host application, but users are not considered clients.

Let’s look at some examples of clients.

In a typical three-tier architecture application, you have a frontend, data layer, and database. While there are three technical parts to a solution like this, you can think of them as a logical unit, and that logical unit would be a single client. Even if you scale the client across multiple servers, as long as it maintains the same client identifier, you can think of it as a single client with the same behavior across all deployments.

In a microservices architecture with multiple request processing services, each service can have a unique client identifier. This level of client granularity can have advantages and disadvantages. Each service can have its own security configuration, but managing all these services can become cumbersome. You can apply the same logical thinking to this architecture, where scaling out the instances of a specific client doesn’t introduce a new client, whereas creating a new logical service would require creating a new client.

Finally, let’s explore a potentially confusing use case of mobile applications and Internet of Things (IoT) solutions. At Duende, we’ve seen two potential approaches to thinking about clients in these solutions, and you could choose the approach that works best for you.

The first approach involves making each physical device (e.g., a mobile phone or IoT device) a client. This approach has the advantage that you can manage each device within the Identity Provider, which we commonly see in automation scenarios such as warehouses, logistics, printing, and healthcare facilities.

The second solution involves treating each physical device as a single logical client that works on behalf of a user. The second solution is standard in apps that use social logins, requiring users to sign in with third-party credentials. If you’ve used an app like Instagram, TikTok, or GitHub, you would think of each as a single logical client. If you’re building a mobile application hoping to scale to millions of users, don’t worry, that can still be considered one client, depending on your solution’s design.

Conclusion

So, hopefully, you understand what security experts mean when they say “client.” An Identity Provider issues security tokens to clients, and a client is a trusted application, service, or device identified by unique identifiers. Remember, Clients are logical, not physical entities, so it’s best to think about your solutions at a high level to see when something is or isn’t a unique client.

The Duende documentation provides detailed information and best practices. If you have any questions or thoughts, please leave a comment.