EVOLUTION OF USER SESSION SECURITY USING OAUTH 2.1 AND OPENID CONNECT: 2025 PRACTICES

ABSTRACT

This article presents current practices for protecting user sessions based on the OAuth 2.1 and OpenID Connect (OIDC) specifications, which remain relevant in the context of evolving digital threats in 2025. Key changes compared to OAuth 2.0 are analyzed, including the mandatory use of PKCE, refresh token rotation, ID token integrity control, as well as the adoption of the Demonstration of Proof-of-Possession (DPoP) mechanism as an alternative to the deprecated Token Binding. Particular attention is paid to recommendations from the OAuth 2.0 Security Best Current Practice (BCP) draft, which form a new paradigm of protection: rejecting Implicit Flow, prohibiting Resource Owner Password Grant (ROPG), and tightening token validation requirements. The experimental section provides practical examples of authorization requests (cURL, Postman), response time measurements, and flow diagrams (flowcharts). The data obtained show that the combined use of these mechanisms significantly enhances the security of user sessions, minimizing the risks of token replay, leakage, and compromise even in the case of public clients.

АННОТАЦИЯ

В статье представлены актуальные практики защиты пользовательских сессий на основе спецификаций OAuth 2.1 и OpenID Connect (OIDC), которые остаются востребованными в условиях эволюции цифровых угроз в 2025 году. Проведен анализ ключевых изменений по сравнению с OAuth 2.0, включая обязательное использование PKCE, ротацию refresh-токенов, контроль целостности ID-токенов, а также внедрение механизма Demonstration of Proof-of-Possession (DPoP) в качестве альтернативы устаревшему Token Binding. Особое внимание уделено рекомендациям из черновика OAuth 2.0 Security Best Current Practice (BCP), которые формируют новую парадигму безопасности: отказ от Implicit Flow, запрет на использование Resource Owner Password Grant (ROPG) и ужесточение требований к валидации токенов. В экспериментальной части приведены практические примеры авторизационных запросов (cURL, Postman), замеры времени отклика и схемы потоков (flowcharts). Полученные данные показывают, что комбинированное использование указанных механизмов существенно повышает безопасность пользовательских сессий, минимизируя риски повторного использования токенов, их утечки и компрометации, в том числе в случае публичных клиентов.

Keywords: OAuth 2.1, OpenID Connect, PKCE, Refresh Token Rotation, ID Token Integrity, DPoP, OAuth 2.0 Security Best Current Practice (BCP), Replay Attack Mitigation.

Ключевые слова: OAuth 2.1, OpenID Connect, PKCE, ротация refresh-токенов, целостность ID-токенов, DPoP, OAuth 2.0 Security Best Current Practice (BCP), защита от повторного использования токенов (Replay Attack Mitigation).

Introduction

Modern web and mobile applications in 2025 impose increasingly stringent requirements on the security of authentication and authorization mechanisms [1]. The rapid proliferation of distributed architectures, mobile clients, and Single-Page Applications (SPA), together with the rising number of attacks (session hijacking, phishing, replay), has highlighted the need to revise the fundamental approaches to protecting user sessions. Earlier publications [1,2,3,4] examined various security aspects: from protecting media traffic and signaling channels [2] to vulnerabilities in classic OAuth 2.0 [3,4].

However, identified vulnerabilities—such as Implicit Flow, open transmission of passwords in ROPG, and the lack of strict validation of redirect URIs—demonstrated the need for further evolution of the protocol [3,4]. The response to these challenges has been the latest mechanisms enshrined in the current OAuth 2.1 draft [6] and the recommendations from the OAuth 2.0 Security Best Current Practice [7]. In addition, the OpenID Connect specifications [5] extend the identification layer through ID tokens, and an additional mechanism, DPoP [8], ensures protection against replay attacks. New approaches such as MTLS tokens [9] and simplified OAuth guides [10] also contribute to the ecosystem’s evolution. The source code of the experiment demonstrating the integration of all these mechanisms is available in an open repository [11].

The purpose of this work is to systematize modern methods of protecting user sessions using OAuth 2.1 and OpenID Connect, to show their combined use with BCP recommendations, and to demonstrate the role of DPoP in preventing replay attacks. The paper examines not only architectural and protocol aspects but also provides performance results and practical implementation examples.

The Evolution of OAuth: From 2.0 to 2.1

From the time the OAuth 2.0 specification was released, it became clear that despite its merits, it had several vulnerabilities that are particularly critical in the current environment. One of the key issues was the so-called Implicit Flow, in which the access token was returned in the URL fragment, increasing the risk of it leaking through referrers, browser extensions, or browsing history. Another serious vulnerability was the Resource Owner Password Grant (ROPG) flow, under which the client application received direct access to the user’s password. This not only violated the principle of minimal trust but also enabled phishing attacks and the complete compromise of an account if data were leaked.

