Patrząc na Biblioteki Twitter Oauth widziałem tę Uwaga:

Bądź ostrożny przy użyciu JavaScript z Oauth. Nie wystawiaj kluczy.

Następnie, patrząc na JSOUTH Przykłady zauważyłem, że klucze są odsłonięte w kodzie.

Więc moje pytanie brzmi: jak można nie narażać kluczy podczas korzystania z biblioteki OAuth w JavaScript?

Dzięki.

Aktualizacja: OK, może JSOAUTH nie jest właściwą biblioteką, ale jak można wykonać uwierzytelnienie z Oauth na pełnej witrynie internetowej JavaScript?

24
rico 15 grudzień 2011, 17:10

3 odpowiedzi

Najlepsza odpowiedź

Jak powiedział w dokumentacji powiązanej przez Ciebie:

Napisany w JavaScript, JSOAUTH ma być w pełni funkcjonalnym open source Oauth Library do użytku w Adobe Air, Appcelerator Titanium i PhoneGap. W rzeczywistości, gdziekolwiek, aby JavaScript może być używany i posiada XMLHTTPREQUQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEQUEVERS. Ze względów bezpieczeństwa JSOAUTH nie działa w przeglądarce. Przeglądarki są tutaj wymieniane tylko do prowadzenia pakietu testowego . Jeśli potrzebujesz JSOAuth w przeglądarce, napisz przedłużenie.


Dobra odpowiedź na dodatkowe pytanie jest dostępne tutaj:

10
Community 23 maj 2017, 12:00

Jedynym naprawdę rozsądnym sposobem, teraz, aby zrobić Oauth 1 w przeglądarce, jest kierowanie apisów API za pośrednictwem serwera.

Po prostu nie ma sposobu, o ile to zrozumiałem, wokół tego. Jeśli wykonasz OAUTH 1.0A połączenia za pomocą JavaScript z przeglądarki -> Musisz wystawiać tajne konsumenta i uzyskać dostęp do tajny teken, do przynajmniej przez użytkownika końcowego.

Nie możesz przechowywać tych poświadczeń w:

  • Cookie, użytkownik może je znaleźć.
  • Lokalne przechowywanie, użytkownik może je znaleźć (lepiej niż ciasteczko, ponieważ nie pociąga za sobą wysyłania pliku cookie w tamtych czasach przez HTTP)
  • W JavaScript użytkownik może je znaleźć (chociaż jest to prawdopodobnie najlepszy zakład, ponieważ łatwiej jest niejasność).

Gdyby był tylko teken dostępowy, który był narażony na użytkownik końcowy, który byłby znośny - ponieważ jest w rzeczywistości, który uwierzytelnił twoją aplikację. Ale utrata tajemnicy konsumenta jest naprawdę tak gorąco, oznacza to, że Twoja aplikacja kwalifikuje się do kradzieży tożsamości. To ktoś inny mógł napisać aplikację, która twierdzi, że jest Twoją aplikacją.

Nawet jeśli zadziałałeś bezpiecznie w przeglądarce, jesteś utrudniony przez bloków bezpieczeństwa domeny.

5
Jon Nylander 15 grudzień 2011, 21:50

Możesz także wykonać skrypt, który wysyła wszystkie niezbędne wartości i parametry na serwer, aby wykonać podpisanie.

Podpisany adres URL można następnie wrócić do klienta (przeglądarki), która z kolei robi rzeczywiste żądanie.

Zaimplementowałem Oauth 1.0a na API Twittera w ten sposób przy użyciu żądań JSONP. Korzyść z tego jest to, że korpus odpowiedzi nie jest przekazywany przez serwer, oszczędzając przepustowość.

W ten sposób możesz mieć swój plik cookie i go jemy.

2
whitebrow 17 październik 2013, 11:34