2016-04-18 7 views
0

Wenn ein Benutzer nur auf sein Dataset zugreifen kann, warum ist IdentityId ein Feld, das für diesen API-Aufruf festgelegt werden muss (ref). Konnte die IdentityId nicht von den AWS-Anmeldeinformationen abgeleitet werden? Oder wenn sie nicht übereinstimmen müssen, bedeutet das technisch nicht, dass böswillige Benutzer auf diese Datenmenge zugreifen könnten, wenn sie die Cognito-ID des Ursprungsbenutzers hätten? Oder überprüft der Aufruf von ListDatasets die Cognito-ID erneut anhand des Tokens des Identitätsanbieters? In welchem ​​Fall sollte ich in meiner Website als Cookie zwischenspeichern, damit sich ein Benutzer nicht jedes Mal neu anmelden muss?Warum benötigen AWS CognitoSync ListDatasets IdentityId?

Momentan cache ich die CognitoId, aber ich mache mir Sorgen, dass, wenn ausgesetzt, dass Daten kompromittiert werden (oder Brute-Force-Angriff), und wenn es keine Sicherheitslücke ist, muss ich den Benutzer re haben - Jedes Mal, wenn sie ihre Daten synchronisieren möchten, gegen ihren Provider authentifizieren? Was ist die Lösung hier?

Jede Hilfe wäre willkommen.

Edit 1:
denke ich, was ich habe, ist ein Caching-Problem mit CognitoSync gefunden im Web-Browser und this question verwendet werden, die auf das gleiche Problem hinweisen. Hier ist der Authentifizierungsablauf, den ich erwarte:

  • Anmeldung bei Web Federated Auth Provider (OIDC, wie Google) => gibt temporäres Token zurück.
  • Verwenden Sie Token, um temporäre Anmeldeinformationen und IdentityId von Cognito zu erhalten.
  • Cache Etwas.
  • Aktivieren Sie CognitoSync Manager zum Synchronisieren.
  • Einige Zeit später:

    • die im Cache gespeicherte etwas Mit, Rerun-Synchronisation.

    Probleme:

    • Wenn ich die OIDC Provider-Token-Cache, kann ich die AWS-Anmeldeinformationen regenerieren, außer es nach 1 Stunde abläuft.
    • Wenn ich die AWS-Anmeldeinformationen zwischenspeichern, kann ich Sync erneut ausgeben, außer dass die Anmeldeinformationen ebenfalls ablaufen.
    • Wenn ich die IdentityId zwischenspeichern kann ich nicht synchronisieren, also was ich cache?

    Fazit:

    • Wenn AWS Credentials benötigt werden Synchronisationsaufruf zu erteilen, warum die listDatasets erfordern IdentityId wieder in den API-Aufruf kann nicht AWS CognitoSync Reverse Lookup die Anmeldeinformationen, um zu bestimmen, was die IdendityId diesen Zugangsdaten zugeordnet sind?
    • Funktioniert der [cognito sdk] (https://github.com/aws/amazon-cognito-js) tatsächlich?
    • Muss ich DynamoDB direkt zur Synchronisierung verwenden, wenn ich den Authentifizierungsfluss jedes Mal vermeiden möchte, wenn ein Benutzer synchronisieren möchte?
    • Es gibt einen [Caching-Provider] (http://docs.aws.amazon.com/AWSAndroidSDK/latest/javadoc/com/amazonaws/auth/CognitoCachingCredentialsProvider.html) für Android SDK, existiert so etwas nicht für den Browser? (Funktioniert das überhaupt?)
    • [Entwickler-Dokumentation] (http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityCredentials.html) Referenz Aktualisieren des Tokens, dies kann nur durchgeführt werden, wenn die aktuelle Token ist immer noch aktiv :(.

    Antwort

    0

    Es scheint zwei Fragen zu sein.

    • Cognito überprüft die AWS-Anmeldeinformationen anhand der IdentityId, sodass keine Sicherheitslücke vorliegt. Es macht jedoch immer noch keinen Sinn, dass die API diesen Parameter als Parameter enthält. Wahrscheinlich wird Amazon diese API aktualisieren müssen.
    • Das Problem, mit dem Sie konfrontiert sind, ist, dass der Identity-Provider eine Möglichkeit bietet, das erforderliche Zugriffstoken für jede Anfrageautorisierung zu erhalten, ohne dass der Benutzer jedes Mal Berechtigungen erteilen muss. Autorisieren Sie mit dem Anbieter und nehmen Sie dann das Zugriffstoken (oder id_token) und senden Sie es jedes Mal, wenn Sie synchronisieren möchten, Cognito als Login-Token für diesen Anbieter. Sie müssen eigentlich nichts zwischenspeichern.
    • Für Google sieht die Anfrage wie:
    
    
        var nonce = createNonce(); 
        setCookie('GoogleAuthNonce', nonce, 1); 
        var paramString = $.param({ 
         response_type:'id_token', 
         scope: 'openid', //email, profile', 
         client_id: GOOGLE_CLIENT_ID, 
         nonce: nonce, 
         login_hint: 'service_email_address', 
         prompt: 'none', 
         redirect_uri: 'http://service.com' 
        }); 
        window.location.href = `https://accounts.google.com/o/oauth2/v2/auth?${paramString}`; 
    
    
    0

    Es ist auch nicht ganz. Cognito wird die Identitäts-ID anhand der Identitäts-ID validieren, für die die AWS-Credentials erstellt wurden. Für Ihre Besorgnis über Spoofing würde es Benutzer nicht erlauben Ein Benutzer B-Sync-Daten zu erhalten, nur durch ihre Identität id wissen

    +0

    Wann, dass die Validierung auftreten, welche Daten im Browser zwischengespeichert werden, und wie sie im Cache gespeichert werden (zum Beispiel Cookies, lokal, spezielle AWS-Klasse)? –

    +0

    Es tritt während des API-Aufrufs auf der Serviceebene auf. Das SDK sollte die meisten Dinge (einschließlich ID und Anmeldeinformationen) für dich zwischenspeichern, warum fragst du? Tut es das nicht für dich? –

    +0

    Das einzige, was Sie verwalten müssen, ist das Provider-Token für zukünftige Aufrufe, um Anmeldeinformationen zu erhalten. –

    Verwandte Themen