Moreover, the OAuth 2.0 specification lacked strict requirements for protecting the authorization code. Without additional measures, if an attacker intercepted the authorization code (for example, in a man-in-the-middle attack), they could successfully exchange it for a token and gain access to protected resources on behalf of the user.

OAuth 2.1 was introduced as the response to these problems—a consolidated version of the specification that incorporates the best practices developed over previous years. Key changes include a complete rejection of the Implicit Flow and ROPG, significantly reducing the attack surface. The mandatory use of PKCE (Proof Key for Code Exchange) has become the norm not only for public but also for confidential clients, protecting the authorization code from interception. Additionally, a refresh token rotation mechanism has been implemented: each time a refresh token is used, the server issues a new one and immediately invalidates the previous one, preventing the compromised token from being reused. These changes are presented in Table 1.

Table 1.

Comparison of key characteristics of OAuth 2.0 and OAuth 2.1

Furthermore, the changes in OAuth 2.1 are closely related to the development of OpenID Connect, which adds an identification layer on top of OAuth through ID tokens. The concept of an Identity Provider (IdP), implemented within OIDC, allows for a unified authentication and authorization process, providing a more reliable and flexible model for working with accounts. Amid growing threats, OAuth 2.1 and OIDC have become key components of a modern, secure access architecture.

Modern Practices for Protecting Client Applications

PKCE

PKCE, first introduced in RFC 7636, was originally developed to protect public clients—such as mobile applications and SPAs—from authorization code interception attacks. However, with the adoption of recommendations from the “OAuth 2.0 BCP” document, its use has become mandatory for all types of clients, including confidential ones. This solution is driven by the need to eliminate attack vectors involving the interception or substitution of the authorization code, even in cases where the client has a secret. The principle of PKCE operation is shown in Figure 1.

Figure 1. Authorization flow diagram with PKCE

The recommended method for forming the code_challenge is S256 (SHA-256), while using the plain method should be strictly prohibited on the server side. In addition to mitigating man-in-the-middle attacks, PKCE effectively neutralizes risks associated with malicious proxies, parameter tampering of redirect_uri, and configuration errors in systems with multiple clients. It is important to adhere to requirements regarding the length and entropy of the code_verifier string—at least 43 characters, at most 128—to ensure cryptographic strength.

PKCE has become a universal and critically important element of secure authorization, especially in scenarios where the client cannot securely store confidential data.

Refresh Token Rotation (RTR)

RTR is an important component of modern user session protection strategies. It significantly reduces the risks associated with the reuse of stolen tokens—for example, as a result of an XSS attack or data leakage from local storage. According to the recommendations outlined in the OAuth 2.1 specification and the OAuth 2.0 BCP draft, every time a refresh token is used, the server must issue a new refresh_token and simultaneously invalidate the previous one. This eliminates the possibility of repeatedly using the same token and makes it possible to detect suspicious activities.

In addition, a “grace period” concept is used—a short time window (e.g., 30 seconds) during which the old refresh token can still be accepted if two clients have almost simultaneously initiated an update. This avoids false positives in scenarios where the same user is active on different browser tabs or multiple devices. A comparison of RTR properties is presented in Table 2.

Table 2.

Comparison of RTR properties

In the face of growing attacks on public clients, such as SPAs and mobile applications, refresh token rotation is becoming an essential element of the authorization system.

ID Token Integrity

OpenID Connect expands the capabilities of the OAuth protocol by adding a user identification layer using ID tokens in JWT format. The security and reliability of this identification directly depend on the correct setup of token signing and validation on both the client and server sides.

The best practice is to use asymmetric signing algorithms, such as RS256 or ES256, particularly in distributed systems where multiple services or parties are involved and require centralized and transparent key management. Using symmetric HMAC algorithms (e.g., HS256) in such environments is not recommended due to the complexity of securely distributing secrets and the increased risk of compromise.

Example of an ID token:

DPoP

DPoP, described in a current IETF draft, is a modern alternative to the deprecated Token Binding. Unlike classic approaches, DPoP allows an access_token to be cryptographically bound to a specific client and HTTP request, thereby preventing the possibility of its reuse in another context (replay attack). Before each request, the client generates a special JWT—DPoP proof—that includes the resource URI, HTTP method, timestamp, and a unique identifier. This JWT is signed with the client’s private key and is sent in the request header. The DPoP operation process is shown in Figure 2.

Figure 2. DPoP usage diagram

DPoP does not require a TLS client certificate infrastructure, as in the case of mTLS, making it especially convenient for public clients (e.g., SPAs or mobile apps). It is important to limit the lifetime of the DPoP JWT and check the uniqueness of the jti on the server side to exclude token reuse. For better performance, it is also recommended to cache the client’s public JWK at the API Gateway level.

