it-swarm.com.de

Mobile Authentifizierung mittels QR in einer Webanwendung

Ich habe Zweifel, was das richtige Schema für die nächste technische Lösung sein sollte ... Ich muss einen Benutzer in einer mobilen Anwendung durch Lesen eines QR-Codes authentifizieren, wobei der Benutzer zuvor in einer Webanwendung authentifiziert wurde.

Der Anwendungsfall besteht darin, dass der Benutzer eine Webanwendung verwendet, die sich in einem Intranet befindet, es muss jedoch möglich sein, Bilder von einem mobilen Gerät hochzuladen, das mit dem Internet verbunden ist .. Die mobile Anwendung wird eine öffentliche API verbrauchen, die für das Internet verfügbar ist das Internet über ein API-Gateway .. Das API-Gateway stellt eine Verbindung zum Backend her, um die Bilder hochzuladen. Wenn der Benutzer das mobile Gerät zum Erfassen und Hochladen von Bildern verwenden muss, sollte er sich nicht erneut authentifizieren , da sie eine offene Sitzung in der Webanwendung haben und einfach einen QR-Code verwenden, um das Gerät zu authentifizieren. Logischerweise verwendet der QR die Anmeldeinformationen des Benutzers nicht.

Meine Idee ist, Oauth 2.0 mit dem folgenden Ablauf für die Authentifizierung mobiler Geräte zu verwenden:

  1. Die Webanwendung fordert API Gateway auf, ein Autorisierungstoken zu generieren, und antwortet mit einer UUID.
  2. Die Webanwendung zeigt das Autorisierungstoken mithilfe eines vom API-Gateway erhaltenen QR an.
  3. Das mobile Gerät liest den QR-Code und fordert mit dem Autorisierungstoken ein Zugriffstoken für das API-Gateway an.
  4. Das API-Gateway überprüft das Autorisierungstoken und generiert das Zugriffstoken, das an das mobile Gerät zurückgegeben wird.
  5. Das mobile Gerät ruft die öffentliche API (API Gateway) mit dem Zugriffstoken auf.

Meine Frage ist, ob es das richtige Schema ist oder ob es eine andere Standardlösung gibt.

Vielen Dank!!

6
jlgr

Ihr Schema funktioniert, ABER es erreicht nicht sein volles Sicherheitspotenzial, da Sie ein neu generiertes Autorisierungstoken von einem bereits autorisierten Gerät direkt auf ein anderes übertragen können (über einen QR-Code, der von der Kamera gelesen wird). Diese Tatsache würde die Schritte 3 und 4 zu einer unnötigen Schwachstelle machen (es ist auch eine Redundanz, es gibt bereits ein Token!, warum ein anderes bekommen?);

Die folgende Alternative zusammen mit einer guten Kryptographie kann dazu führen, dass die Verbindung der später autorisierten Geräte nahezu unmöglich ist. Die Idee ist, dass Sie vor dem Senden der Daten in Schritt 5 eine symmetrische Verschlüsselungsschicht hinzufügen und einen Schlüssel verwenden, der über ein anderes Medium (das bereits autorisierte) ausgetauscht wird Gerät und Server) die verschlüsselten Daten dürfen niemals offengelegt werden;

schritt 3 Ersetzen: Lesen Sie das Autorisierungstoken.

schritt 4 Ersetzen: Überprüfen Sie die sichere Hash-Ableitung des Autorisierungstokens (anstelle des Tokens selbst) mit dem Server, um festzustellen, ob es gültig ist.

token0=read_auth_token_from_camera()
public_token=hash_function(token0) //the useless exposed token
if(check_token_with_server_for_authenticity(public_token)==true)
    continue_to_step_5() //it's authorized
else
    handle_the_scenario()

schritt 5: Ersetzen Sie Ihre Anforderung und Ihr Autorisierungstoken mit einer anderen Hash-Ableitung des Autorisierungstokens und rufen Sie die Server-API auf.

token2=another_hash_function(token0)
request="i am top secret data"
encryption_key=token0
encrypted_request=encryption_function( token2 + request , encryption_key)
send_to_server( public_token+encrypted_request)
//notice that token2 is unknown to the intruder because its encrypted,but it is known to the server; hence the authenticity of each request can be checked by the server;

wie ist es sicherer: Auf diese alternative Weise wird das tatsächliche Autorisierungstoken nie wirklich zwischen dem Server und dem neuen Client ausgetauscht. Wenn also ein Eindringling die SSl/TLS-Schicht hypothetisch brechen und das öffentliche Token erfassen könnte, kann der Eindringling keine Anforderungen in Ihrem Namen senden oder die Daten in Anforderungen ändern.

3
kamyar haqqani

Wenn dieses Schema Ihren gewünschten Anwendungsablauf erfüllt, ist es korrekt. Dies ist keine Standardmethode für die Authentifizierung von Android-Geräten, wenn Sie sich für eine selbst erstellte Authentifizierung entscheiden. 

Ich denke, Sie müssen hinzufügen, ob der Client tatsächlich Ihre Android-Anwendung ist und keine andere Anwendung, die einen ähnlichen Authentifizierungsfluss verwendet. Wenn Sie dies bieten können, ist es gut zu gehen.

2
Wijdan

Sie können das FireBase ML Kit für eine gute Lösung verwenden, und es kann auch eine Reihe von AI-basierten Funktionen für Ihre Apps ausführen. Sie können es hier überprüfen: https://firebase.google.com

0
Sujal Kumar