Die Anwendungsanmeldung mit Cognito hinzufügen

Einführung

Eine Bestellanwendung benötigt eine Möglichkeit zur Benutzeranmeldung. Du erstellst ein Benutzerverzeichnis und einen öffentlichen App-Client, meldest einen synthetischen Benutzer an, validierst die ausgegebenen Token und erneuerst die Sitzung vor der Bereinigung.

Schließe zuerst Eine Bestell-API bauen und validieren ab. Diese neue Umgebung stellt ein eigenes öffentliches Backend, temporäre Anmeldeeingaben und ein Beispiel zur Tokenvalidierung bereit. Halte Passwort- und Tokendateien privat.

Bezug zu Zertifizierungen

Lab-Überblick

Das Benutzerverzeichnis der Anwendung erstellen

In diesem Schritt richtest du einen Benutzerpool, einen öffentlichen App-Client und einen bestätigten synthetischen Benutzer ein.

Wechsle in den Arbeitsbereich und verwende umask 077, damit neu erstellte Dateien nur für deinen Benutzer zugänglich sind. Dies beeinflusst Dateiberechtigungen, nicht die Autorisierungsregeln der API:

cd /home/labex/project

umask 077

Ein Cognito-Benutzerpool ist das Benutzerverzeichnis deiner Anwendung. Seine Benutzer melden sich bei der Anwendung an; deine vorbereitete IAM-CLI-Identität verwaltet die Cloud-Ressourcen. Betrachte AWS View oben, um diese nativen Ressourcen zu vergleichen.

Erstelle den eigenen Benutzerpool. $(...) speichert die zurückgegebene Pool-ID für nachfolgende native Befehle:

POOL_ID=$(aws cognito-idp create-user-pool \
  --pool-name labex-a04-users \
  --query UserPool.Id \
  --output text)
echo "$POOL_ID"

Halte seine ID fest; > schreibt den Wert in die Bestandsdatei:

printf '%s\n' "$POOL_ID" > pool-id.txt

Ein App-Client identifiziert die Anwendung, die Benutzer über diesen Pool anmeldet. Eine öffentliche Anwendung kann ein Client-Geheimnis nicht vertraulich halten. Erstelle diesen Client ohne Geheimnis und erlaube den Benutzername-Passwort-Ablauf sowie den Refresh-Token-Ablauf dieses Labs:

CLIENT_ID=$(aws cognito-idp create-user-pool-client \
  --user-pool-id "$POOL_ID" \
  --client-name orders-client \
  --no-generate-secret \
  --explicit-auth-flows ALLOW_USER_PASSWORD_AUTH ALLOW_REFRESH_TOKEN_AUTH \
  --query UserPoolClient.ClientId \
  --output text)
echo "$CLIENT_ID"

printf '%s\n' "$CLIENT_ID" > client-id.txt

Prüfe sichere Client-Konfiguration, ohne geheime Werte anzufordern:

aws cognito-idp describe-user-pool-client \
  --user-pool-id "$POOL_ID" \
  --client-id "$CLIENT_ID" \
  --query '{Name:UserPoolClient.ClientName,Flows:UserPoolClient.ExplicitAuthFlows}'

Erstelle den Demonstrationsbenutzer mit unterdrückter E-Mail-Zustellung. Dies ist eine Bereitstellungsaktion des Administrators, getrennt von der späteren Anmeldung des Benutzers:

aws cognito-idp admin-create-user \
  --user-pool-id "$POOL_ID" \
  --username labex-demo \
  --message-action SUPPRESS \
  --user-attributes Name=email,Value=demo@example.test \
  --query '{Username:User.Username,Status:User.UserStatus}'

Der anfängliche Status ist FORCE_CHANGE_PASSWORD. Wende ausschließlich für diesen temporären Testbenutzer die bereitgestellte Eingabedatei für ein dauerhaftes Passwort über die CLI an. Die Datei hat die Felder Username, Password und Permanent; die Syntax file:// liest sie, ohne das Passwort auszugeben:

aws cognito-idp admin-set-user-password \
  --user-pool-id "$POOL_ID" \
  --cli-input-json file://demo-password.json

