如今，很多移動應用在做用戶注冊/登錄的時候，為減少用戶的交互成本，會考慮引入常用的第三方平臺的開放登錄授權來快速的將用戶倒流到自己的平臺中。在原來的第三方登錄中，很多是采用基于 Web 的 Oauth 登錄授權機制，在這種情況下，用戶需要在 APP 彈出的網頁中輸入第三方平臺的賬號和密碼進行登錄，然后授權當前應用允許訪問自己的賬號。而現在更多的則采用的是所謂 SSO 授權機制，用戶在點擊第三方登錄按鈕后，應用會將用戶引導至對應的第三方應用中，接下來只需點擊授權按鈕即可完成授權過程，大大增強了操作的便捷性和賬號的安全性。但對于服務端開發者來說此時可能會發現，之前基于 Web 的 Oauth 登錄授權會產生一個回調，服務器可以基于此來做授權驗證。但在 SSO 這種機制下，回調會直接返回給應用本身而不經過服務器。這種時候應如何處理授權驗證的問題呢？

解決方案就是針對不同的第三方平臺，服務端再利用平臺所提供的開放接口來對授權進行一次驗證。

以QQ登錄為例，其實在其官方文檔中也提到了關于登錄校驗的解決方案：

1.2 需要考慮對OpenID和OpenKey做校驗

應用接收頁面請求時，必須對OpenID和OpenKey做校驗，以預防XSS漏洞。

OpenID的校驗規則：長度為32的16進制字符串，字符在[0-9A-F]范圍內。 開發者必須按照該規則對請求中傳來的OpenID進行校驗。(根據該規則生成的正則表達式：^([0-9A-F]{32})$)

OpenKey的校驗規則：長度為不固定的字符串，不能為空。建議開發者不要檢查openkey的長度，也不要在后臺存儲openkey，否則可能會導致用戶無法登錄。開發者可調用v3/user/is_login接口對請求中傳來的Openkey做登錄態校驗。

1.3 進行登錄態校驗的方法：

用戶進入應用時，URL中會帶有該用戶的OpenID和openkey，這時應用只要調用騰訊的任意后臺API，都可以驗證用戶的登錄態是否合法。

但是如果僅僅為了出于驗證登錄態 目的而去隨意調用某一個OpenAPI，則會給后臺服務造成很大的壓力 。

因此更推薦應用在用戶進入應用時通過以下方式進行登錄態校驗：

(1) 方式1：調用v3/user/get_info 接口來驗證登錄態。該接口即可驗證登錄態又可以獲取登錄用戶的信息，1個應用一般都需要獲取登錄用戶的信息，因此調用本接口可一舉兩得。

(2)方式2：調用專門的登錄態校驗接口v3/user/is_login。

在應用取得授權之后，應用可獲得 OpenID 和 OpenKey。服務器可提供一個授權登錄接口，要求應用將獲得的 OpenID 和 OpenKey 傳入，然后服務器可根據建議的方法調取 v3/user/get_info 接口(這樣同時可以得到用戶的基本信息作為注冊資料寫入)，如果調取成功，則說明有效。這時服務器才考慮寫入新的用戶數據并完成注冊/登錄步驟。不過要注意獲取用戶信息的接口是需要取得權限的，因此要記得在授權登錄的時候申請該權限，以 iOS 為例，要加入 kOPEN_PERMISSION_GET_INFO 權限參數。

再以新浪微博為例。新浪微博關于這一點沒有明確說明(或者我沒有找到)。在應用取得授權之后，應用可獲得 uid 和 access_token 等。因為新浪微博接口基本基于 OAuth2 官方標準規范來做的，因此可以在 OAuth2 的接口中找到 授權查詢(oauth2/get_token_info) 的接口， 它可以查詢用戶 access_token 的授權相關信息，包括授權時間，過期時間和 scope 權限。該接口同時會返回該 access_token 對應的 uid，可以與應用獲得的 uid 進行比對，以此來對授權進行驗證。

由此可以看出，SSO 機制對于用戶來說確實更為友好，但因為實現機制和平臺提供的 API 接口與標準的 Oauth 授權過程有所不同，因此這對于開發者來說就帶來了一些額外的工作。當然方法其實都大同小異，因此只要想到這一點，再找到合適的切入點，就可以很順利的達到目的。

總結

以上是生活随笔為你收集整理的服务器端授权验证,移动应用的第三方平台登录在服务端的授权验证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。