您需要了解的有關 OAuth2 和使用 Facebook 登錄的信息

已發表: 2022-03-10
快速總結↬ OAuth2 使用戶可以輕鬆登錄您的應用程序,無需記住每個網站的密碼,並信任您的安全性。 OAuth2 在行業中占主導地位,因為沒有其他安全協議可以接近 OAuth2 的採用。

如果您想知道 OAuth2 是什麼,它是允許任何人使用其 Facebook 帳戶登錄的協議。 它為應用程序和各地網站上的“使用 Facebook 登錄”按鈕提供支持。

本文將向您展示“使用 Facebook 登錄”的工作原理,並解釋其背後的協議。 您將了解為什麼要使用 Facebook、Google、Microsoft 或支持 OAuth2 的眾多其他公司之一登錄。

本文將向您展示“使用 Facebook 登錄”的工作原理,並解釋其背後的協議。 您將了解為什麼要使用 Facebook、Google、Microsoft 或支持 OAuth2 的眾多其他公司之一登錄。

我們將看兩個例子:為什麼 Spotify 使用 Facebook 讓您登錄 Spotify 移動應用程序,以及為什麼 Quora 使用 Google 和 Facebook 讓您登錄其網站。

關於 SmashingMag 的進一步閱讀

  • 構建移動應用程序的四種方法
  • 如何構建誠實的用戶界面並幫助用戶做出更好的決策
  • 讓您的 Android 應用在發布後保持流行
  • Spotify 播放列表為您的編碼和設計課程加油
跳躍後更多! 繼續往下看↓

在 OAuth2 之前

幾年前,OAuth2 贏得了一場標準大戰。 它是主要供應商支持的唯一身份驗證協議。 Google 為其所有 API 推薦 OAuth2,而 Facebook 的 Graph API 僅支持 OAuth2。

了解 OAuth2 的最佳方式是查看它之前的內容以及為什麼我們需要不同的東西。 這一切都始於基本身份驗證。

基本認證

身份驗證方案關注兩個關鍵問題:你是誰? 你能證明嗎?

問這兩個問題的最常見方法是使用用戶名和密碼。 用戶名說明你是誰,密碼證明了這一點。

Basic Auth 是第一個 Web 身份驗證方案。 這聽起來很有趣,但“基本身份驗證”是它在 1999 年首次發布的規範中的實際名稱。

基本身份驗證允許 Web 服務器以瀏覽器理解的方式請求這些憑據。 服務器返回一個 HTTP 響應代碼401 (這意味著需要身份驗證),並在響應中添加一個名為WWW-Authenticate的特殊標頭,其特殊值為Basic

當瀏覽器看到此響應代碼和此標頭時,它會顯示一個彈出登錄對話框:

基本身份驗證登錄對話框
基本身份驗證登錄對話框

Basic Auth 的優點在於它的簡單性。 您不必編寫登錄屏幕。 瀏覽器處理所有這些,只需將用戶名和密碼發送到服務器。 它還使瀏覽器有機會專門處理密碼,無論是通過為用戶記住密碼、從第三方插件獲取密碼還是從操作系統獲取用戶憑據。

缺點是您無法控制登錄屏幕的外觀。 這意味著您無法設置樣式或添加新功能,例如“忘記密碼?” 鏈接或創建新帳戶的選項。 如果您想要更多自定義,則必須編寫自定義登錄表單。

自定義登錄表格

自定義登錄表單為您提供所需的所有控制。 您編寫一個 HTML 表單並提示輸入憑據。 然後,您提交表單並以您想要的任何方式處理登錄。 您可以完全控制:您可以設置樣式、詢問更多詳細信息或添加更多鏈接。

一些網站,例如 WordPress,使用簡單的登錄屏幕形式:

WordPress 登錄屏幕
WordPress 登錄屏幕

LinkedIn 允許用戶在同一頁面上登錄或創建帳戶,而無需轉到網站的其他部分:

LinkedIn登錄屏幕
LinkedIn 登錄屏幕(查看大圖)

基於表單的登錄非常流行,但它有一個主要的根本問題:用戶必須告訴網站他們的密碼。

保守秘密

在安全圈中,我們稱密碼為機密。 這是一條只有你擁有並證明你是你的信息。 秘密也可以不僅僅是密碼; 我們稍後再談。

一個網站可以採取世界上所有的安全措施,但如果用戶共享他們的密碼,那麼這種安全性就消失了。 黑客在 2010 年入侵了 Gawker 網站,暴露了許多用戶的密碼。 雖然這對 Gawker 來說是個問題,但問題並不止於此。 大多數人重複使用密碼,因此黑客從 Gawker 獲取洩露的數據並試圖登錄更重要的網站,例如 Gmail、Facebook 和 eBay。 任何將 Gawker 密碼用於更重要事情的人所失去的遠比關於 Hulk Hogan 性愛錄像帶的最新八卦要多得多。

確保您的用戶不會為多個帳戶重複使用密碼是問題的前半部分——而且這是不可能的。 只要人們必須在互聯網上創建不同的帳戶,他們就會重複使用他們的密碼。

問題的後半部分是安全地存儲密碼。

當有人登錄你的應用程序時,你需要驗證他們的密碼,這意味著你需要一個副本來驗證它。 您可以將所有用戶名和密碼存儲在某個數據庫中,但現在您可能會丟失這些密碼或被黑客入侵。 最佳實踐是使用散列函數,例如 SHA-2 函數之一。 此函數以您永遠無法取回的方式加密數據,但您可以復制加密:“我的密碼”每次都會散列為bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2之類的內容。

現在我們已經離開了高草:我告訴你如何實現加密協議。 接下來,我將不得不解釋如何在您的數據中添加鹽,以及要閱讀哪些關於中間人攻擊的教科書。 你想做的只是寫一個應用程序,現在你必須成為一名安全專家。 我們需要退後一步。

OAuth2

您可能不是安全專家。 即使你是,我仍然不會相信你的密碼。 OAuth2 為您提供了更好的方法。

例如,我在 iPad 上使用 Spotify。 我每月付給公司 10 美元聽音樂。 Spotify 只允許我在三台設備上訪問,所以我需要一個密碼來確保沒有其他人使用我的帳戶。 我的 Spotify 帳戶不是一個大的安全問題。 被黑不會是世界末日,但公司確實有我的信用卡,所以我想確保我是安全的。

我幾乎沒有登錄過 Spotify,所以我不想創建另一個帳戶並且必須記住另一個密碼。 Spotify 給了我一個更好的選擇:

帶有 _Log in with Facebook_ 選項的 Spotify 登錄屏幕
帶有“使用 Facebook 登錄”選項的 Spotify 登錄屏幕(查看大圖)

我可以使用我的 Facebook 帳戶登錄。當我點擊該按鈕時,Spotify 會將我發送到 facebook.com,然後我在那裡登錄。 這似乎是一個小細節,但卻是整個過程中最重要的一步。

Spotify 的 Facebook 登錄屏幕
Spotify 的 Facebook 登錄屏幕(查看大圖)

Spotify 的程序員本可以自己編寫登錄表單,然後使用後端 API 將我的用戶名和密碼發送到 Facebook,但我不希望他們這樣做有兩個重要原因:

  • 我不信任 Spotify 的 Facebook 密碼。 我使用 Facebook 與朋友聯繫,我不想被黑客入侵。 我不相信 Spotify 會正確處理密碼。 我也不相信它會避免用它做一些有趣的事情的誘惑。 也許它會嘗試存儲它以便以後可以使用它。 也許它有一個錯誤,會在將其發送到 Facebook 之前將其寫入某個文件,因此黑客可以抓住它。 對不起,Spotify; 我只是不是那種信任的人。
  • 我不想讓 Spotify 做所有事情。 我想讓 Spotify 播放音樂。 當我聽辣妹的時候,我不想把它貼到我朋友的牆上。 我也不想讓它下載我的朋友列表並讓他們加入 Spotify。 如果我給 Spotify 我的 Facebook 密碼,那麼它可以在 Facebook 上以我的身份登錄; 它可以做我能做的任何事情。