Prüfe nur den sicheren Benutzerstatus:

aws cognito-idp admin-get-user \
  --user-pool-id "$POOL_ID" \
  --username labex-demo \
  --query '{Username:Username,Status:UserStatus,Enabled:Enabled}'

Erwarte labex-demo, CONFIRMED und true. Vergleiche in AWS View die eigene Pool-ID, orders-client, dessen fehlendes Client-Geheimnis und den bestätigten aktivierten Benutzer. Beispiel aus dem tatsächlichen nativen Pool-, Client- und Benutzerzustand:

Der unbeteiligte Pool labex-a04-reference bleibt leer. Es wurde noch kein Benutzertoken angefordert.

Anmelden und die Anwendungsidentität lesen

In diesem Schritt erhältst du tatsächliche Token für den bestätigten Benutzer und beobachtest die Ablehnung eines falschen Passworts.

InitiateAuth mit USER_PASSWORD_AUTH authentifiziert Benutzername und Passwort der Anwendung. Es autorisiert den Benutzer nicht über die IAM-Administratoridentität deiner CLI. Die bereitgestellte Datei sign-in.json enthält die synthetischen Benutzername-Passwort-Parameter für diese Demonstration.

Speichere nur AuthenticationResult in einer privaten Datei. Verwende für diese Antwort nicht cat; sie enthält Bearer-Token:

aws cognito-idp initiate-auth --client-id "$CLIENT_ID" --auth-flow USER_PASSWORD_AUTH --auth-parameters file://sign-in.json --query AuthenticationResult --output json > tokens.json

Zeige mit jq nur die nicht geheimen Antwortfelder. Der Ausdruck zur Tokenpräsenz liefert einen booleschen Wert statt der Tokenwerte:

jq '{TokenType,ExpiresIn,TokensPresent:(has("AccessToken") and has("IdToken") and has("RefreshToken"))}' tokens.json

Erwarte Bearer, eine positive Gültigkeitsdauer und TokensPresent: true. Das Zugriffstoken autorisiert geeignete Benutzer- und API-Anfragen, das ID-Token enthält Identitätsinformationen für die Anwendung, und das Refresh-Token kann neue Zugriffs- und ID-Token beschaffen. Sie haben unterschiedliche Zwecke und sind nicht austauschbar.

Extrahiere Zugriffs- und ID-Token in private Transportdateien. jq -r schreibt unverarbeitete Zeichenketten, und die Umleitung hält sie vom Terminal fern:

jq -r '.AccessToken' tokens.json > access-token.txt

jq -r '.IdToken' tokens.json > id-token.txt

GetUser authentifiziert mit dem Zugriffstoken. Fordere in seiner Ausgabe nur den Benutzernamen an:

aws cognito-idp get-user \
  --access-token "$(cat access-token.txt)" \
  --query Username \
  --output text

Erwarte labex-demo. Dies ist eine aktuelle Cognito-Antwort auf das ausgegebene Token, kein ausschließlich aus einer lokalen JSON-Datei abgeleiteter Nachweis.

Teste die bereitgestellten Parameter mit falschem Passwort und leite jede unerwartete Tokenantwort in eine separate private Datei um:

aws cognito-idp initiate-auth --client-id "$CLIENT_ID" --auth-flow USER_PASSWORD_AUTH --auth-parameters file://wrong-sign-in.json --query AuthenticationResult --output json > rejected-login.json

Erwarte NotAuthorizedException: Incorrect username or password. Der Befehl endet absichtlich mit einem von null verschiedenen Status; fahre mit dem nächsten Schritt fort, nachdem du genau diese Ablehnung gelesen hast. Ein Verbindungs- oder Authentifizierungstransportfehler ist kein Nachweis einer Ablehnung wegen falschen Passworts. Überschreibe deine gültigen Token nicht mit diesem fehlgeschlagenen Ergebnis. Die automatische Schrittprüfung validiert unabhängig die ausgegebenen Token und das aktuelle GetUser-Ergebnis; beobachte den konkreten Fehler bei falschem Passwort manuell.

