SSO單點登入使用token機制來驗證使用者的安全性
登入的業務邏輯
{
http:是短連線.
伺服器如何判斷當前使用者是否登入?
// 1. 如果是即時通訊類:長連線.
// 如何保證伺服器跟客戶端保持長連線狀態?
// "心跳包" 用來檢測使用者是否線上!用來做長連線!
http:短連線使用token 機制來驗證使用者安全性
// token 值: 登入令牌! 用來判斷當前使用者的登入狀態!
// token 值特點: 是一個字串/大整數,只需要保證唯一性.是伺服器根據使用者的資訊(賬號/密碼/身份認證機制(電話號/身份證號/支付寶賬號/銀行卡資訊)...)來生成的用於標識使用者身份的值!
// token 值獲取:
// 當用戶首次登入成功之後, 伺服器端就會生成一個 token 值.
1.會在伺服器儲存token值(儲存在資料庫中)
2.將這個token值返回給客戶端.
// 客戶端拿到 token 值之後,一般儲存在兩個位置 :
1. 將 token 儲存在 cookie 中;
2.將 token 儲存在沙盒中,作為一個公共引數傳遞.
// 公共引數: 每一個網路請求都需要的引數! 一般公共引數有很多都是"可選"引數!,公共引數附帶的越多,越利於後臺監測使用者,資料探勘會使用到監測到的資料.
// 以後客戶端再次傳送網路請求(一般不是登入請求)的時候,就會將這個 token 值附帶到引數中傳送給伺服器.
// 伺服器接收到客戶端的請求之後,會取出token值與儲存在本地(資料庫)中的token值做對比!
// 如果兩個 token 值相同 :說明使用者登入成功過!當前使用者處於登入狀態!
// 如果沒有這個 token 值, 沒有登入成功.
// 如果 token 值不同: 說明原來的登入資訊已經失效,讓使用者重新登入.
// token 值失效問題: 1. token 值有失效時間!
{
token的有效時間:
{
1. 如果 app 是新聞類/遊戲類/聊天類等需要長時間使用者粘性的. 一般可以設定1年的有效時間!
2. 如果 app 是 支付類/銀行類的. 一般token只得有效時間比較短: 15分鐘左右!
}
}
// token 值失效問題: 2. token 值用來做裝置唯一性登入判斷!
{
每次登入之後,無論使用者密碼是否改變,只要呼叫登入介面並且登入成功,都會在伺服器生成新的token值,原來的token值就會失效!
典型的 app : 打車軟體類
}
拓展: 多型裝置同時登入. 裝置唯一性登入!
{
如果允許多臺裝置同時登入 ，並且可以設定最大的登入數量的時候。比如說QQ：允許在電腦客戶端登入，QQ手機端登入, QQ網頁端登入
如果超出這三個端 想要再另外 一個相同的端登入，需要使對應的端的token失效，來保證一個端 一個賬號只登入一次。
可以設定多個token 根據登入端不同 ，來檢測token 是否過期。 根據登入的數量 可以判斷最大支援多少個裝置同時登入
}
}
一，OAuth2.0授權協議：
簡述：一種安全的登陸協議，使用者提交的賬戶密碼不提交到本APP，而是提交到授權伺服器，待伺服器確認後，返回本APP一個訪問令牌，本APP即可用該訪問令牌訪問資源伺服器的資源。由於使用者的賬號密碼並不與本APP直接互動，而是與官方伺服器互動，因而它是安全的。
圖示：
流程：
1，獲取未授權的Request Token。
url:request token url。
param：appKey/appSecret，簽名方法/簽名（如HMAC-SHA1），timeStamp（時間戳：距1970/0/0/0/0/0的秒數），nonce（隨機生成的string，防止重複請求）
response：Oauth_Token/Oauth_Secret
2，獲取使用者授權的Request Token。
url:user authorizition url。
param：Oauth_Token(上個步驟返回的令牌），callback_url（授權成功後返回的地址）
response：Oauth_Token（被使用者授權或否決的令牌）
3，用已授權的Request Token換取AccessToken。
url：access token url。
param：appKey，Oauth_Token（上個步驟返回的令牌），簽名，TimeStamp，nonce
response：Access_Token/Secret
二，新浪微博的implementation（以ios sdk為例）。
1，先封裝下列引數：
NSDictionary *params = [NSMutableDictionarydictionaryWithObjectsAndKeys:
self.appKey, @"client_id",
@"code", @"response_type",
self.appRedirectURI, @"redirect_uri",
@"mobile", @"display", nil];
appKey和AppSecret在申請第三方APP的時候即可得到。appRedirectURI只對網頁應用有效，所以這裡可以隨便填一個或者使用預設的。
response_type為code表面其希望返回的是一個授權碼（相當於上述的未授權的Request Token）。
display應該是指該請求是移動app的請求。
然後啟動一個WebView，請求url：https://open.weibo.cn/2/oauth2/authorize，帶上述引數，方法為get。
形成的url如：https://open.weibo.cn/2/oauth2/authorize？client_id=1213792051&response_type=code&
redirect_uri=https%3A%2F%2Fapi.weibo.com%2Foauth2%2Fdefault.html&display=mobile
接著就進入了要求輸入賬號密碼的頁面
輸入賬號密碼後,以post方式往https://open.weibo.cn/2/oauth2/authorize傳送請求
出現授權或請求的按鈕，至此完成第一部分。
疑問：協議中的未授權的request token在這裡是哪個實體？還是新浪把它弱化掉了，也可能是快取在webview中。
2，點選授權按鈕之後，就可以得到Authorization Code了，該授權碼相當於以授權的Request Token。
3，封裝引數
NSDictionary *params = [NSDictionarydictionaryWithObjectsAndKeys:
self.appKey, @"client_id",
self.appSecret, @"client_secret",
@"authorization_code", @"grant_type",
self.appRedirectURI, @"redirect_uri",
code, @"code", nil];
請求url：https://open.weibo.cn/2/oauth2/access_token，方法post，加上述引數，通過NSURLConnection傳送請求
返回的data就包含access token，當然會判斷下該token是否還合法，有效，過期，成功的話會save住下面4個欄位。
NSString *access_token = [authInfo objectForKey:@"access_token"];
NSString *uid = [authInfo objectForKey:@"uid"];
NSString *remind_in = [authInfo objectForKey:@"remind_in"];
NSString *refresh_token = [authInfo objectForKey:@"refresh_token"];
4，以後在請求資源時，就會加上access_token了。
三，SSO技術。
簡述：SSO全場Single Sign On,使用者只需登陸一次即可訪問相互信任的子系統。使用者訪問系統1時，登陸成功後會返回一個ticket,當用戶訪問系統2時，會把ticket帶上，待驗證合法後即可訪問系統2。聽起來跟cookie有點像，沒錯，Web-SSO便有基於cookie的實現方案。很多手機APP在點選新浪授權時，會跳到新浪客戶端的登陸頁面，這裡就用到SSO技術啦。
在本APP授權新浪微博時，會先檢測手機是否安裝了新浪微部落格戶端。
[[UIApplicationsharedApplication] openURL：xxx]可以開啟另一個APP。這裡sinaweibosso://login為客戶端的url並傳遞三個引數，AppKey，RedirectURI，ssoCallbackScheme。
ssoCallbackScheme是返回的App Url地址，即自己定義的sinaweibosso.appKey。
登陸成功後，客戶端會直接把AccessToken返回給本App。至於在客戶端那邊發生了哪些互動，暫時不得而知。