Modern web applications typically include APIs at their backends, encapsulating programmatic functionality, such as business rules and data access. These APIs also need protection to prevent unauthorized access. Notably, the OAuth 2.0 standard manages access to a web or mobile app's APIs and other resources. As such, it increasingly serves as an important standard for application security on today's web.
Let's examine OAuth 2.0 and how developers leverage it to protect an application's APIs and resources. We also cover important aspects of OAuth, including tokens, scopes, grants, and more. Use these insights to gain a better understanding of how to protect web applications from unauthorized access. In short, knowing how OAuth 2.0 works is vital for web developers.
Why OAuth 2.0 is Important for the Modern Web
Many modern web applications authenticate users by requiring them to provide their credentials to access the app. This form of "logging in" has been around since the early days of mainframes in the 50s and 60s. However, modern web applications include resources (APIs, media, data, etc.) that also need protection.
Forcing users to log in separately to each of these resources provides a poor user experience. It also results in an overuse of passwords. A concept known as access delegation avoids these issues. It enables resource owners to provide secure delegated access to the APIs, data, and media under their control.
Software engineers at Twitter began developing a protocol for access delegation in the early 2000s. It gradually evolved into an open standard, known as OAuth (which stands for Open Authorization). OAuth 2.0 is the latest version of this standard, which is managed by the Internet Engineering Task Force.
A Closer Look at How OAuth 2.0 Works
Now, let's dive into the details of OAuth 2.0 and how it protects today's web and mobile applications. The usage scenario for access delegation on web applications generally involves four entities:
• Resource Owner: The entity that owns the resource used by web applications, typically a user when considering data.
• Client Application: The application with an authenticated user seeking to access a web resource.
• Authorization Server: A system that verifies access requests and subsequently issues access tokens.
• Resource Server: A service or application that grants access to APIs and other relevant web-based resources.
The lifeblood of any OAuth 2.0 implementation is known as an access token. When a client application requests access to a protected resource, an authorization server issues an access token. In some cases, an authorization code is issued, which is then exchanged for an access token. This issuance assumes the client's user is properly authenticated, either for human users or in machine-to-machine scenarios.
An access token is issued with a built-in expiration timestamp, providing an extra layer of security. Importantly, access tokens are typically encrypted, which also boosts their security footprint. Additionally, an authorization server may also issue a refresh token, used to request a new access token if necessary.
What are OAuth 2.0 Scopes?
Within OAuth 2.0, scopes define the level of access granted to a client application acting on behalf of a user. It serves as a mechanism to limit what applications can do for their users, related to an application's resources. Scopes are typically based on a combination of user roles, data entities, and read vs. write access. Expect admin roles to have more powerful scope rights compared to any basic user.
The types of scopes ultimately depend on what's provided by the owner of the resource in question. For example, Fitbit, Google, GitHub, and other resource providers all define their own scopes, represented as strings. Users also can consent to specific scopes for their app. Some examples of Fitbit's scopes include cardio_fitness, electrocardiogram, and heartrate.
It is the responsibility of the client application developer to properly define scope requests in their OAuth 2.0 implementation. A deep analysis of the resource provider's scope documentation is ultimately required for proper access by any client app.
Understanding OAuth 2.0 Grants
OAuth 2.0 grants effectively define the steps a client app needs to take to get an access token. Let's examine some of the more important grant scenarios of the OAuth 2.0 specification.
• Authorization Code Grant: In this scenario, a single-use authorization code is returned to the client, which is exchanged for an access token. This approach is used by web applications where the exchange happens on the server.
• Implicit Grant: Instead of an authorization code intermediary, the implicit grant directly returns an access token upon request by the client.
• Authorization Code Grant with PKCE: This approach uses an authorization code, but with an embedded proof key for code exchange (PKCE). It provides stronger security for mobile applications and SPAs where the code-token exchange doesn't happen on the server.
• Refresh Token Grant: This grant type merely exchanges a refresh token for a new access token.
A Closer Look at OAuth 2.0 Tokens
We already mentioned how access tokens effectively serve as the lifeblood of OAuth 2.0. Authorization servers issue access tokens, and sometimes refresh tokens, when a client app requests access to a resource. As highlighted above, a refresh token is used for the issuance of a new access token once the original expires. It accomplishes this without requiring the user to reenter their credentials.
Programmers must take special care in protecting access and refresh tokens, which are highly attractive to cyber criminals. These unethical hackers find it easy to steal and decrypt access tokens stored within a web browser. As a result, software architects increasingly leverage the backend for frontend pattern. This approach stores and manages tokens in the more secure environment on the server.
OAuth 2.0 and OpenID Connect for your ASP.NET Core Application
When searching for a standards-compliant OAuth 2.0 framework for your ASP.NET Core app, look no further than Duende IdentityServer. Our flexible platform gives you full control over your business logic, data, and UI/UX. Contact our sales team for more information!