<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>PKCE on Nalar</title>
    <link>https://nalar.dev/tags/pkce/</link>
    <description>Recent content in PKCE on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 16 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/pkce/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>PKCE Binds OAuth Authorization Codes to a Per-Request Verifier</title>
      <link>https://nalar.dev/pkce-binds-oauth-authorization-codes-to-a-per-request-verifier/</link>
      <pubDate>Wed, 16 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/pkce-binds-oauth-authorization-codes-to-a-per-request-verifier/</guid>
      <description>&lt;p&gt;A native application starts an OAuth authorization flow in the system browser, then waits for the operating system to route the redirect back to the app. The authorization endpoint is protected by TLS, yet the returned authorization code crosses a different boundary: application dispatch on the local device. Another application able to receive that redirect may obtain the code before the intended client does.&lt;/p&gt;&#xA;&lt;p&gt;Proof Key for Code Exchange, or PKCE, changes the value of that intercepted code. The client creates a transaction-specific secret called the &lt;code&gt;code_verifier&lt;/code&gt;, sends only a derived &lt;code&gt;code_challenge&lt;/code&gt; in the authorization request, and later presents the verifier when redeeming the code. The authorization server binds the challenge to the issued code. Possession of the code alone is then insufficient for redemption.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
