Pytanie Pytania dotyczące korzystania z własnego API za pomocą protokołu OAuth


Tworzę interfejs API RESTful dla projektu, nad którym pracuję i chciałbym, aby główna aplikacja korzystała z interfejsu API, ponieważ:

  1. Spowoduje to posiadanie jednego zestawu kodu do utrzymania
  2. Jeśli zdecydujemy się na udostępnienie interfejsu API dla zewnętrznych programistów, zostanie to już zrobione
  3. Daje możliwość tworzenia aplikacji mobilnych, które go zużywają
  4. Naprawdę chcę się nauczyć, jak to zrobić

Interfejs API będzie hostowany na poddomenie https://api.example.com a główna aplikacja internetowa będzie hostowana w domenie głównej https://example.com.

Pojęciowo rozumiem, jak wszystko działa, ale moim głównym pytaniem jest to, jak zmieni się przepływ uwierzytelniania, jeśli w ogóle. Zwykle aplikacje innych firm:

  1. Uzyskaj token żądania od https://api.example.com/request_token
  2. Przekieruj użytkownika do uwierzytelnienia https://api.authenticate.com/authorize
  3. Zostanie przekierowany z powrotem do aplikacji innej firmy
  4. Uzyskaj token dostępu z https://api.example.com/access_token

Ponieważ kontroluję obie domeny, mogę zrobić coś podobnego do:

  1. Uzyskaj token żądania, gdy użytkownik wejdzie na ekran logowania https://www.example.com
  2. Użytkownik uwierzytelnia za pomocą formularza na https://www.example.com który wywołuje ten sam kod co https://api.example.com/authorize
  3. Jeśli poświadczenia są prawidłowe, token żądania jest zamieniany na token dostępu
  4. Token dostępu jest zapisywany w sesji i wygasa, gdy użytkownik wylogowuje się w normalny sposób

Krok 3 wydaje się błędny, ponieważ wystąpi zduplikowany kod, ale nie otworzy mnie to na ataki XSS to formularz logowania https://www.example.com wysłał dane do https://api.example.com ponieważ są technicznie różne domeny?

Czy nadmiernie komplikuję to?


28
2017-12-15 22:07


pochodzenie




Odpowiedzi:


Natknąłem się na ten sam problem i rozwiązałem go w ten sposób.

1 W przypadku aplikacji innych firm, korzystających z mojego interfejsu API, muszą oni uwierzytelniać się za pośrednictwem protokołu OAuth we wszystkich żądaniach.

2 Dla moich własnych klientów zewnętrznych (mobilnych, AIR itp.) - używają OAuth, z tą różnicą, że zezwalam na wysyłanie nazwy użytkownika i hasła bezpośrednio w kroku autoryzacji (dzięki czemu mogę utworzyć natywne okno dialogowe logowania). Zapewni to, że Twój interfejs API jest połączony z SSL / HTTPS.

3 W przypadku mojej aplikacji internetowej używam uwierzytelniania plików cookie w celu uzyskania dostępu do interfejsów API. Np. Po zalogowaniu użytkownik może po prostu wywołać API: adresy URL i odzyskać JSON / XML. Miło jest również za szybkie zapoznanie się z interfejsami API (chociaż prawdziwa konsola API, taka jak APIGee, wykonuje tam lepszą pracę).


20
2017-12-16 17:49



Czy możesz rozwinąć temat 3? Kiedy użytkownik loguje się, czy zapisujesz identyfikator sesji w pliku cookie, a następnie używasz go jako tokenu dostępu pseudo-dostępu, gdy wywołujesz interfejs API, a następnie sprawdzasz go po otrzymaniu żądania API? Wygląda na to, że byłaby to luka w zabezpieczeniach ... - Steve
W zasadzie tak. Ale jak to jest ta luka? Nie używam protokołu OAuth podczas wywoływania interfejsów API z aplikacji internetowej. Jeśli jesteś zalogowany (ustalony na podstawie sprawdzania poprawności pliku cookie) - interfejsy API są dostępne po prostu przez wywołanie adresu URL. Zapomniałem jednak, że obsługuję API: s do aplikacji internetowej w tej samej domenie. - Jon Nylander
Sądzę, że tak długo, jak nie polegasz wyłącznie na identyfikatorze sesji, aby zidentyfikować użytkownika po stronie serwera, tak nie jest. Myślałem, że możesz się otworzyć Przejęcie sesji, ale jest piątek po szkole i jestem zmęczony. Na podstawie twoich odpowiedzi na inne pytania jesteś zdecydowanie bardzo kompetentnym facetem! Dzięki za pomoc! - Steve
Oczywiście, sesyjne ciasteczko powinno być transmitowane przez SSL, mieć naprawdę długą i niezwykle losową wartość, która jest odnawiana za każdym razem, wygasa, jeśli użytkownik jest nieaktywny przez określony czas, itd. Itd. Ale biorąc pod uwagę, że przetwarzasz pliki cookie sesji poprawnie. . Powinieneś być gotowy do drogi. - Jon Nylander
W jaki sposób upewnić się, że podczas korzystania z hasła dostępu do nazwy użytkownika ktoś nie tylko dekompiluje aplikację mobilną, nie ukradnie kluczy i podszyje się pod aplikację? Czy to nieuniknione? - untitled


Powiedziałbym, że trochę komplikujesz. Jeśli twój kod jest właściwie podzielony, możesz łatwo zbudować cienką warstwę REST na warstwie usługi aplikacji, jednocześnie kontrolery aplikacji będą cienką warstwą w warstwie serwisowej.


0
2017-12-16 12:42



Co masz na myśli przez warstwę usługi? Czy to modele wewnątrz kontrolerów wykonują wszystkie ciężkie operacje podnoszenia? Jeśli tak, to jest to mój plan - to naprawdę bit uwierzytelniania, który rzuca mnie na pętlę. Chcę przenieść całą logikę biznesową do oddzielnej subdomeny interfejsu API, ponieważ będziemy musieli ją udostępnić do tworzenia aplikacji mobilnych, a ja myśleć to pomoże mi w skalowalności w tym sensie, że mogę obrócić w górę lub w dół liczbę głupich klientów łączących się z API i po prostu mieć centralne API do obsługi wszystkich buforowania danych. Jednak nie wiem jeszcze wiele o skalowalności ... - Steve