在Google開發者控制檯中，當您創建OAuth 2.0中使用的新應用憑據並指定一個Web應用時，它會請求您註冊回調URI和JavaScript源。Google OAuth 2.0實施 - 註冊
我沒有準確的理解需要註冊這些。
對於回調URI，可能這會阻止向用戶呈現惡意頁面的第三方獲取授權碼。但是，客戶端ID和密碼仍然隱藏在應用程序服務器中，那麼惡意應用程序是不是無法做任何事情？
此外，如果回調URI已經註冊，那麼註冊JS起源的註冊分別完成了什麼。與回調URI註冊不同，OAuth 2.0規範沒有提及，這是Google選擇實施的。
謝謝你的幫助！
當您請求令牌時，該令牌將傳遞給回調URL。通過只允許您在API控制檯中配置的回調URL，您可以防止惡意用戶欺騙請求並將令牌發送給第三方。我懷疑你錯過的OAuth方面是回調是通過瀏覽器重定向發送的，所以很容易造成錯誤。
回調URL是OAuth服務器流程的一部分。
當您使用客戶端（Javascript）OAuth流程時，JS起源將發揮作用。他們確保任何OAuth請求都來自源自您網站的網頁。
服務器流量...
好吧，我想我明白多一點從閱讀的規範。 https://tools.ietf.org/html/rfc6749#section-10.6
這是爲了防止由用戶同一客戶端的攻擊，攻擊者可以在同一個客戶端創建一個帳戶，並啓動驗證流程，但他取代了重定向URI用自己的URI。
然後，他誘使受害人跟隨鏈接，授權他們正在使用的相同合法客戶端。但是，授權碼現在被髮送給攻擊者URI。
然後，攻擊者通過將驗證碼提供回客戶端來完成流程，客戶端使用該驗證碼來完成獲取令牌的流程。但是，該令牌可能與客戶端與攻擊者關聯，允許他冒充受害者。
同意，但爲了完整性：該攻擊不限於攻擊者是同一客戶端的用戶;任何攻擊者都可以這樣做 – 2014-12-26 19:40:49
Hey Hans，我不確定來自_different_ client的攻擊者如何獲取客戶端ID和密碼？這是我在上面的談話中的問題。規範中描述的攻擊採用相同的客戶端，因此有一組客戶端憑證。 – allstar 2014-12-27 21:07:20
好吧，也許我只是誤解了：我的意思是說攻擊者不需要在客戶端擁有一個**帳戶**（這通常是對同一客戶端的其他帳戶進行攻擊的好開始），但我猜想你的意思是「同一客戶的用戶」，攻擊者只是通過受害者想要使用的同一客戶端來應用攻擊;在後一種情況下，我同意 – 2014-12-28 08:20:01
關於服務器流中的回調URL，對令牌的請求還必須發送client_id和client_secret。所以沒有這些信息的令牌請求不會返回一個令牌。那麼是否存在安全性的損失？ – allstar 2014-09-24 21:27:49
p.s.感謝解決JS的起源 - 我不知道爲什麼你需要同時擁有JS起源和回調，但我看到谷歌有一個Web應用註冊頁面，將使用服務器/客戶端流量。 仍然希望瞭解預先註冊回調的附加安全性。謝謝！ – allstar 2014-09-24 23:51:49
在服務器流程中，客戶端詳細信息將從您的服務器通過https發送到Google。查看我添加到答案的流程圖。 – pinoyyid 2014-09-25 03:23:11