Spotify不想這樣做還有兩個重要原因:

  • Facebook 有多種登錄方式可供我選擇。 我可以使用我的用戶名和密碼登錄,也可以使用 Facebook 應用程序登錄。 我還可以從 Facebook 找回密碼或獲得 Spotify 無法提供的幫助。 如果我只是給 Spotify 我的密碼,我不會得到任何這些選項。
  • 我的秘密可能不是密碼。 . 密碼對於我每月 10 美元的 Spotify 帳戶來說足夠安全,但對於我的銀行或更重要的東西來說可能還不夠。 我可以提供許多其他秘密:我可能有一張智能卡,或者我可能生活在碟中諜電影中並使用視網膜掃描儀。

我不在《碟中諜》電影中,但在現實世界中,許多公司使用雙因素身份驗證,例如密碼和其他東西。 最常見的方法是使用手機。 當您想登錄時,公司會向您發送一條帶有特殊代碼的文本,該代碼持續幾分鐘; 然後您輸入代碼或使用應用程序輸入代碼。

現在,該公司確信沒有人可以在沒有您手機的情況下登錄您的帳戶。 如果有人竊取了您的密碼,他們仍然無法登錄。只要您不丟失手機,一切都是安全的。

Facebook 不是唯一的 OAuth2 提供商。 當我使用我的 Google 帳戶登錄 Quora 時,Google 會告訴我 Quora 想要做什麼並詢問是否可以:

Google Quora OAuth2 流程的第 2 步對話框
Google 和 Quora OAuth2 流程的第 2 步對話框

我可能允許 Quora 查看我的電子郵件地址和我的基本個人資料數據,但我不希望它管理我的聯繫人。 OAuth2 向我展示了 Quora 想要的所有訪問權限,允許我選擇我授予訪問權限的內容。

所以,這些就是 OAuth2 的優點。 讓我們看看它是如何工作的。

OAuth2 的工作原理

Facebook、Google 和大多數其他 OAuth2 提供商對待本地客戶端和 Web 客戶端的方式不同。 原生客戶端被認為更安全,它們獲得的令牌和刷新令牌可以持續數月。 Web 客戶端獲得的令牌要短得多,通常在用戶關閉瀏覽器或有一段時間沒有點擊網站時超時。

在這兩種情況下,登錄過程是相同的。 不同之處在於用戶需要通過它的頻率。

OAuth2 登錄遵循以下一般步驟:

  1. 用戶嘗試做一些需要身份驗證的事情。 這可以像打開應用程序或單擊“登錄”按鈕一樣簡單。
  2. 應用程序或網站確定用戶尚未登錄並開始登錄過程。 它通過打開一個網頁並將其發送到 Facebook、Google 或任何其他提供 OAuth2 的網站上的特殊 URL 來實現這一點。

為 OAuth2 提供者打開一個新的瀏覽器窗口是關鍵的一步。 這就是允許提供商顯示他們自己的登錄表單並詢問每個用戶他們需要的任何登錄信息的原因。 大多數應用程序使用嵌入式 Web 視圖來執行此操作。

