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.comtak
POST-
api.example.com/login
gdzie po sukcesie
client.example.commoż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
akaPrzepł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.
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.
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
5 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
DotNetOpenAuth
http://dotnetopenauth.net/
dla dostawcy OAuth. Zamiast proponowanego przez Ciebie podejścia hybrydowego wykonujemy następujące czynności:
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
Potwierdzenie od:
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
Potwierdzenie od:
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
Potwierdzenie od:
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.
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
Potwierdzenie od:
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.