我正在爲我的API實現服務器端OAuth。 我見過here，Google允許完整的JavaScript編寫應用程序使用其API。OAuth完全Javascript訪問，安全問題？
在這種情況下，由於我們處於「查看源」環境，因此我們沒有使用客戶端密鑰，因此我們無法確定應用程序標識。
例如： 如果我看到一個完整的JavaScript的谷歌應用程序，我只需要查看源代碼，獲取客戶端密鑰，並在我自己的網站上放置一個編輯版本的代碼。 如果用戶已經接受了第一個網站上的應用程序，我將能夠使用他的數據（因爲應用程序被接受，接受部分對用戶來說是完全不可見的）。
即使用戶必須重新接受該應用，如果他接受該應用，我也將擁有第一個應用身份的訪問權限。
我對這種方法感到有些害怕，我很驚訝Google不會在文檔中或授權階段暴露不同的風險。 我必須錯過一些東西......你能幫我嗎？
我不太清楚，如果我讓我理解，但如果您有任何問題，請詢問。
（對不起，我的英語）
你說得對。在您的應用程序中可見的數據是client id和client secret。當用戶對您的應用程序進行身份驗證時，您會得到一個access token，您必須將其用於以下API請求。訪問令牌通常存儲在本地數據庫中，對每個用戶都是唯一的（甚至可能會過期）。
後果：有訪問client id一個邪惡的用戶和client secret必須重新接受申請去訪問它。他不能直接訪問它，因爲他沒有access token。但接受後，他可以訪問所有數據。
解決此問題的一種方法是在服務器端執行授權。您的服務器執行初始授權並存儲access token。當您想從客戶端訪問API時，您可以從服務器獲取access token（，通過安全連接），並且您應該能夠正常使用API，並且您的client id和client secret處於隱藏狀態。一個簡單的方法來實現這將是Yahoo Query Language。
我也很擔心它，而且我正在閱讀很多東西以使它變得舒適。實際上，有很多web服務器允許純JavaScript訪問（例如facebook，google，mercadolibre）。
這些公司要求您提供有效的域名服務器名稱，即您的客戶端ID和客戶端密鑰只有在您的網絡應用程序提出請求時纔可以使用。這就是說，我太舒服一點了。僞造你的應用程序並不容易，你11歲的侄子會嘗試一段時間。
無論如何，我知道你可以對瀏覽器使用某種釣魚攻擊，使他們相信你在「your-app-domain.com」。我不確定這些上述公司如何過濾這種攻擊。
想法：我有一個想法可以將您的憑據存儲在cookie中。在應用程序的開始處使用REST URI並將您的憑證存儲在那裏。只要我知道有可能用很少的黑客訪問cookie，但它會是一個額外的障礙。
思維2：我不是一個移動開發者，所以我讓我問：如何在移動應用程序中解決這個問題。即使知道去解編一個應用程序並不容易，但這樣做是正確的。
我不知道如何解決/與客戶端憑證存儲相兼容，但我希望爲本次討論做出貢獻。