Autoryzacja tokenów REST API

Question

Właśnie rozpocząłem rozwój mojego pierwszego API REST w .NET. Ponieważ będzie to bezpaństwowcem użyję tokeny do uwierzytelniania:

Podstawowa idea (System.Security.Cryptography):

• AES do szyfrowania + HMACSHA256 integralności
• dane symboliczne obiekt składać się będzie z właściwości: nazwa, data wydania i Timeout
• baza danych będzie posiadać nazwę użytkownika, hasło i mieszany HMAC hash

Login:

• sprawdzić, czy poświadczenia są ważne (nazwa użytkownika, porównaj zaszyfrowany hasło Wartość dB)
• jeśli jest prawdziwa, szyfrowania danych obiektów
• użycie HMAC na wygenerowane żeton i przechowywać go do bazy
• powrócić żeton (bez HMAC), aby użytkownik (cookie/string)

Zapytanie do metody, która wymaga uwierzytelnienia:

• użytkownik wysyła żeton z każdego żądania
• token rozszyfrowanej
• jeśli jest wygasł, błąd
• jeżeli nie upłynął użycie HMAC i porównać login + wygenerowany hash z db wartości
• jeśli db sprawdź poprawny, użytkownik jest uwierzytelniony

Sposób, w jaki to widzę, ma następujące zalety:

• nawet jeśli db jest comprosmised, że nie zawiera on rzeczywisty znacznik (hash nie można odwrócić ...)
• nawet jeśli atakujący ma żeton, nie może zwiększyć upływie pól aktualizujących ponieważ data ważności jest w token sam w sobie

Teraz po pierwsze zastanawiam się, czy to w ogóle dobre podejście. Poza tym nadal nie wiedziałem, gdzie przechowywać klucze AES i SHA256 na serwerze (czy powinienem je po prostu skasować? Jeśli umieściłem je w web.config lub użyłem klucza maszynowego to mam problem w przypadku ładuj zbalansowane serwery, ...).

I wreszcie, gdzie mam przechowywać wektory AES IV, ponieważ Crypto.CreateEncryptor wymaga tego do odszyfrowania? Czy to oznacza, że ​​użytkownicy muszą przesłać token + IV przy każdym żądaniu?

Mam nadzieję, że to ma sens i dziękuję za odpowiedź z góry.

UPDATE:

Ok, teraz zrobiłem kilka badań i zszedł z tego rozwiązania:

• żeton będzie zawierała pierwotnie określone dane (nazwa użytkownika, data wydania i timeout)
Wygenerowano token
• z encrypt-then-mac (zawiera on zaszyfrowane dane AES, wektor IV + znacznik tych 2 wartości do uwierzytelnienia, wygenerowany przy użyciu HMACSHA265)
• znacznik tokena być napisane do db
• użytkownik zostanie uwierzytelniony, jeżeli:
  • tag jest ważny (tokenu uwierzytelniania)
  • dane można odszyfrować
  • żeton nie upłynął jeszcze
  • tag odpowiada jeden napisany w bazie
  • użytkownik nie jest zablokowany w bazie (na żądanie unieważnienia tokenu)
• klucze będą przechowywane i n oddzielna sekcja web.config. Te same klucze muszą być na każdym serwerze (na zastosowaniu kursu)

nie używałem FormsAuthenticationTicket ponieważ w .NET są następujące kwestie:

• same klucze są używane do różnych celów (MachineKey na widok stanach, zasobów i formauthtickets)
• mac-then-szyfrowania, stosowanych przez .NET nie jest uważany as safe as encrypt-then-mac
• ma wbudowanego w sposób invalidate token before it is expired

Answer 1

To jest kontynuacja wątku komentarza pod pytaniem.

Wygląda na to, że jesteś trochę zdezorientowany co do tego, czym dokładnie jest OAuth, więc mam nadzieję, że mogę to wyjaśnić tutaj.

OAuth nie jest usługą sieciową lub czymś, co użytkownik spożywa. Jest to protokół opisujący sposób, w jaki witryna może uwierzytelniać użytkownika względem usługi, bez pozwolenia stronie na poznanie poświadczeń użytkownika. Jako korzyść uboczna większość usługodawców protokołu OAuth ma również usługę sieci Web, która pozwala przesyłać zapytania do informacji użytkownika, a uprawnienia do tego mogą być przyznawane w tym samym czasie.

Zwykle interesuje Cię wdrożenie OAuth z perspektywy strony (np. AcmeWidgets.com), aby użytkownik mógł zalogować się za pośrednictwem Facebooka, Google lub czegoś podobnego. Można jednak również wdrożyć stronę usługi (np. Tam, gdzie zazwyczaj byłby Facebook) i zezwolić innym na uwierzytelnianie się w stosunku do CIEBIE.

Załóżmy na przykład, że posiadasz usługę internetową, która pozwala stronom zewnętrznym dostarczać widżety marki Acme użytkownikom. Twoim pierwszym narzędziem zewnętrznym jest popularny MyBook.org. Przepływ będzie wyglądać mniej więcej tak:

1. Ktoś zaprasza użytkownika do korzystania z aplikacji "Acme Widgets" na swoim profilu MyBook.

2. Użytkownik klika przycisk, który przekierowuje do AcmeWidgets.com. URL wygląda mniej więcej tak:

   http://acmewidgets.com/oauth/user?r=http%3A%2F%2Fmybook.org%2Foauth%2Fclient&appid=12345

3. użytkownik jest proszony, czy chcą, aby umożliwić MyBook dostęp do swoich danych i widgety przepisu.
4. Użytkownik klika przycisk Tak, po czym Acme Widgets zauważa, że ​​użytkownik na to zezwolił.

5. Użytkownik zostaje przekierowany z powrotem do mybook, pod adresem URL tak:

   http://mybook.org/oauth/client?token=ABCDEFG

6. MyBook, po stronie serwera, teraz trwa to żeton i umieszcza wywołanie usługi WWW BACK AcmeWidgets:

   http://acmewidgets.com/oauth/validate?token=ABCDEFG&appid=12345&appsecret=67890

7. AcmeWidgets odpowiada z końcowym uwierzytelniania znak identyfikujący użytkownika.
8. Alternatywnie nie działa, co oznacza, że ​​użytkownik próbuje sfałszować token, lub odmówił pozwolenia lub innego warunku niepowodzenia.

9. MyBook z tokena, może teraz wywołać AcmeWidgets API:

   http://acmewidgets.com/api/provision?appid=12345&token=ABC123&type=etc

To wszystko jest znany jako taniec OAuth. Zauważ, że istnieje tutaj wiele zdefiniowanych elementów, takich jak adresy URL, sposoby kodowania różnych tokenów, czy tokeny mogą wygasnąć lub zostać odwołane, itp.

Mam nadzieję, że wszystko wyjaśnisz!