take a auth-shot – PKCE Grant
„Confidential Clients können im Vergleich zu Public Clients ein Geheimnis (client-secret) sicher aufbewahren, also speichern und verarbeiten.“
Heute wollen wir uns damit befassen wie Public Clients auf sichere Art und Weise an einen Access-Token kommen können.
Public Clients haben nicht nur die Einschränkung, dass sie das client-secret nicht sicher aufbewahren zu können, sie müssen auch gleichzeitig die Authentifizierung des Nutzers berücksichtigen. Genau genommen geht es darum einem Nutzer Zugriff auf eine bestimmte Ressource, über einen bestimmten Client zu gewähren.
Der empfohlene Grant dafür ist der PKCE Grant, PKCE steht dabei für Proof Key for Code Exchange. Als Ersatz für das client-secret kommen in diesem Grant 3 zusätzlicher Werte zum Einsatz.
- der code-verifier: Ein zufälliger String, bestehend aus Buchstaben, Zahlen und wenigen Sonderzeichen
- die code-challenge: der gehashte code-verifier
- die code-challenge-method: Die Hash-Methode mit der die code-challenge erzeugt wurde
| Method | Logic |
| plain | code_challenge = code_verifier |
| S256 | code_challenge = BASE64URL- ENCODE(SHA256(ASCII(code_verifier))) |
Bei der Autorisierungs-Anfrage sendet der Client seine client-id und zusätzlich die gehashte code_challenge. Der Authorization-Server nimmt diese Informationen entgegen und leitet den Endanwender an eine Anmeldeseite. Nachdem sich der Endanwender erfolgreich angemeldet hat, sendet der Authorization-Server dem Client einen code zurück.
Diesen code kann der Client nun in Kombination mit dem vorher erzeugten code_verifier gegen einen Token austauschen. Der Client ruft dabei den Token Endpoint mit dem Code und dem code_verifier auf. Dabei prüft der Authorization-Server, ob der code-verifier (gehasht) mit der vorher übergebenen code-challenge übereinstimmt. Wenn beides übereinstimmt, kann der Authorization-Server den Access-Token ausstellen und dem Client zurückgeben.
Anbei haben wir den Client Credentials Grant mit allen Rollen, also der Application (Client), dem Authorization-Server (cidaas), dem Resource Server, sowie dem Nutzer und der Anmeldeseite (Hosted Pages), in einem Ablaufdiagramm dargestellt.
Mit unserem dritten Teil über den PKCE Grant geht nun unsere take a auth-shot Blogreihe zu Ende. Wir freuen uns über Euer Feedback 😊
Unseren ersten Teil der take a auth-shot Blogreihe – „Ein Grant für alle Fälle?“ – findest du hier.
Den zweiten Teil unserer take a auth-shot Blogreihe – „Client Credentials Grant“ – findest du hier.