應用訪問鑒權
A. 我的5300用UC下載軟體保存時提示應用軟體訪問許可權受限怎麼辦
是諾基亞5300嗎？如果是，先進入設置菜單＞保密設備＞授權證書＞證書列表＞操作鍵＞選擇用途，把交差認證、伺服器鑒權等能設定的都設定就可以了，有好多證書得一個一個的都設定了，我已前就遇到過這種問題，就是這樣解決的。
B. 什麼是鑒權
鑒權（authentication）是指驗證用戶是否擁有訪問系統的權利。
鑒權包括兩個方面：
用戶鑒權，網路對用戶進行鑒權，防止非法用戶佔用網路資源。
網路鑒權，用戶對網路進行鑒權，防止用戶接入了非法的網路，被騙取關鍵信息。
(2)應用訪問鑒權擴展閱讀：
移動網路對鑒權時機的要求為：
2G、3G網路中，鑒權發生在開機、呼叫、位置更新以及在補充業務的激活、去活、登記或刪除操作之前。
2G網路中，運營商都是啟用的「按比例鑒權」方案。
3G網路中，用戶首次接入網路必須鑒權，此後啟用「按比例鑒權」方案。
IMS網路中，網路可以通過注冊或重注冊過程，在任何時候對用戶進行鑒權。
C. WebSocket連接鑒權的過程
根據WebSocket文檔上的說明，鑒權授權是需要自己實現。我們自己實現的流程大概是，在每次連接前，訪問介面取得鑒權必須的參數，在連接WebSocket的時候拼到url後面，聊天伺服器在連接的時候取url後面的參數，用於判斷是否連接是否合法
WebSocket協議一個應用層協議，它基於HTTP協議上的一個補充。它利用了HTTP協議的握手過程，通過HTTP請求頭中的某些欄位表示是否是WebSocket協議。
由於HTTP協議是一個無狀態協議，基於HTTP協議實現長鏈接必須通過ajax輪詢或者long pull實現。
通過第一個HTTP請求建立TCP連接後，之後的數據交換就不需要發送HTTP請求頭了，所以WebSocket協議時一個真正的長鏈接協議，它與HTTP協議還是有區別的。
在此基礎上WebSocket實現了一個雙通道的連接，也就是在同一個TCP上既可以收消息也可以發消息。
D. Android中請先調用鑒權是什麼意思
android6.0後對應用開放許可權更嚴格，在應用首次發起調用的時候，需要得到用戶的許可，（彈窗提示是否允許應用訪問該許可權），類似於蘋果！所以在開發者在開發中要先判斷許可權是否被允許，不允許要發起請求
E. 互聯網獨立鑒權應用在哪些行業啊為什麼
鑒權（authentication）是指驗證用戶是否擁有訪問系統的權利。傳統的鑒權是通過密碼來驗證的。這種方式的前提是，每個獲得密碼的用戶都已經被授權。在建立用戶時，就為此用戶分配一個密碼，用戶的密碼可以由管理員指定，也可以由用戶自行申請。這種方式的弱點十分明顯：一旦密碼被偷或用戶遺失密碼，情況就會十分麻煩，需要管理員對用戶密碼進行重新修改，而修改密碼之前還要人工驗證用戶的合法身份。
為了克服這種鑒權方式的缺點，需要一個更加可靠的鑒權方式。目前的主流鑒權方式是利用認證授權來驗證數字簽名的正確與否。
邏輯上，授權發生在鑒權之後，而實際上，這兩者常常是一個過程。
當用戶購機入網時，運營商將IMSI（International Mobile Subscriber
Identity，國際移動用戶標識）和用戶鑒權鍵Ki一起分配給用戶，同時將該用戶的IMSI和Ki存入AUC（Authentication
Center，鑒權中心），這樣鑒權參數信息存儲在手機的USIM（UMTS Subscriber Identity
Mole，UMTS用戶身份模塊）卡和AUC中。VLR（Visitor Location Register，拜訪位置寄存器）從AUC獲得用戶的鑒權數據，MSC（Mobile Switching
Center，移動交換中心）/VLR從鑒權數據中選取一組未使用過的鑒權參數。MSC/VLR向手機發起鑒權請求。請求消息中攜帶所選取的鑒權參數中的
RAND、AUTN和CKSN參數。手機中的USIM根據收到的RAND和自己保存的IMSI、Ki一起計算出XMAC，與從網路側收到的AUTN中的MAC值進行比較。
如果相同，繼續驗證接收到的AUTN中序列號SQN是否在有效的范圍內。序列號SQN的設置是為了防止他人冒充網路，利用截獲的、舊的鑒權參數AUTN欺騙用戶。
如果SQN有效，則認為這是個合法網路，網路鑒權成功。手機計算出RES，並將RES發送給MSC/VLR/SGSN。否則若發現SQN值無效時，手機會向網路報錯並且觸發網路與手機間的SQN重新同步過程。
如果SQN同步失敗或者MAC值不同，則網路鑒權失敗。
MSC/VLR將自己用RAND、IMSI和Ki算出的XRES與手機返回的RES進行比較。如果相同，則認為用戶合法，用戶鑒權成功，網路允許手機接入；否則認為用戶不合法，用戶鑒權失敗，拒絕為其服務。
F. 銀行卡鑒權怎麼處理
要解決銀行卡鑒權的問題，需要帶上開戶的身份證和銀行卡，到辦卡所在地銀行網點重新授權。鑒權，是指驗證用戶是否擁有訪問系統的權利。通常銀行卡鑒權是由銀行卡號+（姓名+身份證號碼+銀行預留手機號碼）組成的驗證服務。
【拓展資料】
當信用卡刷卡時，銀行卡身份驗證用於驗證用戶是否有權訪問系統。如果身份驗證失敗，則訪問失敗。認證是驗證用戶是否有權訪問系統。主流的認證方法是使用認證授權來驗證數字簽名的正確性。
銀行卡認證是由銀行卡號碼(姓名、身份證號碼、銀行預約手機號碼)組成的認證服務，目前主要包括銀行卡雙要素認證、銀行卡三要素認證、銀行卡四要素認證。
一、應用行業：目前在互聯網金融、貸款、擔保、支付、旅遊、保險、人力資源、網約車等各類有需求的政府、企業、第三方分制考核和身份驗證環節，也需要使用銀行卡驗證。
二、銀行卡認證的應用場景有以下兩種。
所有風擋審查環節：驗證卡號、姓名、手機號、身份證號的正確性，驗證卡的狀態是否正常，如果驗證成功，說明本人信息真實有效，風險小。 如果驗證失敗，則信息不正確，可以在前一階段篩選部分風險。 各種支付環節：防止用戶輸入銀行卡是否真的存在、狀態是否正常、信息是否正確、錯誤輸入。
數據范圍：所有銀聯銀行卡 四、銀行卡認證失敗處理方法 銀行卡認證失敗的原因有各種各樣。 例如，如果網上銀行預約的賬戶信息與在網站開設賬戶的賬戶信息不一致，或者銀行卡為「銀聯通」模式(浦發卡等)，則需要啟用銀聯通功能。 銀行卡認證失敗後的補救措施也很簡單，去當初辦理銀行卡的銀行重新定位即可。
G. vivo手機《游戲服務》鑒權失敗，無法登錄具體錯誤請查看錯誤日誌是什麼意思
原因如下：
1、重新打開應用。
2、重新啟動手機。
3、清除軟體數據。實在不行就等段時間。有的時候是賬號無法訪問伺服器所以會有錯誤日誌等系統檢測出來就行了。
網游
聊天
在很多MMORPG中，聊天都占據了大部分的網路流量，所以將聊天業務分離，建立單獨的聊天伺服器成為了很多開發者首先想到的事情。
戰斗
其次是回合制戰斗MMORPG中的戰斗模塊，由於玩家在進行戰斗時，幾乎和主伺服器完全沒有關聯，所以將戰斗業務分離到單獨伺服器也是理所當然、順理成章的事情。
腳本NPC
我們在和一些NPC對話執行劇情的時候，雖說也是在地圖上進行，但真正的劇情執行卻和地圖關系不大，所以也可以將使用腳本的NPC轉移到單獨的伺服器上，而主伺服器上僅在地圖網格上標識出NPC的編號和位置。
H. 鑒權異常是什麼意思
銀行卡鑒權其實就是驗證持卡人姓名、身份證號、銀行卡號、銀行預留手機號這四項要素是不是符合的意思，如果鑒權失敗了，那麼很有可能是四項要素信息不一致的原因導致的，這時候用戶就需要帶上本人的身份證、銀行卡去到開戶行重新辦理，這樣就可以了。
如果沒有鑒權功能，移動用戶可隨意接入和使用任一無線網路，運營商的利益得不到保障，同時，用戶的安全也會受到威脅。移動通訊網路發展之初，就考慮並解決了這個問題：採取用戶鑒權的方式來識別出非法用戶。
用戶鑒權，是對試圖接入網路的用戶進行鑒權，審核其是否有權訪問網路。通過用戶鑒權可以保護網路，防止非法盜用；同時通過拒絕假冒合法客戶的「入侵」而保護該網路中的客戶。
鑒權的含義：
鑒權（authentication）是指驗證用戶是否擁有訪問系統的權利。傳統的鑒權是通過密碼來驗證的。這種方式的前提是，每個獲得密碼的用戶都已經被授權。
在建立用戶時，就為此用戶分配一個密碼，用戶的密碼可以由管理員指定，也可以由用戶自行申請。這種方式的弱點十分明顯：一旦密碼被偷或用戶遺失密碼，情況就會十分麻煩，需要管理員對用戶密碼進行重新修改，而修改密碼之前還要人工驗證用戶的合法身份。
為了克服這種鑒權方式的缺點，需要一個更加可靠的鑒權方式。主流鑒權方式是利用認證授權來驗證數字簽名的正確與否。
邏輯上，授權發生在鑒權之後，而實際上，這兩者常常是一個過程。
I. 鑒權必須了解的 5 個兄弟：cookie、session、token、jwt、單點登錄
本文你將看到：
**「前端存儲」**這就涉及到一發、一存、一帶，發好辦，登陸介面直接返回給前端，存儲就需要前端想辦法了。
前端的存儲方式有很多。
有，cookie。cookie 也是前端存儲的一種，但相比於 localStorage 等其他方式，藉助 HTTP 頭、瀏覽器能力，cookie 可以做到前端無感知。一般過程是這樣的：
「配置：Domain / Path」
cookie 是要限制::「空間范圍」::的，通過 Domain（域）/ Path（路徑）兩級。
「配置：Expires / Max-Age」
cookie 還可以限制::「時間范圍」::，通過 Expires、Max-Age 中的一種。
「配置：Secure / HttpOnly」
cookie 可以限制::「使用方式」::。
**「HTTP 頭對 cookie 的讀寫」**回過頭來，HTTP 是如何寫入和傳遞 cookie 及其配置的呢？HTTP 返回的一個 Set-Cookie 頭用於向瀏覽器寫入「一條（且只能是一條）」cookie，格式為 cookie 鍵值 + 配置鍵值。例如：
那我想一次多 set 幾個 cookie 怎麼辦？多給幾個 Set-Cookie 頭（一次 HTTP 請求中允許重復）
HTTP 請求的 Cookie 頭用於瀏覽器把符合當前「空間、時間、使用方式」配置的所有 cookie 一並發給服務端。因為由瀏覽器做了篩選判斷，就不需要歸還配置內容了，只要發送鍵值就可以。
**「前端對 cookie 的讀寫」**前端可以自己創建 cookie，如果服務端創建的 cookie 沒加HttpOnly，那恭喜你也可以修改他給的 cookie。調用document.cookie可以創建、修改 cookie，和 HTTP 一樣，一次document.cookie能且只能操作一個 cookie。
調用document.cookie也可以讀到 cookie，也和 HTTP 一樣，能讀到所有的非HttpOnly cookie。
現在回想下，你刷卡的時候發生了什麼？
這種操作，在前後端鑒權系統中，叫 session。典型的 session 登陸/驗證流程：
**「Session 的存儲方式」**顯然，服務端只是給 cookie 一個 sessionId，而 session 的具體內容（可能包含用戶信息、session 狀態等），要自己存一下。存儲的方式有幾種：
「Session 的過期和銷毀」**很簡單，只要把存儲的 session 數據銷毀就可以。****「Session 的分布式問題」**通常服務端是集群，而用戶請求過來會走一次負載均衡，不一定打到哪台機器上。那一旦用戶後續介面請求到的機器和他登錄請求的機器不一致，或者登錄請求的機器宕機了，session 不就失效了嗎？這個問題現在有幾種解決方式。
但通常還是採用第一種方式，因為第二種相當於閹割了負載均衡，且仍沒有解決「用戶請求的機器宕機」的問題。**「node.js 下的 session 處理」**前面的圖很清楚了，服務端要實現對 cookie 和 session 的存取，實現起來要做的事還是很多的。在npm中，已經有封裝好的中間件，比如 express-session - npm，用法就不貼了。這是它種的 cookie：
express-session - npm 主要實現了：
session 的維護給服務端造成很大困擾，我們必須找地方存放它，又要考慮分布式的問題，甚至要單獨為了它啟用一套 Redis 集群。有沒有更好的辦法？
回過頭來想想，一個登錄場景，也不必往 session 存太多東西，那為什麼不直接打包到 cookie 中呢？這樣服務端不用存了，每次只要核驗 cookie 帶的「證件」有效性就可以了，也可以攜帶一些輕量的信息。這種方式通常被叫做 token。
token 的流程是這樣的：
**「客戶端 token 的存儲方式」 在前面 cookie 說過，cookie 並不是客戶端存儲憑證的唯一方式。token 因為它的「無狀態性」，有效期、使用限制都包在 token 內容里，對 cookie 的管理能力依賴較小，客戶端存起來就顯得更自由。但 web 應用的主流方式仍是放在 cookie 里，畢竟少操心。 「token 的過期」**那我們如何控制 token 的有效期呢？很簡單，把「過期時間」和數據一起塞進去，驗證時判斷就好。
編碼的方式豐儉由人。**「base64」**比如 node 端的 cookie-session - npm 庫
默認配置下，當我給他一個 userid，他會存成這樣：
這里的 eyJ1c2VyaWQiOiJhIn0=，就是 {"userid":"abb」} 的 base64 而已。 「防篡改」
是的。所以看情況，如果 token 涉及到敏感許可權，就要想辦法避免 token 被篡改。解決方案就是給 token 加簽名，來識別 token 是否被篡改過。例如在 cookie-session - npm 庫中，增加兩項配置：
這樣會多種一個 .sig cookie，裡面的值就是 {"userid":"abb」} 和 iAmSecret通過加密演算法計算出來的，常見的比如HMACSHA256 類 (System.Security.Cryptography) | Microsoft Docs。
好了，現在 cdd 雖然能偽造出eyJ1c2VyaWQiOiJhIn0=，但偽造不出 sig 的內容，因為他不知道 secret。**「JWT」**但上面的做法額外增加了 cookie 數量，數據本身也沒有規范的格式，所以 JSON Web Token Introction - jwt.io 橫空出世了。
它是一種成熟的 token 字元串生成方案，包含了我們前面提到的數據、簽名。不如直接看一下一個 JWT token 長什麼樣：
這串東西是怎麼生成的呢？看圖：
類型、加密演算法的選項，以及 JWT 標准數據欄位，可以參考 RFC 7519 - JSON Web Token (JWT)node 上同樣有相關的庫實現：express-jwt - npm koa-jwt - npm
token，作為許可權守護者，最重要的就是「安全」。業務介面用來鑒權的 token，我們稱之為 access token。越是許可權敏感的業務，我們越希望 access token 有效期足夠短，以避免被盜用。但過短的有效期會造成 access token 經常過期，過期後怎麼辦呢？一種辦法是，讓用戶重新登錄獲取新 token，顯然不夠友好，要知道有的 access token 過期時間可能只有幾分鍾。另外一種辦法是，再來一個 token，一個專門生成 access token 的 token，我們稱為 refresh token。
有了 refresh token 後，幾種情況的請求流程變成這樣：
如果 refresh token 也過期了，就只能重新登錄了。
session 和 token 都是邊界很模糊的概念，就像前面說的，refresh token 也可能以 session 的形式組織維護。狹義上，我們通常認為 session 是「種在 cookie 上、數據存在服務端」的認證方案，token 是「客戶端存哪都行、數據存在 token 里」的認證方案。對 session 和 token 的對比本質上是「客戶端存 cookie / 存別地兒」、「服務端存數據 / 不存數據」的對比。**「客戶端存 cookie / 存別地兒」**存 cookie 固然方便不操心，但問題也很明顯：
存別的地方，可以解決沒有 cookie 的場景；通過參數等方式手動帶，可以避免 CSRF 攻擊。 「服務端存數據 / 不存數據」
前面我們已經知道了，在同域下的客戶端/服務端認證系統中，通過客戶端攜帶憑證，維持一段時間內的登錄狀態。但當我們業務線越來越多，就會有更多業務系統分散到不同域名下，就需要「一次登錄，全線通用」的能力，叫做「單點登錄」。
簡單的，如果業務系統都在同一主域名下，比如wenku..com tieba..com，就好辦了。可以直接把 cookie domain 設置為主域名 .com，網路也就是這么乾的。
比如滴滴這么潮的公司，同時擁有didichuxing.com xiaojukeji.com didiglobal.com等域名，種 cookie 是完全繞不開的。這要能實現「一次登錄，全線通用」，才是真正的單點登錄。這種場景下，我們需要獨立的認證服務，通常被稱為 SSO。 「一次「從 A 系統引發登錄，到 B 系統不用登錄」的完整流程」
**「完整版本：考慮瀏覽器的場景」**上面的過程看起來沒問題，實際上很多 APP 等端上這樣就夠了。但在瀏覽器下不見得好用。看這里：
對瀏覽器來說，SSO 域下返回的數據要怎麼存，才能在訪問 A 的時候帶上？瀏覽器對跨域有嚴格限制，cookie、localStorage 等方式都是有域限制的。這就需要也只能由 A 提供 A 域下存儲憑證的能力。一般我們是這么做的：
圖中我們通過顏色把瀏覽器當前所處的域名標記出來。注意圖中灰底文字說明部分的變化。
謝謝大家哦