<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>DPoP on Nalar</title>
    <link>https://nalar.dev/tags/dpop/</link>
    <description>Recent content in DPoP on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 19 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/dpop/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>DPoP Binds OAuth Tokens to Client Keys, Not to Client Identity</title>
      <link>https://nalar.dev/dpop-binds-oauth-tokens-to-client-keys/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/dpop-binds-oauth-tokens-to-client-keys/</guid>
      <description>&lt;p&gt;A bearer access token normally authorizes whichever party can present its value to a resource server. Copying the token can therefore move its authority away from the client that originally received it. OAuth 2.0 Demonstrating Proof of Possession, or DPoP, changes that property by binding a token to a public key and requiring a signed proof from the corresponding private key during presentation.&lt;/p&gt;&#xA;&lt;p&gt;That binding narrows one important failure mode, but it does not turn the key into a universal client identity. DPoP is an application-layer sender-constraining mechanism. Its guarantees depend on the token binding, proof validation, replay policy, TLS, and the security of the client execution context.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
