{ "id": "4e1d9fc3-36c6-4c38-9cba-1a46415bb09d", "created_at": "2026-04-06T00:12:35.653901Z", "updated_at": "2026-04-10T13:11:48.970438Z", "deleted_at": null, "sha1_hash": "829fa4d65d7e692574204680a095a0877b7b7115", "title": "A leap forward in token security: Okta adds support for DPoP", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 80600, "plain_text": "A leap forward in token security: Okta adds support for DPoP\r\nBy About the Author\r\nArchived: 2026-04-05 16:28:24 UTC\r\nHave you ever wondered how secure your tokens are when they are transmitted from a client to a server? As our\r\ndigital footprints expand, the need for more stringent security measures in web applications and APIs has never\r\nbeen greater. In the wake of a recent GitHub security breachopens in a new tab affecting dozens of organizations,\r\nthe question of token securityopens in a new tab has once again been thrust into the spotlight.\r\nRecently, a group of hackers used stolen OAuth access tokensopens in a new tab to gain unauthorized access to\r\nnumerous organizations' internal systems, causing considerable disruption and raising serious concerns over how\r\nwe protect our digital identities. This incident serves as a stark reminder of the importance of implementing robust\r\nsecurity measures, especially when it comes to OAuth tokens.\r\nToday, we are excited to announce support for the OAuth 2.0 Demonstrating Proof-of-possession at the\r\nApplication Layer (DPoP)opens in a new tab, a significant approach for bolstering security and mitigating risks\r\nassociated with token-based authentication. In this blog post, we will delve deep into the world of OAuth 2.0\r\ntoken binding using cryptographic keys. We will explore what it means, how it works, and why it is an important\r\nstep toward ensuring a more secure token transmission process.\r\nHistory of API security\r\nIn the early days of API development, API keys were the cornerstone of authentication. These static strings were\r\npassed along with API calls, offering a simple yet effective way to identify and authenticate the client. But, as the\r\ndigital landscape evolved, so did the security demands. Despite the convenience of API keys, they come with\r\nnotable downsides. They never expire and lack authorization information, which means they can be used to\r\nperform any operation. This open-ended nature of API keys poses considerable security risks, especially if they\r\nfall into the wrong hands.\r\nEnter the world of OAuth 2.0, a protocol designed to overcome these limitations. OAuth access tokens are short-lived strings that can be used to make API calls. They are ephemeral, with shorter expiration times than API keys,\r\nand they carry information about the user and the application to which the token was minted. Moreover, access to\r\nAPIs can be restricted using OAuth scopes and permissions. Despite these advancements, OAuth tokens, like API\r\nkeys, are still bearer tokens. This means anyone who gains possession of these tokens can use them just as any\r\nother party could — to make API requests and extract information. Given the far-reaching implications of a token\r\nbreach, it’s clear that we need a way to ensure that even if tokens are intercepted, they can't be misused.\r\nThat's where the new OAuth 2.0 standard comes in. In a significant stride towards enhancing token security, Okta\r\nhas introduced support for DPoP with our OAuth applications and authorization servers.\r\nProof of possession\r\nhttps://www.okta.com/blog/2023/06/a-leap-forward-in-token-security-okta-adds-support-for-dpop/\r\nPage 1 of 4\n\nProof-of-possession (PoP)\r\n in OAuth tokens refers to a security mechanism that ensures the client sending a\r\nrequest to the resource server is in possession of a specific cryptographic key, thus proving its identity. This\r\nconcept is particularly important in the context of OAuth 2.0, as it aims to improve the security of bearer tokens,\r\nwhich are the common choice. There are two ways to implement proof of possession for OAuth tokens, mTLS-based certificate-bound access tokens (RFC 8705)opens in a new tab and DPoPopens in a new tab.\r\nMutual Transport Layer Securityopens in a new tab (mTLS) PoP is a security mechanism that ensures both the\r\nclient and server involved in a communication authenticate each other using digital certificates, providing an extra\r\nlayer of security compared to regular TLS. In regular TLS, only the server presents a certificate for authentication.\r\nHowever, in mTLS, both client and server present their certificates, ensuring that both parties are who they claim\r\nto be. mTLS can be used with certificate-bound access tokens, which bind access tokens to specific cryptographic\r\nkeys and require the sender to prove possession of those keys. But the mTLS-based proof of possession comes\r\nwith its own disadvantages.\r\nComplexity\r\nImplementing mTLS requires special domain knowledge and additional labor, which could lead to a steeper\r\nlearning curve for developers, especially for those who are not well-versed in mTLS.\r\nCompatibility issues\r\nAlthough mTLS offers strong security, it may not be compatible with all tech stacks or platforms. For instance,\r\nmTLS may not be suitable for certain client types, such as single-page applications (SPAs) and native applications\r\n(Mobile Apps), as it's not easily implementable in these scenarios. This is primarily due to client-side storage\r\nlimitations and browser compatibility issues.\r\nPerformance Impact\r\nWhile mTLS does not incur an extra roundtrip for client authentication, it does add some overhead in terms of\r\ndata during the initial handshake. This additional data can potentially affect performance, especially when dealing\r\nwith large-scale systems or high volumes of requests.\r\nOAuth 2.0 Demonstrating Proof-of-possession at the Application Layer (DPoP)\r\nJust like mTLS, DPoP provides better security compared to traditional bearer tokens by binding access and refresh\r\ntokens to a private key that belongs to the client. This binding makes the DPoP access token sender-constrained,\r\nmeaning that its replay, if leaked or stolen, can be detected and prevented, unlike the common bearer token. \r\nhttps://www.okta.com/blog/2023/06/a-leap-forward-in-token-security-okta-adds-support-for-dpop/\r\nPage 2 of 4\n\nThe client first generates a public/private key pair for use with DPoP. Then the client adds the public key in the\r\nheader of the JWT and signs the JWT with the private key. The client adds the JWT to the DPoP request header\r\nand sends the request to the token endpoint for an access token. After verifying the DPoP header, the authorization\r\nserver binds the public key to the access token and sends the response.\r\nWhen the client accesses a protected API using a DPoP token, it generates a new DPoP proof signed by the same\r\nprivate key used to obtain the token. This proof must be included as part of the DPoP header, which provides an\r\nadditional layer of security compared to bearer tokens. DPoP-bound tokens mitigate the misuse of tokens by\r\nunauthorized parties, including bad actors and resource APIs with access to the token that re-use it to access other\r\nendpoints.\r\nBenefits of using DPoP over mTLS for token protection\r\nSince DPoP operates at the application layer, leveraging asymmetric cryptography and lightweight JSON Web\r\nTokens (JWTs), it is much more accessible to developers, as it does not require additional infrastructure and is\r\nhttps://www.okta.com/blog/2023/06/a-leap-forward-in-token-security-okta-adds-support-for-dpop/\r\nPage 3 of 4\n\ntransparent to end users. DPoP also works well with public OAuth 2.0 clients, such as single-page applications\r\n(SPAs) and mobile applications.\r\nHow can you get started?\r\nWe are thrilled to announce out-of-the-box support for OAuth DPoP token protection for all Okta customers. To\r\nget started, follow the DPoP developer guideopens in a new tab.\r\nSource: https://www.okta.com/blog/2023/06/a-leap-forward-in-token-security-okta-adds-support-for-dpop/\r\nhttps://www.okta.com/blog/2023/06/a-leap-forward-in-token-security-okta-adds-support-for-dpop/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://www.okta.com/blog/2023/06/a-leap-forward-in-token-security-okta-adds-support-for-dpop/" ], "report_names": [ "a-leap-forward-in-token-security-okta-adds-support-for-dpop" ], "threat_actors": [], "ts_created_at": 1775434355, "ts_updated_at": 1775826708, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/829fa4d65d7e692574204680a095a0877b7b7115.pdf", "text": "https://archive.orkl.eu/829fa4d65d7e692574204680a095a0877b7b7115.txt", "img": "https://archive.orkl.eu/829fa4d65d7e692574204680a095a0877b7b7115.jpg" } }