2011-12-15 6 views
24

Patrząc na Twitter OAuth Libraries, widziałem tę notatkę:Jak można nie ujawnić tajnego klucza za pomocą biblioteki OAuth JavaScript?

być ostrożnym podczas korzystania z OAuth JavaScript. Nie wystawiaj swoich kluczy.

Następnie, patrząc na jsOAuth examples, zauważyłem, że klucze są widoczne w kodzie.

Moje pytanie brzmi: jak to możliwe, aby nie narażać swoich kluczy podczas korzystania z biblioteki OAuth w JavaScript?

Dzięki.

AKTUALIZACJA: Ok, może jsOAuth nie jest odpowiednią biblioteką do użycia, ale jak można uwierzytelniać się z OAuth na pełnej stronie JavaScript?

+0

Zamiast dodawać nowe pytanie do tego wątku, powinieneś oznaczyć je jako rozwiązane i zamieścić nowe, szczególnie pytania nie są TAKIE PODOBNE. Odpowiedź na pytanie uzupełniające dostępna jest tutaj: [Bezpieczne OAuth w JavaScript] (http://stackoverflow.com/questions/6144826/secure-oauth-in-javascript) –

+0

Tytuł mojego pytania się nie zmienił. Może chcesz, żebym usunął notkę jsOAuth – rico

+0

Zaakceptuj odpowiedź już teraz ... :) –

Odpowiedz

10

Jak powiedział w dokumentacji związanej przez Ciebie:

napisany w JavaScript, jsOAuth ma być w pełni funkcjonalny open source OAuth biblioteki do użytku w środowisku Adobe AIR, Appcelerator Titanium i PhoneGap. W rzeczywistości, wszędzie tam, gdzie można używać javascript i ma cross-domain XMLHttpRequests. Ze względów bezpieczeństwa jsOAuth nie działa w przeglądarce. Przeglądarki są wymienione tutaj tylko do uruchamiania zestawu testów. Jeśli potrzebujesz jsOAuth w przeglądarce, napisz rozszerzenie.


Dobrą odpowiedź na twoje dodanej pytanie jest dostępny tutaj:

5

Jedynym naprawdę rozsądny sposób, w tej chwili, aby zrobić OAuth 1 w przeglądarce, polega na kierowaniu wywołań API za pośrednictwem serwera.

Po prostu nie ma sposobu, o ile zrozumiałem, wokół tego. Jeśli wykonasz OAuth 1.0a wywołania JavaScript z poziomu przeglądarki -> MUSISZ ujawnić tajny klucz klienta i tajny token dostępu, co najmniej użytkownikowi końcowemu.

Nie można przechowywać te poświadczenia w:

  • cookie, użytkownik może je znaleźć.
  • lokalna pamięć, użytkownik może je znaleźć (lepiej jednak niż ciasteczko, ponieważ nie powoduje wysyłania ciasteczka w kółko przez HTTP)
  • w javascriptu, użytkownik może je znaleźć (chociaż jest to prawdopodobnie najlepiej, ponieważ łatwiej jest ukryć).

Gdyby to był tylko tajny token dostępu, który byłby narażony na użytkownika końcowego, byłoby to znośne - ponieważ w rzeczywistości to on/ona uwierzytelnił twoją aplikację. Ale utrata tajemnicy klienta nie jest tak gorąca, oznacza to, że twoja aplikacja kwalifikuje się do kradzieży tożsamości. Może ktoś napisał aplikację, która twierdzi, że jest Twoją aplikacją.

Nawet jeśli sprawiłeś, że działa bezpiecznie w przeglądarce, utrudniają Cię blokowanie zabezpieczeń międzydomenowych.

2

Można również utworzyć skrypt, który prześle wszystkie niezbędne wartości i parametry do serwera w celu podpisania.

Podpisany adres URL można następnie odesłać do klienta (przeglądarki), który z kolei wykonuje rzeczywiste żądanie.

Zaimplementowałem OAuth 1.0a na Twitterze API w ten sposób, używając żądań jsonp. Zaletą tego jest to, że ciało odpowiedzi nie jest przekazywane przez serwer, oszczędzając przepustowość.

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

Powiązane problemy