Signierte Token validieren und die Sitzung erneuern

In diesem Schritt prüfst du die Signatur und den vorgesehenen Empfänger des Tokens, erneuerst die Sitzung und unterscheidest Anmeldung vom Schutz der API-Routen.

Ein JWT enthält kodierte Header- und Claim-Daten sowie eine Signatur. Bloßes Dekodieren beweist nicht, wer es ausgestellt hat. JWKS ist der öffentliche Signaturschlüsselsatz des Ausstellers; RS256 verwendet eine RSA-Signatur, die mit diesen öffentlichen Schlüsseln geprüft werden kann.

Lies das bereitgestellte gewöhnliche Beispiel zur Anwendungsvalidierung; es enthält keine wörtlichen Passwörter oder Token:

cat verify_tokens.py

Das Beispiel ruft den öffentlichen JWKS deines Pools von seinem vorbereiteten Arbeitsbereichsendpunkt ab, prüft RS256 und die Schlüssel-ID und prüft anschließend Aussteller, aktuelle Zeit, token_use und App-Client. Der signierte Aussteller verwendet die Cognito-Pool-Identität. Das Zugriffstoken identifiziert den Client mit client_id; das ID-Token verwendet aud. Führe es mit der gespeicherten Tokendatei und den tatsächlichen Pool- und Client-IDs aus:

/home/labex/project/client-venv/bin/python verify_tokens.py tokens.json "$POOL_ID" "$CLIENT_ID"

Erwarte sichere Zusammenfassungen für access und id, jeweils mit RS256 und current_time_valid: true. Es ändert außerdem ein Signaturbyte im Speicher und bestätigt die Ablehnung, bevor es die Claims akzeptiert; kein manipuliertes Token wird gespeichert. Der Scope aws.cognito.signin.user.admin des Zugriffstokens erlaubt Cognito-Benutzer-Self-Service-Vorgänge. Dieser Scope ist weder AWS-Administratorzugriff noch eine Regel zum Bestellbesitz oder ein eigener Geschäfts-Scope.

Erstelle private Refresh-Parameter aus dem ursprünglichen Refresh-Token. Dies schreibt in eine Datei und legt den Wert nicht offen:

jq '{REFRESH_TOKEN:.RefreshToken}' tokens.json > refresh-parameters.json

Beschaffe neue Zugriffs- und ID-Token, ohne das Passwort des Benutzers erneut zu senden:

aws cognito-idp initiate-auth --client-id "$CLIENT_ID" --auth-flow REFRESH_TOKEN_AUTH --auth-parameters file://refresh-parameters.json --query AuthenticationResult --output json > refreshed.json

Validiere die erneuerten Token mit denselben Prüfungen von öffentlichem Schlüssel und Claims:

/home/labex/project/client-venv/bin/python verify_tokens.py refreshed.json "$POOL_ID" "$CLIENT_ID"

Erwarte gültige Zugriffs- und ID-Zusammenfassungen für denselben Pool und Client. Die Refresh-Antwort muss kein weiteres Refresh-Token enthalten; erhalte die ursprüngliche private Antwort bis zur Bereinigung.

Die Anmeldung allein ändert die vorbereitete öffentliche API nicht. Finde ihre erzeugte ID und sende eine öffentliche Zustandsanfrage ohne Bearer-Token:

API_ID=$(aws apigatewayv2 get-apis \
  --query "Items[?Name=='labex-a04'].ApiId | [0]" \
  --output text)
echo "$API_ID"

printf '%s\n' "$API_ID" > api-id.txt

curl -i "http://127.0.0.1:8081/api/$API_ID/health"

Erwarte HTTP 200 und healthy: true. AWS View zeigt weiterhin die Autorisierung NONE für alle Routen und keine Bestellelemente. Die Benutzerauthentifizierung war erfolgreich, aber die API verlangt noch kein Token. Die nächste Einheit ergänzt JWT-Routenautorisierung; ein gültiges Token stellt trotzdem nicht automatisch den Besitz einer bestimmten Bestellung fest.

