Ankündigung

Einklappen
Keine Ankündigung bisher.

REST-API Authentifikation

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • REST-API Authentifikation

    Hallo zusammen,
    ich arbeite mich gerade etwas in REST-APIs ein.
    Jetzt bin ich bei einfacher authentifizierung hängen geblieben.

    Ziel ist eine API, die am Ende sowohl über Web als auch über App für in einer Datenbank eingetragene Nutzer aufrufbar wird. REST-Prinzip eben.

    Ich habe eine Datei login.php welche entweder einen 200er header oder einen 401er header returnt.
    Wenn ich nun auf andere Bereiche der API zugreifen möchte, muss ich ja generell den Nutzernamen und das Passwort erneut mitschicken, oder?
    Ich habe zwar schon über OAuth gelesen, aber das scheint mir für so etwas doch etwas sehr umfangreich...
    Ist mein obiger Gedankengang mit der login.php richtig?

    Man liest ja durchaus immer wieder etwas über Sessions in REST-APIs, aber dies verstößt ja grundlegend gegen das REST-Prinzip.

    Wie gehe ich da nun korrekt vor?

    Danke allen schonmal!

  • #2
    Für gewöhnlich löst man das über eine Authentication-Middleware. Diese ist den entsprechenden API-Endpoints vorgeschaltet und prüft das vom Client gesendete Access-Token noch bevor das Request an den Controller weitergereicht wird. Ist das Access-Token ungültig wird das Request direkt abgewürgt und der Client erhält eine entsprechende Fehlermeldung ("access denied"). Middlewares werden von so ziemlich jedem halbwegs brauchbaren Framework unterstützt.
    [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

    Kommentar


    • #3
      Moin,

      das geht zum Beispiel so How to secure a REST API using JWT
      Kurz:
      - der Client führt zu Beginn die Authentifizierung durch
      - die API generiert einen Schlüssel für den Client und gibt ihn zurück
      - der Client hängt diesen Schlüssel an die weiteren Requests an
      [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
      [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

      Kommentar


      • #4
        Nein, nach dem Login erfolgreich war, kriegst du in der Regel ein Auth Token. Das ist halt eine Zufällig generierte Nummer. Dieser Token muss in jedem Request wo du ein User Bruachst, mitgesendet werden.

        Damit es nicht zu kompliziert wird, kannst du ja eine Token Tabelle anlegen mit folgenden Spalten

        token | session_id | expires

        token muss unique INDEX sein.


        Dein Prozess sieht dann so aus. Bei Requests wo du eine Authentizierung brauchst, fragst du immer nach ob ein token mit geschickt wurde, wenn nein, dann Fehler.
        Wenn ja, dann gucke nach ob zu dem Token eine Session_id gespeichert ist, wenn ja. übergebe diese an session_id($row->session_id);

        Damit kannst du dann mit REST und Session arbeiten.

        Natürlich musst du auch auf expires achten.
        apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

        Kommentar


        • #5
          Zitat von BlackScorp Beitrag anzeigen
          Nein, nach dem Login erfolgreich war, kriegst du in der Regel ein Auth Token. Das ist halt eine Zufällig generierte Nummer. Dieser Token muss in jedem Request wo du ein User Bruachst, mitgesendet werden.

          Damit es nicht zu kompliziert wird, kannst du ja eine Token Tabelle anlegen mit folgenden Spalten

          token | session_id | expires

          token muss unique INDEX sein.


          Dein Prozess sieht dann so aus. Bei Requests wo du eine Authentizierung brauchst, fragst du immer nach ob ein token mit geschickt wurde, wenn nein, dann Fehler.
          Wenn ja, dann gucke nach ob zu dem Token eine Session_id gespeichert ist, wenn ja. übergebe diese an session_id($row->session_id);

          Damit kannst du dann mit REST und Session arbeiten.

          Natürlich musst du auch auf expires achten.
          Das klingt doch mal sehr interessant!
          Würde das expires dann bei jedem neuen Aufruf überprüft werden und nach Überschreiten gelöscht, oder eher eine Datenbankroutine, die selbstständig unabhängig der API-Aufrufe prüft und löscht?

          Kommentar


          • #6
            Zitat von JohnHSmith Beitrag anzeigen

            Das klingt doch mal sehr interessant!
            Würde das expires dann bei jedem neuen Aufruf überprüft werden und nach Überschreiten gelöscht, oder eher eine Datenbankroutine, die selbstständig unabhängig der API-Aufrufe prüft und löscht?
            Ich würde es in einem Clean Up Cronjob leeren
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

            Kommentar


            • #7
              Eigentlich spart man sich die ganze Arbeit wenn man direkt mit JWT arbeitet (https://jwt.io/). Diese Token haben out-of-the-box ein Ablaufdatum und du kannst darin bspw. die User-ID zur weiteren Identifizierung hinterlegen. Eine eigene Datenbank-Tabelle ist dann nicht mehr notwendig. Mit https://github.com/firebase/php-jwt hast du auch direkt eine passende Library um mit JWT umzugehen (encode, decode).
              [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

              Kommentar


              • #8
                Zitat von BlackScorp Beitrag anzeigen
                Nein, nach dem Login erfolgreich war, kriegst du in der Regel ein Auth Token. Das ist halt eine Zufällig generierte Nummer. Dieser Token muss in jedem Request wo du ein User Bruachst, mitgesendet werden.

                Damit es nicht zu kompliziert wird, kannst du ja eine Token Tabelle anlegen mit folgenden Spalten

                token | session_id | expires

                token muss unique INDEX sein.


                Dein Prozess sieht dann so aus. Bei Requests wo du eine Authentizierung brauchst, fragst du immer nach ob ein token mit geschickt wurde, wenn nein, dann Fehler.
                Wenn ja, dann gucke nach ob zu dem Token eine Session_id gespeichert ist, wenn ja. übergebe diese an session_id($row->session_id);

                Damit kannst du dann mit REST und Session arbeiten.

                Natürlich musst du auch auf expires achten.
                Damit hälst du auf einem Server einen Zustand und verstößt gegen das RESTful Prinzip. Verstehe auch nicht was der Sinn dahinter sein sollte, da so einfach die Sessions auf Tokens umgemünzt werden.

                Drei verbreitete Ansätze:
                1) API Tokens und die einfach über HTTPS(!) Header mitsenden (dynamisch oder statisch generiert)
                2) OAuth
                3) JWT (as already mentioned)
                "Software is like Sex, it's best if it's free." - Linus Torvalds

                Kommentar


                • #9
                  Zitat von JaMa Beitrag anzeigen

                  Damit hälst du auf einem Server einen Zustand und verstößt gegen das RESTful Prinzip. Verstehe auch nicht was der Sinn dahinter sein sollte, da so einfach die Sessions auf Tokens umgemünzt werden.

                  Drei verbreitete Ansätze:
                  1) API Tokens und die einfach über HTTPS(!) Header mitsenden (dynamisch oder statisch generiert)
                  2) OAuth
                  3) JWT (as already mentioned)
                  Das habe ich doch geschrieben, um es einfach zu halten,ich gehe davon aus dass der TE bereits seine Applikation so geschrieben hat wie er es gewohnt ist, mit session und cookies usw.. damit er nicht jeden session zugriff umschreiben soll, kann er einfach API tokens zu session ids mappen. Er könnte auch direkt session ID als token nutzen doch dadurch könnte man session hijacking betreiben und das wäre nicht gut
                  apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                  Kommentar


                  • #10
                    Zitat von BlackScorp Beitrag anzeigen

                    Das habe ich doch geschrieben, um es einfach zu halten,ich gehe davon aus dass der TE bereits seine Applikation so geschrieben hat wie er es gewohnt ist, mit session und cookies usw.. damit er nicht jeden session zugriff umschreiben soll, kann er einfach API tokens zu session ids mappen. Er könnte auch direkt session ID als token nutzen doch dadurch könnte man session hijacking betreiben und das wäre nicht gut
                    Nein, ich habe tatsächlich noch keinerlei Authentifizierung oder Session-Handling betrieben, eben weil ich weiß dass das gegen das RESTful-Prinzip verstoßen würde.
                    Trotz allem Danke für die Infos!

                    Kommentar


                    • #11
                      Zitat von JohnHSmith Beitrag anzeigen

                      Nein, ich habe tatsächlich noch keinerlei Authentifizierung oder Session-Handling betrieben, eben weil ich weiß dass das gegen das RESTful-Prinzip verstoßen würde.
                      Trotz allem Danke für die Infos!
                      alles klar dann vergiss das mit der Tabelle
                      apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                      Kommentar


                      • #12
                        Zitat von BlackScorp Beitrag anzeigen
                        Er könnte auch direkt session ID als token nutzen doch dadurch könnte man session hijacking betreiben und das wäre nicht gut
                        Wenn jemand den Token erlangt, dann übernimmt er dadurch auch die Session. Und selbst wenn die Session ID direkt genutzt wird, so ist das Risiko für Session Hijacking gleich groß wie bei klassischen Websites mit Sessions.
                        Bei deiner Implementierung müsste darauf geachtet werden, dass die Sessions den gleichen Timeout haben wie die Tokens und auch dass Sessions nicht automatisch gestartet/geladen werden.
                        "Software is like Sex, it's best if it's free." - Linus Torvalds

                        Kommentar


                        • #13
                          Sorry dass ich das nochmal ausgrabe, war die letzten beiden Monate sehr im Stress.

                          Verstößt nicht auch das ganze Token-Handling gegen das RESTful-Prinzip? Immerhin müssen ja dafür die Tokens temporär auf dem Server gespeichert werden...

                          Kommentar


                          • #14
                            Tokens an sich nicht, insofern diese aus der Datenbank kommen. Sobald diese aber irgendwie an Sessions (oder einer Reimplementierung selbiger) geknüpf sind schon.
                            "Software is like Sex, it's best if it's free." - Linus Torvalds

                            Kommentar

                            Lädt...
                            X