take a auth-shot ÔÇô OAuth 2.0 PKCE Grant

take a auth-shot ÔÇô PKCE Grant

ProstÔÇŽ In unserem letzten auth-shot haben wir den Grant-Typ Client-Credentials genauer angeschaut, zudem haben wir den Unterschied zwischen Confidential Clients und Public Clients kennengelernt. Heute schauen wir uns den PKCE Grant an.

ÔÇ×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.

OAuth 2.0 PKCE Grant Ablaufdiagramm | cidaas

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.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht ver├Âffentlicht. Erforderliche Felder sind mit * markiert