Die Erneuerung setzt die angemeldete Sitzung für denselben App-Client fort. Sie ändert weder die Autorisierung einer API-Route noch gewährt sie Zugriff auf eine Bestellung. Trenne diese Entscheidungen beim Vergleich der erneuerten Identitätsübersichten mit der weiterhin öffentlichen Zustandsantwort.

Anmelde- und API-Ressourcen entfernen

In diesem Schritt entfernst du eigene Anmelderessourcen und Backend-Bestandteile und erhältst den unbeteiligten Referenzpool, die Tabelle und Logs.

Dein Bestand umfasst labex-a04-users aus pool-id.txt, orders-client aus client-id.txt, den Benutzer labex-demo, die API-ID in api-id.txt, labex-a04-orders-api, ihre Funktions-Log-Gruppe, labex-a04-orders und die Richtlinie OrdersData der Rolle. Lösche nur diese benannten Ressourcen.

Entferne den synthetischen Benutzer, anschließend den App-Client und den eigenen Pool:

aws cognito-idp admin-delete-user --user-pool-id "$POOL_ID" --username labex-demo

aws cognito-idp delete-user-pool-client --user-pool-id "$POOL_ID" --client-id "$CLIENT_ID"

aws cognito-idp delete-user-pool --user-pool-id "$POOL_ID"

Lösche die vorbereitete funktionierende API und ihre eigenen Backend-Ressourcen:

aws apigatewayv2 delete-api --api-id "$API_ID"

aws lambda delete-function --function-name labex-a04-orders-api

aws logs delete-log-group --log-group-name /aws/lambda/labex-a04-orders-api

aws dynamodb delete-table \
  --table-name labex-a04-orders \
  --query TableDescription.TableName \
  --output text

aws iam delete-role-policy --role-name labex-a04-execution --policy-name OrdersData

Frage die nativen Bestände erfolgreich ab; Transportfehler belegen keine Abwesenheit:

aws cognito-idp list-user-pools --max-results 60 --query 'UserPools[].Name'

aws apigatewayv2 get-apis --query 'Items[].Name'

aws lambda list-functions --query 'Functions[].FunctionName'

aws dynamodb list-tables --query TableNames

Erwarte nur Referenzpool und Referenztabelle sowie leere API- und Funktionslisten. AWS View muss denselben Zustand zeigen und das Referenzelement sowie INFO platform reference keep unchanged erhalten. Die vorbereitete Ausführungsrolle behält FunctionLogs.

Entferne deine privaten Authentifizierungsdateien einschließlich bereitgestellter synthetischer Passworteingaben. rm -f löscht nur die ausdrücklich aufgeführten lokalen Dateien:

rm -f tokens.json access-token.txt id-token.txt refreshed.json refresh-parameters.json rejected-login.json sign-in.json wrong-sign-in.json demo-password.json

Das Entfernen lokaler Dateien allein ist kein serverseitiger Sitzungswiderruf. Hier wurden auch synthetischer Benutzer, Client und Pool gelöscht; dieses Lab behauptet keinen allgemeinen JWT-Abmelde- oder Widerrufsmechanismus. Erhalte die unbeteiligten Referenzressourcen bis zur Bereinigung durch den Autor und zum Herunterfahren der VM.

Zusammenfassung

Du hast ein Anwendungsbenutzerverzeichnis und einen öffentlichen App-Client erstellt, einen synthetischen Benutzer eingerichtet, dich angemeldet und eine Ablehnung bei falschem Passwort beobachtet. Du hast tatsächliche RS256-Signaturen sowie Claims für Aussteller, Client, Zeit und Typ geprüft, die aktuelle Benutzeridentität gelesen und Zugriffs- und ID-Token erneuert. Du hast Cognito-Benutzer von IAM-Identitäten sowie Anmeldung von API-Autorisierung unterschieden und anschließend eigene Ressourcen und private Dateien entfernt, während Referenzen erhalten geblieben sind.

Weitere Informationen bietet die AWS-Dokumentation: Zwecke der Benutzerpool-Tokens; JWT-Signaturen und Claim-Validierung; Sitzungserneuerung und Refresh-Token-Abläufe.