除了提供商的登錄 URL,您還需要發送一些 URL 參數來告訴提供商您是誰以及您想做什麼:

  • client_id這告訴 OAuth2 提供者您的應用程序是什麼。 您需要提前註冊您的應用以獲取客戶端 ID。
  • redirect_uri這告訴提供者你完成後想去哪裡。 對於一個網站,這可以返回到主頁; 本機應用程序可以轉到關閉 Web 視圖的頁面。
  • response_type這告訴提供者你想要什麼。 通常,此值要么是token ,表示您需要訪問令牌,要么是code ,表示您需要訪問代碼。 提供者還可以擴展此值以提供其他類型的數據。
  • scope這告訴提供者你的應用想要訪問什麼。 這就是 Google 知道 Quora 要求訪問以管理您的聯繫人的方式。 每個提供者都有一組不同的範圍。

還有一些額外的字段可以增加更多的安全性或幫助緩存。 某些提供商還可以添加更多字段,但這四個是重要的。

一旦您的應用程序打開 Web 視圖,提供商就會接管。 他們可能只要求輸入一個簡單的用戶名和密碼,或者他們可能會顯示多個屏幕,要求從您最喜歡的老師的名字到您母親的娘家姓等任何內容。 這完全取決於他們。 重要的部分是,當提供者完成後,他們會重定向回你並給你一個令牌。

一切都與代幣有關

該過程完成後,提供者將為您提供一個令牌和一個令牌類型。 有兩種類型的令牌:訪問令牌和刷新令牌。 您擁有的客戶類型將決定您可以請求哪些類型的令牌。

當我登錄我的 Spotify 應用程序時,我可以保持登錄數月,因為假設我的手機僅供我使用。 Facebook 信任 Spotify 應用程序來管理令牌,我相信 Spotify 應用程序不會丟失令牌。

當訪問令牌超時(通常在一到兩個小時內)時,Spotify 可以使用刷新令牌來獲取新令牌。

刷新令牌持續數月。 那樣的話,我一年只需要在手機上登錄幾次。 不利的一面是,如果我丟失了該刷新令牌,其他人可能會使用我的帳戶數月之久。 刷新令牌非常重要,以至於 iOS 為令牌提供了一個鑰匙串,它可以確保加密並安全地存儲它們。

在 Web 應用程序中使用 OAuth2 的工作方式相同。 您可以在框架、iframe 或單獨的窗口中打開 OAuth2 登錄請求,而不是使用 Web 視圖。 您也可以在當前頁面上打開它,但這會導致您在有人需要登錄時丟失所有 JavaScript 應用程序狀態。

當我使用網絡瀏覽器登錄 Quora 時,我沒有獲得刷新令牌。 他們希望令牌超時並在我退出瀏覽器甚至只是出去吃午飯時提示我再次登錄。 不受信任的客戶端無法刷新令牌,因為無法信任他們持有重要的刷新令牌。 它更安全但不太方便,因為它們會更頻繁地提示您再次登錄。

在您的應用程序中使用 OAuth2

現在您知道了 OAuth2 的工作原理,但您可能不想實現自己的 OAuth2 客戶端。 如果您無法入睡,您可以閱讀整個 75 頁的 OAuth 2.0 規範,但您不需要閱讀。 一些很棒的庫可供您使用。

iOS 內置了對 OAuth2 的支持。 Corrina Krych 有一個關於在 Swift 中使用 OAuth 2.0 的非常有用的教程。 它將引導您了解如何獲取令牌、如何將視圖集成到您的應用程序中以及存儲令牌的位置。

Android 還內置了對 OAuth2 的支持。 我必須承認我並不熟悉它,因為我專注於 iOS,但是文檔中有一些很好的部分可以向您展示示例和一些開源庫,以使其更加容易。

JavaScript 沒有對 OAuth2 的內置支持,但是所有主要的 JavaScript 庫都有客戶端。 React 完全支持 OAuth2。 AngularJS 為許多項目提供了對 OAuth2.0 的第三方支持。 我什至寫了其中之一。

擁有 OAuth2 客戶端后,您需要選擇提供者。

你相信誰?

