Autorisierung: IAM, Lambda Authorizers und Cognito
Sichern Sie API-Endpunkte mit IAM-SigV4-Signaturen, benutzerdefinierten Lambda Authorizers oder Amazon-Cognito-User-Pool-Authorizers.
Autorisierung: IAM, Lambda Authorizers und Cognito ist eine kostenlose Cloud & IT Cert Prep-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cloud & IT Cert Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.
Warum die API-Autorisierung wichtig ist
Ohne Autorisierungskontrollen könnte jeder Internet-Client Ihre API-Gateway-Endpunkte aufrufen und auf Daten zugreifen oder diese ändern. API Gateway bietet drei native Autorisierungsmechanismen: IAM (SigV4), Lambda-Authorizer und Amazon-Cognito-User-Pool-Authorizer. Jeder Mechanismus eignet sich für unterschiedliche Anwendungsfälle: IAM für Aufrufe zwischen AWS-Services, Lambda-Authorizer für benutzerdefinierte token- oder anforderungsbasierte Authentifizierung und Cognito für die Authentifizierung von Web- und mobilen Benutzern.
IAM-Autorisierung mit SigV4
Die IAM-Autorisierung erfordert, dass Aufrufer Anforderungen mit AWS Signature Version 4 (SigV4) signieren. Der Aufrufer benötigt AWS-Anmeldeinformationen (Zugriffsschlüssel + geheimer Schlüssel oder temporäre Anmeldeinformationen von STS), und die IAM-Richtlinie muss execute-api:Invoke für die ARN der API erlauben. Dies eignet sich ideal für Aufrufe zwischen Maschinen (Server-zu-Server) innerhalb von AWS: Lambda ruft eine andere API auf, EC2 ruft eine interne API auf oder ein Service greift kontenübergreifend zu. Browser-Clients können SigV4 nicht ohne Weiteres verwenden.
# IAM policy to allow invoking a specific API endpoint
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Action': 'execute-api:Invoke',
'Resource': 'arn:aws:execute-api:us-east-1:123456789012:abc123/prod/GET/orders'
}]
}Lambda-Authorizer: tokenbasiert
Ein Lambda-Authorizer (früher Custom Authorizer) ist eine von Ihnen geschriebene Lambda-Funktion, die API Gateway aufruft, bevor die Backend-Integration aufgerufen wird. Bei tokenbasierten Authorizern extrahiert API Gateway ein Token (JWT, OAuth, API-Schlüssel) aus dem Authorization-Header und übergibt es an Ihre Lambda-Funktion. Ihre Lambda-Funktion validiert das Token (prüft beispielsweise die JWT-Signatur anhand eines öffentlichen Schlüssels oder ruft einen Drittanbieter für die Identitätsverwaltung auf) und gibt ein IAM-Richtliniendokument zurück, das die Anforderung erlaubt oder ablehnt.
def lambda_handler(event, context):
token = event['authorizationToken']
# Validate token (JWT verification, introspect OAuth, etc.)
if is_valid_token(token):
return {
'principalId': 'user123',
'policyDocument': {
'Version': '2012-10-17',
'Statement': [{'Effect': 'Allow', 'Action': 'execute-api:Invoke',
'Resource': event['methodArn']}]
},
'context': {'userId': 'user123', 'role': 'admin'}
}
raise Exception('Unauthorized')Lambda-Authorizer: anforderungsbasiert
Bei anforderungsbasierten Lambda-Authorizern übergibt API Gateway den vollständigen Anforderungskontext (Header, Query-Strings, Stage-Variablen und Pfadparameter) an Ihre Lambda-Funktion – nicht nur ein Token. Dies ist nützlich für Autorisierungen, die von mehreren Anforderungsattributen abhängen, etwa IP-Allowlists, Header-Kombinationen oder Prüfungen der Multi-Faktor-Authentifizierung. Anforderungsbasierte Authorizer werden sowohl von REST API als auch von HTTP API unterstützt.
Caching von Lambda-Authorizern
Wenn bei jeder API-Anforderung ein Lambda-Authorizer aufgerufen wird, entstehen zusätzliche Latenz und Kosten. Aktivieren Sie das Caching von Authorizer-Ergebnissen: Cachen Sie die vom Authorizer zurückgegebene IAM-Richtlinie für eine konfigurierbare TTL (0–3600 Sekunden), wobei der Tokenwert als Schlüssel dient. Nachfolgende Anforderungen mit demselben Token überspringen den Lambda-Aufruf und verwenden die gecachte Richtlinie. Legen Sie die TTL passend zur Gültigkeitsdauer Ihres Tokens fest – ist ein Token 1 Stunde gültig, cachen Sie das Authorizer-Ergebnis ebenfalls für diesen Zeitraum. Caching ist in REST API verfügbar; JWT-Authorizer für HTTP API verfügen über integriertes Caching.
Amazon-Cognito-User-Pool-Authorizer
Cognito-User-Pool-Authorizer validieren von Cognito ausgestellte JWTs direkt in API Gateway, ohne eine Lambda-Funktion zu benötigen. Wenn sich ein Benutzer über Cognito authentifiziert (über die Hosted UI, das SDK oder einen föderierten Identitätsanbieter), stellt Cognito ein ID-Token oder Zugriffstoken aus. Der Client fügt dieses Token in den Authorization-Header ein. API Gateway überprüft die Tokensignatur und den Ablauf anhand des Cognito User Pool. Ist das Token gültig, wird die Anforderung fortgesetzt; andernfalls gibt API Gateway 401 zurück.
aws apigateway create-authorizer \
--rest-api-id 'abc123' \
--name 'CognitoAuthorizer' \
--type COGNITO_USER_POOLS \
--provider-arns 'arn:aws:cognito-idp:us-east-1:123456789012:userpool/us-east-1_XXXXXXX' \
--identity-source 'method.request.header.Authorization'JWT-Authorizer in HTTP API
HTTP API unterstützt nativ JWT-Authorizer ohne Lambda. Sie geben die URL des JWT-Ausstellers (Cognito, Auth0, Okta) und die Zielgruppe an, woraufhin API Gateway JWTs automatisch validiert. Dies entspricht im Wesentlichen einem Cognito-User-Pool-Authorizer, funktioniert aber auch mit jedem standardkonformen OIDC-Anbieter. Die Tokenvalidierung (Signatur, Ablauf und Zielgruppe) wird intern von API Gateway durchgeführt – mit geringerer Latenz als bei Lambda-Authorizern und ohne Lambda-Kosten.
aws apigatewayv2 create-authorizer \
--api-id 'abc123' \
--authorizer-type JWT \
--name 'JWTAuthorizer' \
--identity-source '$request.header.Authorization' \
--jwt-configuration '{
"Issuer": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXXXX",
"Audience": ["your-client-id"]
}'Cognito Identity Pools im Vergleich zu User Pools
Verwenden Sie für die API-Autorisierung Cognito User Pools: Sie verwalten die Benutzerauthentifizierung und stellen JWTs aus. Cognito Identity Pools (föderierte Identitäten) funktionieren anders: Sie tauschen Tokens von Drittanbietern (aus User Pools, Social-Logins oder SAML) gegen temporäre AWS-Anmeldeinformationen ein (über STS AssumeRoleWithWebIdentity). Identity Pools werden verwendet, wenn Ihre Anwendung direkt vom Client aus auf AWS-Services (S3, DynamoDB) zugreifen muss. Für die Authentifizierung bei API Gateway sind JWTs aus User Pools die richtige Wahl; Identity-Pool-Anmeldeinformationen sind für direkte Aufrufe des AWS SDK aus dem Browser oder von mobilen Geräten vorgesehen.
Ressourcenrichtlinien in API Gateway
REST APIs unterstützen Ressourcenrichtlinien – JSON-Richtlinien, die an die API angefügt werden und den Zugriff anhand von IP-Adresse, VPC-Endpunkt, Quellkonto oder ARN steuern. Verwenden Sie Ressourcenrichtlinien, um nur bestimmten IP-Bereichen den Aufruf Ihrer API zu erlauben, den Zugriff auf Anforderungen über einen bestimmten VPC-Endpunkt (private API) zu beschränken oder kontenübergreifende Aufrufe zu erlauben. Ressourcenrichtlinien funktionieren zusätzlich zu Authorizern auf Methodenebene – beide müssen die Anforderung erlauben, damit sie erfolgreich ist.
# Allow only specific IP range to call the API
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': '*',
'Action': 'execute-api:Invoke',
'Resource': 'arn:aws:execute-api:us-east-1:123456789012:abc123/*',
'Condition': {'IpAddress': {'aws:SourceIp': '203.0.113.0/24'}}
}]
}Beidseitige TLS-Authentifizierung
Beidseitiges TLS (mTLS) erfordert, dass sowohl der Client als auch der Server während des TLS-Handshakes Zertifikate vorlegen. API Gateway unterstützt mTLS für REST- und HTTP-APIs, wenn benutzerdefinierte Domainnamen konfiguriert sind. Clients müssen ein gültiges Zertifikat vorlegen, das von einer Zertifizierungsstelle (CA) signiert wurde, deren Zertifikat Sie in einem Truststore in S3 hochladen. mTLS wird im Finanzwesen, zur Authentifizierung von IoT-Geräten und bei B2B-Integrationen eingesetzt, wenn über tokenbasierte Authentifizierung hinaus eine starke Überprüfung der Clientidentität erforderlich ist.
Den richtigen Authorizer-Typ auswählen
Auswahl des Authorizers für die Prüfung SAA-C03: IAM (SigV4) → Aufrufe zwischen AWS-Services innerhalb desselben oder über mehrere Konten hinweg; Cognito User Pool → Web- und App-Benutzer, die über Cognito authentifiziert wurden; Lambda-Authorizer → benutzerdefinierte Authentifizierungslogik (Identitätsanbieter von Drittanbietern, Legacy-Tokenformate, OAuth-Introspektion, Kombination aus IP und Token); JWT-Authorizer (HTTP API) → OIDC-/OAuth2-Tokens mit jedem standardkonformen Anbieter, kostengünstiger als Lambda-Authorizer. Kein Authorizer → öffentliche API.
Schnelltest
Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.
Zusammenfassung der Lektion
In dieser Lektion haben Sie gelernt: Die IAM-Autorisierung (SigV4) ist für Aufrufe zwischen Services mit AWS-Anmeldeinformationen vorgesehen. Cognito-User-Pool-Authorizer validieren von Cognito ausgestellte JWTs nativ für Web- und mobile Apps. Lambda-Authorizer implementieren eine benutzerdefinierte Tokenvalidierung für Identitätsanbieter von Drittanbietern oder komplexe Autorisierungslogik, optional mit Caching der Ergebnisse. Als Nächstes behandeln wir Drosselung, Caching und Nutzungspläne in API Gateway.
Häufig gestellte Fragen
Ist die Lektion „Autorisierung: IAM, Lambda Authorizers und Cognito“ kostenlos?
Ja — der vollständige Text von „Autorisierung: IAM, Lambda Authorizers und Cognito“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cloud & IT Cert Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Autorisierung: IAM, Lambda Authorizers und Cognito“?
Sichern Sie API-Endpunkte mit IAM-SigV4-Signaturen, benutzerdefinierten Lambda Authorizers oder Amazon-Cognito-User-Pool-Authorizers. Du übst Cloud & IT Cert Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Cloud & IT Cert Prep zu starten?
Keine Vorkenntnisse erforderlich. Cloud & IT Cert Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.
Wie lange dauert die Lektion „Autorisierung: IAM, Lambda Authorizers und Cognito“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Cloud & IT Cert Prep-Lektion Code schreiben und ausführen?
Ja. Jede Cloud & IT Cert Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- REST API vs. HTTP API vs. WebSocket API
- Integrationen: Lambda, HTTP und Mock
- Autorisierung: IAM, Lambda Authorizers und Cognito
- Drosselung, Caching und Nutzungspläne