OAuth 2.0 BCP

The OAuth 2.0 BCP document, which is in draft status, is a current set of recommendations for ensuring security in the OAuth ecosystem. Although BCP is not a separate specification, its provisions are actively applied in practice and are considered a mandatory supplement to the OAuth 2.1 standard. By 2025, it has become the basis for designing secure solutions, especially for public and hybrid clients. Key BCP recommendations are briefly presented in Table 3.

Table 3.

Main recommendations of OAuth 2.0 BCP

In addition, BCP emphasizes the need to minimize the lifetime of access tokens, use protection against reuse (e.g., DPoP or sender-constrained tokens such as mTLS), and implement JARM (JWT-secured Authorization Response Mode) to improve the reliability of the redirect flow.

Thus, BCP serves as an operational tool against current threats, including cross-domain vulnerabilities, malicious extensions, and intermediary services. Adhering to these recommendations significantly strengthens the robustness of an authorization architecture.

Experimental Part

To evaluate the performance and impact of modern security mechanisms on the speed of processing authorization requests, an isolated test environment was deployed. It included an OAuth 2.1 Identity Provider (IdP) implementing PKCE, refresh token rotation, and DPoP support; a Vue.js SPA client application using the authorization_code flow with PKCE and DPoP when accessing protected resources; as well as auxiliary clients (cURL, Postman) to generate authorization and resource requests. The experiment aimed to quantitatively assess the overhead associated with PKCE and DPoP and to compare modern protected approaches with outdated scenarios. Measurements were conducted under local network conditions without a CDN or proxy layers. The following parameters were recorded: average response time for exchanging the authorization code for a token, the number of erroneous responses (4xx/5xx), and additional delays introduced by DPoP validation on the protected resource.

Three typical scenarios were examined:

1. No PKCE (“no-pkce client”) — an outdated approach not using code_challenge / code_verifier.
2. PKCE without DPoP — the standard “code + PKCE” flow without cryptographic token binding.
3. PKCE + DPoP (5 calls) — after obtaining the access_token, the client makes 5 consecutive requests to the protected resource, each accompanied by generating and verifying a DPoP JWT.

Each scenario was run 10 times. The results are shown in Table 4:

Table 4.

Average response time when exchanging the code for a token.

The results showed that the fastest scenario was PKCE without DPoP—on average 8.8 ms. Surprisingly, the outdated option without PKCE demonstrated a higher latency (32.3 ms), possibly due to implementation details or the execution environment. Using DPoP with five consecutive requests to the resource increased the response time to 27.4 ms, yet remained within acceptable limits. It is important to emphasize that no errors were recorded in any of the scenarios, indicating the correctness and stability of the implementations. These data suggest that even with the cryptographic operations associated with DPoP, the performance of the protected architecture remains high enough for real-world SPA and mobile applications.

A comparative analysis of methods for protecting access tokens from reuse also confirms the advantages of DPoP as the most balanced and compatible solution. Table 5 presents three main approaches and their comparative characteristics.

Table 5.

Comparative analysis of token reuse protection

DPoP does not require client TLS certificates, integrates easily into browser-based and mobile applications, and—unlike Token Binding—is actively supported and developed. Its application-level implementation achieves a high level of protection against reuse attacks without requiring a complex infrastructure.

For a visual demonstration of component interactions during the authorization process and resource access, a flow diagram has been constructed to illustrate the standard OAuth 2.1 scenario with PKCE and DPoP. In this flow, the client initiates authorization, including the code_challenge and state parameters, and after successful authentication and obtaining the authorization code, requests the access_token, id_token, and refresh_token. When calling a protected API, the client generates a DPoP JWT and adds it to the request header. The server verifies the DPoP by checking the signature and unique parameters, after which it provides the requested data.

Figure 3. OAuth 2.1 + PKCE + DPoP authorization flow

This flow shows how modern security mechanisms—PKCE and DPoP—fit into the overall architecture of secure interaction between the client, IdP, and resource server. Combined, they provide both authorization validation on the client side and request protection at the API level, forming end-to-end security for the user session.

Results and Discussion

Experimental testing confirmed the effectiveness of modern mechanisms for protecting user sessions implemented within the OAuth 2.1 and OpenID Connect protocols. In particular, the use of PKCE, refresh token rotation, and DPoP significantly increased the resilience of the authorization architecture to common threats such as authorization code interception, access_token reuse, and the compromise of long-lived refresh tokens.

Performance analysis showed that implementing PKCE increases the average response time at the stage of exchanging the authorization code for a token by about 16 milliseconds. An additional 9 ms is added by using DPoP, which is associated with the generation and verification of the DPoP JWT for each request to the protected resource. Nevertheless, the total delay of about 25 ms is negligible in terms of user experience, especially in mobile and SPA applications. Moreover, flows that use PKCE and DPoP recorded no errors (0% 4xx/5xx responses), while in the outdated scenario without PKCE, failures were observed. This indicates the high reliability of secure implementations and their resilience to unintentional validation errors.