這裡最大的假設是我更信任 Facebook 而不是 Spotify。 我沒有充分的理由。 Facebook 沒有公開其內部安全,我也沒有好辦法對其進行審核。 Spotify 也沒有。 沒有針對 OAuth2 安全性的消費者報告。 我基本上信任 Facebook,因為它更大。 我信任 Facebook,因為其他人也信任。

每次單擊“使用 Facebook 登錄”按鈕時,我都會更加信任 Facebook。 如果 Facebook 丟失了我的密碼,那麼黑客不僅可以訪問我的 Facebook 帳戶,還可以訪問我的 Spotify 帳戶以及我使用我的 Facebook 帳戶登錄的任何其他服務。 好處是只有一個地方我必須重設密碼才能解決問題。

我不必信任 Facebook,但我必須信任某人。 必須有人對我進行身份驗證。 我需要選擇我信任的提供者。

選擇 OAuth2 提供者

Wikipedia 維護了一個 OAuth 提供者列表,但您不會關心其中的大多數。 最大的是 Facebook 和谷歌。 您可能還想看看亞馬遜或微軟。

它們都很大並且易於集成。 Facebook 提供了註冊應用程序的說明。 谷歌也有類似的步驟。 基本思想是您創建一個開發者帳戶,然後創建一個應用 ID。 然後,提供商會為您提供一個客戶端 ID,您可以使用它來發出請求。

您還可以選擇多個提供商。 Quora 允許您使用 Facebook 或 Google 登錄; 因為它們都使用 OAuth2,所以您可以對兩者使用相同的代碼。

OAuth2 缺少什麼

OAuth2 在解決複雜問題方面做得非常好,但它缺少一些東西:

  • 標準並不完全標準。 我從來沒有編寫過一個 OAuth2 客戶端,它可以在沒有一些if語句的情況下同時登錄 Facebook 和 Google。 每個人對規範的解釋都不同,每個人的細節幾乎沒有什麼不同。 他們也總是對提供什麼範圍有不同的想法。 使用庫與 OAuth2 集成對解決這個問題有很大幫助,但它在您的應用程序代碼中永遠不會 100% 透明。
  • 註銷很棘手。 . 每個使用 OAuth2 的應用程序或網站都有一個註銷按鈕,但大多數人只會忘記令牌而不會使它們失效。 該應用程序將忘記您當前的所有令牌並允許其他人登錄,但您的令牌仍然有效。 如果黑客竊取了您的令牌,他們仍然可以使用它並以您的身份登錄。

有一個單獨的規範用於使 OAuth2 令牌失效,但許多主要提供商都沒有採用它。 如果黑客獲取了您的刷新令牌,OAuth2 不提供恢復方法; 即使您可以刪除令牌的本地副本,黑客仍然會擁有它。 許多提供商為您提供了暫停帳戶的方法,但沒有標準的方法可以做到這一點。

為了保護 OAuth2,這是一個難題,因為許多提供商使用公鑰密碼術來創建無狀態令牌。 這意味著服務器不記得它創建的令牌,因此以後不會忘記它們。

OAuth2 的另一個主要問題是您依賴於您的提供商。 當 Facebook 出現故障時,您的應用程序中的“使用 Facebook 登錄”按鈕也會出現故障。 如果 Google 決定開始向您收取支持 OAuth2 的費用或要求您與其分享利潤,那麼您無能為力。 這是信任提供商的雙刃劍:他們為您做了很多事情,但他們可以控制您的用戶。

OAuth2 運行世界

即使缺少一些功能和很大的依賴性,OAuth2 仍然是一個很好的選擇。 它使用戶可以輕鬆登錄您的應用程序,無需記住每個網站的密碼,並信任您的安全性。 OAuth2 是一個非常受歡迎的選擇。 它在行業中占主導地位。 沒有其他安全協議能與 OAuth2 的採用相提並論。

現在您知道 OAuth2 來自何處以及它是如何工作的。 明智地選擇信任誰,停止閱讀有關安全存儲加密密碼的文章,並花更多時間編寫令人驚嘆的應用程序。