<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Identity on Liniom</title><link>https://215cd2c3.blog-8x6.pages.dev/tags/identity/</link><description>Recent content in Identity on Liniom</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 24 Aug 2026 11:19:40 +0200</lastBuildDate><atom:link href="https://215cd2c3.blog-8x6.pages.dev/tags/identity/index.xml" rel="self" type="application/rss+xml"/><item><title>Identity Crisis: When Email Pretends to Be a Primary Key</title><link>https://215cd2c3.blog-8x6.pages.dev/posts/identity-crisis/</link><pubDate>Mon, 24 Aug 2026 11:19:40 +0200</pubDate><guid>https://215cd2c3.blog-8x6.pages.dev/posts/identity-crisis/</guid><description>&lt;div class="paragraph"&gt;
&lt;p&gt;SSO vulnerabilities are often caused by something visibly broken. The application does not validate the token signature, accepts the wrong issuer, forgets &lt;code&gt;state&lt;/code&gt;, or leaves an open redirect in the callback.&lt;br/&gt;
&lt;br/&gt;
This one is a bit more annoying.&lt;br/&gt;
&lt;br/&gt;
The token can be valid. The signature can be correct. The issuer and audience can match. The email can even be marked as verified.&lt;br/&gt;
&lt;br/&gt;
And the application can still log the attacker into the wrong account.&lt;/p&gt;
&lt;/div&gt;</description></item></channel></rss>