Aplikacja uwierzytelniająca po stronie klienta do REST API przy użyciu CORS ze strategią lokalną



Problem:
>
Zapewnij bezpieczny interfejs API aplikacji klienckiej przy użyciu tylko lokalnej strategii uwierzytelniania.
Czerwone strzałki to część luki w wiedzy.


Kontekst:
>
To znaczy - - -
client.example.com
tak

POST-
api.example.com/login

gdzie po sukcesie
client.example.com
może uzyskać dostęp do GET

-

usługa taka jak
api.example.com/secret
.

Pomysł!
>
Implementacja OAuth 2.0 z hybrydowym typem przydziału umieszczonym przed API.


Dlaczego hybryda?
  • Nie będzie to
    Niejawny przepływ przyznania
    aka
    Przepływ aplikacji internetowych po stronie klienta
    , ponieważ nie ma przekierowania do serwera API, który również zapewnia token dostępu. (to znaczy.) „Czy taki a taki jest możliwy dostęp do twoich danych "
  • Nie będzie to
    Przepływ hasła właściciela zasobu
    , ponieważ identyfikator klienta i klucz klienta są przekazywane wraz z żądaniem, więc zakłada się, że aplikacja kliencka znajduje się po stronie serwera.
OK ... a może trochę z obu?

Co by było, gdybyśmy użyli tokena CRSF podczas ładowania strony aplikacji klienckiej i POST ją z poświadczeniami użytkownika również z punktem końcowym uwierzytelniania OAuth 2.0, aby wymienić go na token dostępu? Każde kolejne żądanie uwierzytelniasz tokenem dostępu i tokenem CRSF po pomyślnym zalogowaniu.

Znalazłem niezłą bibliotekę Node.js OAuth 2.0

:
https://github.com/ammmir/node-oauth2-provider
https://github.com/ammmir/node-oauth2-provider

Pomóż mi!
>
Nie mogę znaleźć działającego przykładu środka uwierzytelniania, który rozwiązuje ten problem! Pokaż mi właściwy kierunek?

Ostatecznie celem również tutaj jest uwierzytelnienie aplikacji klienckiej w REST API przy użyciu CORS z lokalną strategią - tj. Nazwa użytkownika & amp; hasło - nawet jeśli powyższa umowa nie jest możliwa.


Aby dopasować nagrodę:
>To aplikacja kliencka, więc bądźmy na czasie.

Szukam praktycznego przykładu,


używając nasion Node.js OAuth 2.0 powyżej dla serwera API/Auth i struktury pierwszego planu, takiej jak

Angular.js

lub Backbone.js

,

zadawać pytania.

Przykład powinien pasować do kontekstu opisanego powyżej.

Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Pracuję nad aplikacją o dość podobnej architekturze, chociaż usługi to .NET Web API, a nie węzeł i używamy

