Zalety korzystania z uwierzytelniania hasła OAuth Udzielenie dostępu do tokenów Uwierzytelnianie

Question

Tworzę API dla aplikacji mobilnej używającej Rails 5. W tej chwili nie potrzebuję uprawnień trójstronnych, ponieważ API będzie używane tylko przez naszą własne aplikacje mobilne.

myślę o wyborze jednej z tych dwóch opcji:

1. odźwierny + opracować: można zaimplementować za pomocą OAuth 2.0 odźwierny, ale będę używał tylko Poświadczenia hasło Grant, przynajmniej dla teraz.
2. Moduł szynowy z własnym modułem ActionController::HttpAuthentication::Token + Devise: Wydaje się, że jest to prostsza droga.

Szczerze mówiąc, nie widzę różnicy między metodą Token Access Authentication a OAuth 2.0's Password Credentials Grant.

Jak wybrać jedną z nich nad drugą? Czy istnieje jakaś inna opcja, którą należy wziąć pod uwagę?

Answer 1

Obie są koncepcyjnie różne rzeczy:

• „Reklamowe Uwierzytelnianie dostępu” określa protokół opisujący, w jaki sposób (ewentualnie długowieczne) token powinien być prezentowane na serwer bezpieczny sposób. Nie mówi nic o tym, skąd pochodzi tenken ani jak należy go interpretować.
• "Przyznanie haseł z hasłem" jest częścią pełnoprawnego przepływu OAuth, opisującego sposoby uzyskania uzyskania (zazwyczaj krótkotrwałego) tokena.

W pewnym sensie można użyć funkcji Udzielanie poświadczeń haseł, aby uzyskać token za pomocą protokołu OAuth, a następnie użyć tego tokenu w nagłówku autoryzacji Token, aby uzyskać do niego dostęp.

Pojawia się pytanie - czy warto wykonać dodatkowy obieg wymiany danych (stałych i tajnych) dla tokena (tymczasowego), kiedy zamiast tego możemy użyć tokena (stałego i tajnego) przechowywanego w aplikacji do autoryzuj natychmiast.

Jak widzę, istnieją dwie potencjalne korzyści płynące z korzystania z pełnego przepływu OAuth. Po pierwsze, umożliwia naturalne dodawanie innych sposobów autoryzacji stronom trzecim. Po drugie, pozwala unieważnić token w dowolnym momencie i wymusić ponowną autoryzację za pomocą tych innych środków (oczywiście jeśli je wdrożysz) bez konieczności wymyślania jakichkolwiek kół.

Z drugiej strony, zawsze można dodać dodatkowe części "generujące token" później, gdy są potrzebne. Tak więc, jeśli twój obecny plan jest w stanie kodować poświadczenia w kodzie, podejrzewam, że prawdopodobnie lepiej jest polegać na autoryzacji Token.

jest nie tylko jeden wniosek krótsza, może być również nieco bardziej bezpieczny niż uwierzytelnianie Bearer stosowanych w OAuth: jeśli atakujący wącha się Bearer żeton, to oni (zazwyczaj) uzyskać pełny tokenu dostępu do serwera do momentu jej wygaśnięcia . Nie jest tak w przypadku tokenów Token (normalnie). Oczywiście nie ma to znaczenia, jeśli atakujący może wydobyć wspólny sekret z aplikacji.

Answer 2

Jeśli wszystko, co kiedykolwiek masz, to "interfejs API jednorazowego użytku" (tylko w przypadku aplikacji mobilnych), nie ma dużej różnicy w zakresie bezpieczeństwa.

Ale jeśli chcesz rozszerzyć ten interfejs API, aby mógł być używany przez zewnętrzne usługi, będziesz w znacznie lepszej pozycji z zaimplementowanym OAuth 2.0 za pomocą Doorkeepera, ponieważ możesz łatwo skonfigurować, na przykład, Kod autoryzacyjny Przydziel dla nich. Powiedziałbym więc, że opcja "Doorkeeper + Devise" jest bardziej przyszłościowa, ponieważ zapewnia więcej opcji, podczas gdy HTTP Token authentication jest znacznie prostsza do wdrożenia.