{"id":14902,"date":"2022-02-21T12:03:42","date_gmt":"2022-02-21T11:03:42","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/how-to-engage-graphql-net-and-react-together-part-ii-veda-versum-backend-authentication\/"},"modified":"2022-05-16T16:03:52","modified_gmt":"2022-05-16T14:03:52","slug":"how-to-engage-graphql-net-and-react-together-part-ii-veda-versum-backend-authentication","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/how-to-engage-graphql-net-and-react-together-part-ii-veda-versum-backend-authentication\/","title":{"rendered":"GraphQL, .Net und React miteinander verbinden – Teil II: Veda Versum backend authentication."},"content":{"rendered":"
\r\n

 <\/p>\r\n

„If you optimize everything, <\/em>you will always be unhappy“ – \u00a0<\/em>Donald Knuth<\/a><\/p>\r\n<\/blockquote>\r\n

Mit einem guten Tool k\u00f6nnen Sie Aufgaben effektiv erledigen und dabei Spa\u00df haben. Es macht aber doppelt so viel Spa\u00df, das Werkzeug selbst zu entwickeln \ud83d\ude42<\/p>\r\n

Hallo, hier ist wieder Mikhail<\/a> von Centigrade. Im Blogartikel m\u00f6chte ich weiter unser Tool aufbauen – eine Wissensdatenbank namens Veda Versum<\/strong>. Der Artikel ist der zweite der Serie „GraphQL, .Net und React miteinander verbinden“. Im vorherigen Artikel<\/a> haben wir unsere Zielanwendung, Anforderungen und Architektur definiert. Wir haben .Net 6 f\u00fcr das Backend mit der Hot Chocolate<\/a> Library f\u00fcr GraphQL<\/a> API und React<\/a> als UI-Framework gew\u00e4hlt. Und wir haben das Ger\u00fcst f\u00fcr die Backend-Anwendung<\/a> erstellt. Jetzt ist es an der Zeit, unserem Backend Leben einzuhauchen.<\/p>\r\n

Heute werden wir dem Backend eine Authentifizierung hinzuf\u00fcgen. Wir werden die Datenpersistenz f\u00fcr unsere Anwendung definieren und implementieren, \u00fcber GraphQL-Resolver <\/em>und Datenlader <\/em>sprechen und ein paar Worte \u00fcber das Testen verlieren.<\/p>\r\n

Let’s go! \ud83d\ude09<\/p>\r\n

1.\u00a0\u00a0 Authentifizierung und Autorisierung<\/h2>\r\n

Im vorigen Artikel haben wir bereits besprochen, dass jeder Nutzer die Anwendung \u00f6ffnen, einige Wissenskarten erstellen, Karten lesen und andere Nutzer sehen kann, die gerade online sind. Nat\u00fcrlich soll unsere Veda Versum <\/strong>Anwendung jeden Nutzer pers\u00f6nlich kennen ?Wie Sie bereits wissen, ist die \u00fcbliche Art, sich in der IT-Welt „zu zeigen“, sich in das <\/strong>System einzuloggen<\/strong>. Ja, um dies zu tun, sollten Sie ein Konto mit Login und Passwort haben. Das ist nichts Neues. Wir m\u00fcssen die gleiche Funktionalit\u00e4t f\u00fcr unsere brandneue Anwendung bereitstellen. Aber wir werden das Rad nicht neu erfinden und das Verfahren zur Speicherung der Benutzerdaten nicht selbst einf\u00fchren. Wir werden das Standardprotokoll OAuth 2<\/a> verwenden, bei dem davon ausgegangen wird, dass wir bereits vorhandene Authentifizierungsserver f\u00fcr unsere Benutzer verwenden. Viele Anbieter wie Microsoft, Google, Twitter, Facebook und andere unterst\u00fctzen dieses Protokoll. Wenn Sie also Ihre eigene Benutzerverwaltung implementieren m\u00f6chten, aber keinen eigenen Authentifizierungsserver betreiben wollen, k\u00f6nnen Sie diese verwenden. Ein wichtiger Akteur in diesem Bereich ist Auth0<\/a>, der sich auf Authentifizierungsdienste spezialisiert hat. Aber da unser Team GitLab f\u00fcr die meisten unserer Projekte verwendet, haben wir alle ein Konto bei GitLab. Daher wird GitLab.com unser OAuth-Anbieter sein. Der Veda <\/strong>Versum-Benutzer muss also kein weiteres Konto erstellen, um sich in Veda Versum <\/strong>anzumelden, sondern kann ein bereits bestehendes Konto in GitLab verwenden. Unsere Anwendung leitet den Benutzer auf die Anmeldeseite von GitLab um. Nachdem der Benutzer seinen Benutzernamen und sein Kennwort eingegeben hat, wird er mit einem Authentifizierungs-Token zu unserer Anwendung zur\u00fcckgeleitet. Und unsere Anwendung funktioniert nur mit diesem Token.<\/p>\r\n

Soweit unsere Anwendung Frontend, Backend und GitLab als OAuth 2-Provider hat, wird das Authentifizierungsschema wie folgt aussehen:<\/p>\r\n

\"Authentication

Abb. 1: Authentifizierungsschema<\/p><\/div>\r\n

Das ganze Schema sieht ein bisschen kompliziert aus. Ich werde versuchen, alle Details zu erkl\u00e4ren und Sie Schritt f\u00fcr Schritt durch alle Prozesse zu f\u00fchren.<\/p>\r\n

1.1 Mutation der GitLab-Authentifizierung<\/h3>\r\n

Zuallererst m\u00fcssen wir OAuth auf der Einstellungsseite von GitLab einrichten. Folgt dieser Anleitung, um eine gruppeneigene Anwendung zu erstellen.<\/a> Als Ergebnis erhalten wir eine Anwendungs-ID <\/em><\/strong>und ein Geheimnis<\/em><\/strong>. Wir ben\u00f6tigen sie f\u00fcr die n\u00e4chsten Schritte.<\/p>\r\n

Dies ist der Link zur Gitlab OAuth API<\/a> zur Implementierung der Authentifizierung. Um die Schritte 2 und 4 aus Abbildung 1 <\/strong>zu implementieren, m\u00fcssen wir die GitLab-API-Methode oauth\/authorize <\/u><\/strong>aufrufen. Diese Methode wird von der Benutzeroberfl\u00e4che aus aufgerufen. Sp\u00e4ter m\u00fcssen wir f\u00fcr die Schritte 6 und 7 die Methode oauth\/token aufrufen<\/u><\/strong>. Und f\u00fcr die Schritte 8 und 9 – die Methode \/api\/v4\/user aufrufen<\/u><\/strong>.<\/p>\r\n

Das Frontend ist nicht unser heutiges Ziel, hier werden wir uns auf den Backend-Teil konzentrieren<\/strong>. Um die Schritte 5 bis 10 aus Abbildung 1 <\/strong>zu implementieren, m\u00fcssen wir eine brandneue Mutation in unserer GraphQL-API erstellen, die GiltLabUser-Informationen abrufen soll. Sie nimmt den GitLab Single-Use Auth Code <\/u>als Parameter und gibt ein gesichertes JWT-Token zur\u00fcck, das die Benutzerinformationen enth\u00e4lt. Diese Mutation wird die Implementierung der Schritte 6 – 9 aus Abbildung 1 <\/strong>beinhalten.<\/p>\r\n

Um das zu erreichen, m\u00fcssen wir unser Projekt so \u00e4ndern:<\/p>\r\n