Starałem się czytać jak najwięcej różnych odpowiedzi i postów, ale wciąż nie mogę się zdecydować na rozwiązanie, które pasuje do moich potrzeb. Próbuję wypracować najlepszy (najbardziej wydajny, ale w większości bardziej bezpieczny) sposób obsługi uwierzytelniania użytkowników, logowania się itp.

Mam serwer Node.js, działający na Expressie; Mam aplikację internetową Angular.js; i mam aplikację na iOS. Udostępniam API RESTful za pomocą Express / Node.js.

Ciasteczka

Pierwsze rzeczy, o których czytałem, mówiły o używaniu plików cookie, oraz o przechowywaniu identyfikatora sesji / tokenu logowania po stronie serwera (hashed) i po stronie klienta (unhashed). Klient przekazywałby ten identyfikator przy każdym żądaniu, serwer mieszałby go, analizował i odpowiednio przetwarzał żądanie. Nie wydaje się to RESTful (nie jest to ogromny problem), ale co ważniejsze, czy musiałbym powielić moje API: jedno dla uwierzytelniania nazwy użytkownika / hasła (np. Wykonane za pomocą curl) i jedno dla uwierzytelniania opartego na plikach cookie (np. Moja aplikacja internetowa)?

Kolejny problem z tym: co bym zrobił, gdybym miał wiele połączeń od jednego użytkownika, np. są zalogowani w dwóch przeglądarkach, iPhone i iPad. Czy moje przechowywanie identyfikatorów sesji musi być teraz tablicą?

Podstawowe uwierzytelnianie HTTP

Następnym pomysłem było użycie HTTP Basic Auth (z SSL), co wydaje się dość łatwe, ale nie jest zalecane, ponieważ trzeba przesłać nazwę użytkownika i hasło przy każdym żądaniu. Gdybym miał to zrobić za pomocą podstawowego uwierzytelniania HTTP, czy zapisałbym nazwę użytkownika i hasło w plikach cookie (lub lokalnym magazynie HTML), aby umożliwić działanie funkcji „Zapamiętaj mnie”? Czy mogę połączyć te dwa elementy: użyj podstawowego uwierzytelnienia HTTP dla rzeczywistych żądań (opublikuj nowy post, itd.) I po prostu użyj identyfikatora sesji zapisanego w pliku cookie dla początkowej sekwencji logowania / zapamiętaj aspekty?

Czy transmisja identyfikatora sesji jest bezpieczniejsza niż tylko przesłanie hasła użytkownika? W jaki sposób? Identyfikator sesji będzie działał rzekomo jako hasło, więc przesyłanie go będzie miało takie same problemy z bezpieczeństwem, jak przesyłanie hasła.

Wydaje się, że Basic Auth jest obsługiwany na wszystkich platformach, co jest idealne. Głównym minusem wydaje się być konieczność przesyłania danych uwierzytelniających klienta z każdym żądaniem. Czy istnieje sposób na złagodzenie tego problemu?

OAuth

OAuth wydaje się przesadą dla moich potrzeb. Myślę, że straciłbym możliwość wykonywania poleceń zwijania w celu przetestowania mojego interfejsu API. W jaki sposób OAuth jest ulepszeniem metody plików cookie?

Jak zapewne wiesz, jestem trochę zdezorientowany różnymi dostępnymi informacjami, więc jeśli masz zestaw dobrych linków - mających zastosowanie w tym scenariuszu - z przyjemnością je przeczytam. Próbuję znaleźć rozwiązanie, które pasuje do wszystkich platform, ale jest nadal tak bezpieczne, jak to możliwe. Ponadto, jeśli mam błędną terminologię, popraw mnie, ponieważ ułatwi mi to wyszukiwanie.

Dzięki.

Aktualizacja:

Myślałem o tym problemie i miałem pomysł. Proszę mi powiedzieć, czy to głupie / niepewne / jakiekolwiek opinie, ponieważ nie jestem pewien, czy to dobrze.

Kiedy użytkownik się loguje, generujemy losowy identyfikator sesji (solony itd.). Toopcjonalny identyfikator sesji jest wysyłany do klienta, który klient może przechowywać (np. w plikach cookie), jeśli zechcą; identyfikator sesji jest przechowywany w bazie danych.

Ten identyfikator sesji jest następnie opcjonalnie wysyłany z każdym żądaniem jako nagłówek uwierzytelniania HTTP lub ciąg zapytanialub klient może po prostu wysłać nazwę użytkownika i hasło, jeśli chce (co daje nam nasz regularny REST API). Na końcu serwera sprawdzamy najpierw parametr identyfikatora sesji, jeśli go nie ma, sprawdzamy nazwę użytkownika / hasło. Jeśli nie ma żadnego z nich - błąd.

Na serwerze sprawdzamy, czy identyfikator sesji jest powiązany z poprawną nazwą użytkownika. Jeśli tak, wypełniamy prośbę.

Za każdym razem, gdy użytkownik się loguje, tworzymy nowy identyfikator sesji lub usuwamy bieżący i wysyłamy go z odpowiedzią na żądanie do dziennika.

Myślę, że to pozwala mi używać regularnego API REST, gdzie to właściwe, z Basic Auth i utrzymywać sesje / zapamiętaj funkcjonalność. Nie rozwiązuje problemu wielu logów, ale poza tym myślę, że tak powinno być. Proszę daj mi znać.