DotNetOpenAuth
http://dotnetopenauth.net/
dla dostawcy OAuth. Zamiast proponowanego przez Ciebie podejścia hybrydowego wykonujemy następujące czynności:
  • x.com wyświetla stronę logowania
  • POST strony logowania zwraca poświadczenia do x.com
  • logika po stronie serwera w x.com łączy identyfikator client_id i client_secret z poświadczeniami, aby wysłać żądanie tokenu ( podaj poświadczenia hasła właściciela zasobu http://tools.ietf.org/html/rfc6749#section-4.3które masz wspomniano powyżej) odzyskanie tymczasowego tokena dostępu i tokena aktualizacje
  • token odświeżania jest zaszyfrowany w pliku cookie wysyłanym przez x.com
  • następnie zarówno plik cookie (z zaszyfrowanym tokenem odświeżania), jak i tymczasowy token dostępu są wysyłane do przeglądarki
  • aplikacja kliencka (w moim przypadku kątowa) może teraz używać tokena dostępu do wysyłania api.x.com do usług (wygląda na to, że doskonale zdajesz sobie sprawę z ograniczeń CORS ... zhakowaliśmy wersję kątową $resource http://docs.angularjs.org/api/ ... ourceżeby to było łatwiejsze, ale nie było to zbyt ładne, ponieważ chcieliśmy używać wszystkich czasowników HTTP i obsługiwać IE9)
  • po wygaśnięciu tokenu dostępu aplikacja kliencka może zażądać nowego tokenu dostępu od x.com
  • strona serwera x.com odszyfrowuje plik cookie, aby uzyskać token odświeżania i wysyła kolejne wywołanie Oauth dla nowego tokena dostępu

To dość wysoki poziom, ale miejmy nadzieję, że daje ci wyobrażenie, jak sobie poradzić w tej sytuacji. W moim przypadku, podobnie jak w Twoim, nie chcieliśmy używać stanu sesji lub bazy danych do przechowywania tokena odświeżania, ale oczywiście przekazanie go przeglądarce budzi obawy związane z bezpieczeństwem, dlatego szyfrowanie tokena odświeżania jest ważne (między innymi względami bezpieczeństwa) , a użycie pliku cookie eliminuje potrzebę utrzymywania stanu sesji lub innego trwałego przechowywania w x.com.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Zbudowałem ten przykład przy użyciu Node i PassportJS, aby pokazać, jak uwierzytelniać użytkowników za pomocą Facebooka lub lokalnej strategii. Obie strony znajdują się w różnych domenach, zgodnie z opisem, a to wymaga włączenia mechanizmu CORS.
GitHub: https://github.com/pablodenadai/Corsnection
https://github.com/pablodenadai/Corsnection
Live demo:

http://corsnection-client.herokuapp.com
http://corsnection-client.herokuapp.com/
/
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Brak odpowiedzi, Zdobywco nagród. Tylko moje 2 centy :)
Na moim serwerze internetowym
Uwierzytelniam się za pomocą połączenia zwrotnego z loginem/hasłem z podstawowym uwierzytelnianiem przez https. To wywołanie dostarcza klucz do klienta (jednostronicowa aplikacja internetowa).
Następnie każde kolejne wywołanie REST jest podpisywane kluczem. Serwer sprawdza poprawność podpisu i wszystko nadal dzieje się w https.
Uważam, że ten mechanizm jest dość używany.
Nie widzę problemu między domenami. Mam jedno źródło i jeśli potrzebuję czegoś z innego źródła, użyłbym JSONP.
Używam nginx jako mojego przekazującego https - & > http.
Nie wiem, jak konkuruje z rozwiązaniem OAuth2.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Nie mogę obiecać, że będę miał czas na napisanie działającego przykładu, ale mogę Wam pokazać 2 sposoby :)
Największą transakcją jest CORS. Po rozwiązaniu tego problemu korzystanie z usługi $ http będzie łatwiejsze. Tak więc pierwszym i prawdopodobnie najłatwiejszym może być skonfigurowanie odwrotnego proxy na serwerze WWW x.com, który wskazuje na api.x.com. Napisałem artykuł

tutaj
https://coderoad.ru/10304198/
Drugie podejście jest lepsze i zostało zaprojektowane właśnie w tym celu, aby umożliwić określonej domenie korzystanie z Twojego zasobu. Obejmuje to trochę kodowania w api.x.com, więc nie musisz niczego zmieniać w nowych aplikacjach internetowych obsługiwanych w innych domenach. Wystarczy autoryzować żądanie CORS w usłudze api.x.com.
  • Utwórz tabelę w bazie danych, w której możesz zarządzać listą autoryzowanych domen
  • Dodaj wpis „x.com” do tej tabeli
  • w api.x.com dodaj filtr/przechwytywacz żądań, niezależnie od tego, jakiego terminu technicznego używasz dla metody, która ma zostać wywołana po przetworzeniu żądania, i dodaj
    Access-Control-Allow-Origin: x.com
    , jeśli żądanie pochodzi z x.com (innymi słowy, sprawdź w nagłówku żądania, aby dopasować dowolną wartość z powyższej tabeli i umieść tę wartość w nagłówku odpowiedzi Access-Control-Allow-Origin).

To wszystko :) po tym, jeśli wiesz, jak używać

$http
http://docs.angularjs.org/api/ng.$http
lub

jQuey.ajax
http://api.jquery.com/jQuery.ajax/, będziesz mógł POST/PUT/DELETE/... każde żądanie do api.x.com z dowolnej autoryzowanej domeny w ciągu zaledwie kilku minut.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jestem bardzo podobny do pomysłu korzystania z aplikacji internetowej vinilla js i uwierzytelniania między domenami dla backendu GAE lub połączenia OpenID.
Aplikacja internetowa działa w sieci CDN. Po kliknięciu łącza logowania następuje przejście do odpowiedniego serwera logowania i przekierowanie z powrotem do aplikacji internetowej (przy użyciu tokena zabezpieczającego XSRF i tylko pliku cookie HTTPS). Serwer logowania akceptuje żądania między domenami

z księgowością
https://developer.mozilla.org/ ... tials
dane. Token XSRF należy ustawić (w nagłówku) przy każdym żądaniu. plik cookie przeglądarki. Ponieważ jest to tylko plik cookie HTTP, JS nie może go odczytać. Technika jest bardzo bezpieczna.
Po zalogowaniu możesz uzyskać bezpieczną ocenę z serwera logowania.
Możesz znaleźć szczegółowy opis

tutaj
http://dev.yathit.com/auth/ydn-login-client.html, i

REPO
https://bitbucket.org/ytkyaw/ydn-auth/wiki/Home
open source - tutaj.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się