OAuth: przechowywanie tokena dostępu i tajemnicy

Question

Mamy wielu klientów, którzy używają naszego API do zasilania swoich stron internetowych.

Rozpocząłem rozmowę w pracy na temat używania protokołu OAuth do uwierzytelniania wywołań interfejsu API. Będziemy mieli przepływy zarówno dwu, jak i trójnożne.

W przypadku potrójnego kroku nie doszliśmy jeszcze do porozumienia co do sposobu przechowywania tokenu dostępu i sekretu.

Wspólnym podejściem do tego problemu byłoby przechowywanie przez klientów tokenu dostępu i tajnego klucza we własnej bazie danych, ale nie wchodzi to w grę, ponieważ klienci nie chcą zajmować się zmianami kodu i problemami z implementacją.

Inne opcje Rozważamy:

1) Zapisywanie i tajny token dostępu w pliku cookie

2) zapisywanie ich w sesji.

Nie jestem pewien, czy któryś z nich jest dobrym pomysłem. Czy ktoś ma jakieś sugestie?

Dziękuję.

Answer 1

Zakładam, że mówisz o typowym ustawieniu "Usługodawca", "Konsument" i "Użytkownik". Nie wiem, czy będziesz w stanie wprowadzić trzyetapową procedurę OAuth, jeśli Twoi Konsumenci (klient) nie wprowadzą żadnych zmian.

Sesja i pliki cookie działałyby na rzecz zapisywania tokenów, ale problem polega na tym, że to Konsument (klienci) musi je zapisać - nie ty. Połączenia z Twoim API odbywają się na zapleczu, więc nie ma prawdziwej sesji ani ciasteczka dostępnego w tym zakresie. Jeśli wywołujesz tylko połączenia JavaScript, być może to działa, ale nawet wtedy zwykle wywołania są wykonywane za pośrednictwem serwera proxy, aby uniknąć problemów z obsługą skryptów cross-domain.

W obu przypadkach, jeśli tokeny są przechowywane w sesji lub ciasteczkach, będą to klucze "tymczasowe", a Użytkownik będzie musiał ponownie uwierzytelnić się po wygaśnięciu sesji lub plików cookie. Ale nie ma w tym nic złego, o ile chodzi o specyfikację oAuth - o ile Użytkownicy nie mają nic przeciwko ponownemu uwierzytelnianiu.

Można odwołać Sample app for .NET written using MVC 5 Razor engine

Answer 2

jak Jason wspomniało, że nie jest to możliwe na wniosek konsumenta, aby uwierzytelnione żądania, jeśli nie przechowywać znaki potrzebne do autoryzacji - mogą przechowywać je w jakikolwiek sposób chcą, ale to jest potrzebną częścią równania. Może to być system plików, memcache, baza danych, pamięć.

Jedyny sposób, w jaki widzę używanie plików cookie do przechowywania tych plików, jest dla aplikacji konsumenckiej, aby ustawić te poświadczenia tokena jako plik cookie w przeglądarce użytkownika, a użytkownik może odesłać je do klienta z każdym żądaniem - jednak wydaje się to absurdalne po pierwsze, aplikacja konsumencka ponownie będzie musiała wprowadzić zmiany w swoim kodzie, aby poradzić sobie z tym, a po drugie, tajne klucze tokenu i tokena będą niepotrzebnie latać wokół sieci i przeglądarki użytkownika, co może stanowić lukę bezpieczeństwa, jeśli sam użytkownik zdecyduje się na hackować.

Answer 3

Miałem ten sam problem, gdy zaimplementowałem 3-legged oauth. Złożyłem wniosek online pod nr Google App Engine & używanego Google DataStore do przechowywania tokenów dostępu.

Limitem jest jednak wymienienie here do przechowywania danych & wrzucania zapytań! Jest to jedyne ograniczenie podczas korzystania z Google App Engine!

Answer 4

o 1) Zapisywanie i tajny token dostępu w pliku cookie

rozważyć klient w kafejce internetowej i co się dzieje po tym jak robi wyraźne ciasteczka i następna osoba ta kopiuje informacje?

pójdę do sesji DB lub PHP