<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Authorisation on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/authorisation/</link><description>Recent content in Authorisation on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/authorisation/index.xml" rel="self" type="application/rss+xml"/><item><title>OAuth 2.0</title><link>https://lesitedefrancois.be/en/security/oauth2/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/oauth2/</guid><description>&lt;p&gt;&lt;strong&gt;OAuth 2.0&lt;/strong&gt; (RFC 6749, 2012) is an authorisation delegation framework — not an authentication protocol — that solves a specific problem: how does a user grant a third-party application access to their resources on a server, without giving that application their password? The canonical example is a user granting a calendar app access to their Google Drive files: OAuth 2.0 lets Google issue the calendar app a scoped, time-limited &lt;strong&gt;access token&lt;/strong&gt; that permits it to read Drive files, without the app ever seeing the user&amp;rsquo;s Google password. The distinction between authorisation and authentication is fundamental: OAuth 2.0 proves that a token was issued by an authorisation server for a specific scope — it says nothing about who the user is. Attempting to use OAuth 2.0 for authentication (treating token possession as proof of identity) is a well-documented anti-pattern with concrete exploits; &lt;strong&gt;OIDC&lt;/strong&gt; (OpenID Connect) is the authentication layer built on top of OAuth 2.0 that addresses this correctly.&lt;/p&gt;</description></item></channel></rss>