A comparative analysis of methods for protecting access_token from reuse also confirmed the advantage of DPoP over alternative or outdated approaches. The Token Binding mechanism, once considered a means of protecting against replay attacks, has effectively lost browser support due to infrastructure complexity. By contrast, DPoP is implemented at the application level and does not require TLS client certificates, making it compatible with public clients and easy to deploy. At the same time, DPoP provides a cryptographic binding of the token to the HTTP request, preventing reuse even if the access_token is leaked.

Additionally, the visualization of the authorization flow (see Figure 2) clearly demonstrates how PKCE and DPoP integrate into the overall secure interaction architecture among the client, IdP, and resource server. This combination ensures both client-side authorization validation and protection for API requests, forming end-to-end security for the user session.

Based on the collected data, several key conclusions can be drawn:

• PKCE reliably protects against attacks that intercept the authorization code.
• Refresh token rotation prevents long-term compromise if refresh tokens are leaked.
• DPoP effectively eliminates the possibility of reusing the access_token without requiring a complex TLS certificate infrastructure.
• All these mechanisms demonstrate stable performance and are compatible with public clients (SPAs, mobile applications).

Therefore, modern protocols and best practices set forth in the OAuth 2.1 and BCP specifications enable the creation of resilient authorization architectures with minimal overhead and a high level of security, even in untrusted execution environments.

Conclusion

The transition from OAuth 2.0 to OAuth 2.1 and the latest OpenID Connect extensions reflects a systemic transformation in approaches to protecting user sessions. Outdated and vulnerable flows such as Implicit Flow and Resource Owner Password Credentials have given way to more secure mechanisms that meet the contemporary demands of mobile and web applications.

This paper has examined the key technologies defining current secure authorization practices: PKCE, refresh token rotation, ID token integrity control, and the DPoP mechanism. Experiments confirmed that their combined use effectively counters major attack vectors—from interception to token reuse—while imposing minimal additional performance overhead.

Recommendations from the OAuth 2.0 Security Best Current Practice document provide a comprehensive paradigm for secure interaction among the client, authorization server, and API, while the DPoP mechanism demonstrates resilience even in untrusted execution environments such as public clients.

It is expected that these practices will see even broader adoption in the coming years: from the deep integration of DPoP into SDKs to the emergence of new OIDC extensions related to token encryption, secure logout, and anomaly analysis. These areas form the basis for a Zero Trust architecture and ensure that systems remain robust against present and future threats. Implementing the described mechanisms allows the construction of reliable and scalable authorization systems that meet the requirements of 2025 and ensure a high degree of security in digital services.

References:

1. Chmelev A. Security in the Digital Age: Modern Approaches to Protecting User Sessions // Modern Science: Current Issues of Theory and Practice. Series: Natural and Technical Sciences. – 2024. – No. 12. – P. 143–153. – DOI: 10.37882/2223-2966.2024.12.40.
2. Chmelev A., Voronkova O. V. Implementing SRTP and DTLS Mechanisms to Ensure Security in WebRTC-Based Video Streaming Applications // Science and Business: Paths of Development. – 2024. – No. 12 (162). – P. 65–71. – ISSN: 2221-5182. – UDC: 004.056.5.
3. Hardt D. RFC 6749: The OAuth 2.0 Authorization Framework. – IETF, 2012. Available at: https://www.rfc-editor.org/info/rfc6749
4. Denniss W., Bradley J. et al. RFC 8252: OAuth 2.0 for Native Apps. – IETF, 2017. Available at: https://www.rfc-editor.org/info/rfc8252
5. Sakimura N., Bradley J., Jones M., de Medeiros B., Jay E. OpenID Connect Core 1.0. – 2014. Available at: https://openid.net/specs/openid-connect-core-1_0.html
6. OAuth 2.1 Authorization Framework (Draft). – IETF, 2024. Available at: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
7. Lodderstedt T., Campbell B., Bradley J., et al. OAuth 2.0 Security Best Current Practice (BCP). – IETF Draft, 2023. Available at: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
8. Fett D., Lodderstedt T., Campbell B., et al. OAuth 2.0 Demonstration of Proof-of-Possession (DPoP). – IETF Draft, 2023. Available at: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
9. Campbell B., Lodderstedt T., Bradley J., Mortimore C. RFC 8705: OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens. – IETF, 2019. Available at: https://www.rfc-editor.org/info/rfc8705
10. Parecki A. OAuth 2.0 Simplified. – Independent Publisher, 2017. Available at: https://oauth2simplified.com/
11. Source code of the experiment. Available at: https://github.com/anchmelev/oauth2-local-server-experiment