Erklär mir den OAuth Authorization Code Flow mit PKCE.

Der Client erzeugt einen zufälligen Verifier, hasht ihn zu einer Code Challenge und leitet den Nutzer mit dieser Challenge zum Authorization Server. Der Nutzer authentifiziert sich, wird mit einem einmal nutzbaren Code zurückgeleitet, und der Client tauscht diesen Code plus den ursprünglichen Verifier gegen Tokens. Weil der Tausch den Verifier verlangt, ist ein abgefangener Code wertlos. OAuth 2.1 verlangt PKCE für jeden Client, öffentlich oder vertraulich.

Der Client erzeugt zuerst einen Verifier mit hoher Entropie und hasht ihn mit SHA-256 zur Code Challenge. Er schickt den Nutzer mit Client-Id, Redirect-URI, Scopes, einem state-Wert und dieser Challenge zum Authorization Server. Der Nutzer loggt sich ein und stimmt zu, und der Authorization Server leitet mit einem kurzlebigen Code zurück. Der Client postet dann diesen Code und den rohen Verifier an den Token-Endpoint, der Server hasht den Verifier und prüft, ob er zur gespeicherten Challenge passt, und erst dann gibt er Tokens aus. Genau darum geht es bei PKCE: ein Code, der aus einem Redirect, einem Log oder einer bösartigen App auf dem Gerät gestohlen wurde, lässt sich ohne den Verifier nicht einlösen, und der hat den Client nie verlassen. Ich validiere state trotzdem separat, weil das CSRF auf dem Callback abdeckt und nicht das Abfangen des Codes. Geht es um Login statt um API-Zugriff, interessiert mich das OIDC-ID-Token, und ich validiere Signatur, Issuer, Audience und Nonce, bevor ich einem einzigen Claim darin vertraue.