openid演算法

⑴ 用戶openid是否唯一

是唯一的，應該是微信自己經過了一個什麼演算法返回給我們的

⑵ ID Token - JWT

我們來繼續前兩章（ OAuth2 總結 , 對OpenID Connect的理解 ）的討論，進入對JWT的理解。先來簡單回顧一下OAuth2和OpenID：

OpenID建立在OAuth之上，完成了認證和授權。而認證和授權的結果就體現在這個ID token之上，而這個ID token通常會是JWT。那麼為什麼會是JWT呢？我們通過以下幾點來逐一解釋。

JWT RFC 7519 給出了官方定義的一些欄位：

當然也不限於此，可以根據自己的需要，添加其他欄位。到此，我們可以看出JWT提供了ID token所需要的能力。一個完整的JTW是由三部分組成：Header，Payload，Signature。三者之間由 . 隔開，剛才提到的認證授權的欄位就存在於Payload中。
Header中存放的是JTW的元數據，包含簽名的演算法以及token的類型，如下所示：

Signature部分是對前兩部分的簽名， 防止數據篡改 。首先，需要指定一個密鑰（secret）。這個密鑰只有伺服器才知道，不能泄露給用戶。然後，使用 Header 裡面指定的簽名演算法（默認是 HMAC SHA256），按照下面的公式產生簽名。

算出簽名以後，把 Header、Payload、Signature三個部分經過base64序列化為三個字元串，再講三個字元串由 . 為間隔拼接成一個字元串返回給客戶端。

ID Token需要有足夠的安全性，JWT是如何做到的呢？
剛看到了簽名部分，簽名的作用只是為了防止數據篡改，而JWT默認是不加密，但也是可以加密的。生成原始 Token 以後，可以用密鑰再加密一次。比如認證伺服器中使用私鑰進行加密，把公鑰分發給其他應用伺服器，應用服務拿到加密後的token後用公鑰解密，獲取到JWT，再用簽名的秘鑰來驗證數據是否經過的篡改。

我們來看看還有神馬其他備選么？Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)。
JWT vs SAML：JWT基於json，而SAML基於XML，在大小上就有足夠的優勢，更適用於HTML和HTTP。
JWT vs SWT：在安全性上，SWT只支持對稱加密，而JWT和SAML支持公私鑰的加密方式。

作為一個mobile developer，也想在這里對比一下原先的簡單token模式和SSO中的JWT：
在沒有該機制前，我們通常會使用一個隨機產生的字元串作為token，認證成功後返回給前端，之後前端的每個請求帶上這個token。若後台服務的是個單體應用沒有什麼問題，請求來了，驗證一下token是否有效即可，但當認證服務和其他的應用服務是分離的，怎麼做呢？應用服務受到請求，再向認證服務發起一個請求來驗證驗證token是否合法，是否有許可權訪問該應用服務。這樣做到沒有什麼問題，只是當服務變多時，比如微服務下，勢必會造成認證伺服器的壓力過大。
在使用該機制後，客戶端通過認證服務登錄，獲得這個JWT，之後其他應用服務自身便可以驗證這個token的是否有效，是否有權訪問。

看似完美，但也有它自身的問題，我們來看一個場景：許可權變更。某用戶原先是一個超級管理員，可以訪問所有服務，並可進行任意的刪除，更改操作，他在這個狀態下拿到了JWT。隨後，由於許可權更改為普通管理員，便不應該具有所有許可權，但此時他開始時的JWT被緩存在客戶端仍然可用，其他應用服務也並無法知道這個用戶的許可權已經被更改，後果可想而知了。解決的方式無非是將這個token的有效時間設置的短一些。

⑶ 如何登錄自己的小程序

1.微信小程序端發起請求並攜帶主要參數;
2.java後台接收到登錄請求後，根據臨時憑證code去調用微信介面獲取用戶唯一標識openId和sessionKey;
3.使用openId去查詢資料庫（openId是會員的的唯一標識）
a.若openId存在，直接登錄成功；
b.若openId』不存在，我們把openId寫入到資料庫，並且讓他登錄
4.根據openId查詢redis資料庫，判斷openId對應的skey是否存在，如果存在刪除原來的老skey以及對應的openId和sessionKey（為了安全，保證每次登錄的key都是最新的）
5.通過uuid生成唯一的skey，用openId做鍵，skey做值，存入到redis中
6.然後把skey做鍵，openId和sessionKey的json串做值也重新存入到redis中
7.根據解密演算法，參數有encryptedData、sessionKey和iv，獲取用戶信息userInfo,如果userInfo欄位不滿足需要，可通過userInfo.put( 「balance」,user.getUbalance() );添加所需要的欄位和值
8.將微信小程序需要的數據封裝到map容器中，返回給小程序端

⑷ 聯想之星劉維：為什麼我不投模式型項目

本期和我們對談的VC是聯想之星投資總監劉維，劉維主要負責TMT領域的天使投資。聯想之星系聯想旗下的科技創業孵化器。聯想之星在投資上有一個「數據軸」理論，能不能跟我們具體說說呢? 劉維：這么說吧，我覺得業內很多人投的還是模式型的項目比較多， 美國有什麼東西比較火， 國內有幾個人就做了它了。從投資的角度來講，這些項目可能看著比較順眼，但是在那個時間點，你也看不出來多不錯，所以後面就是一個賭概率的游戲。 從聯想之星的角度來講，我們更多的還是去找一個「軸長」。這個「軸長」一定是在投資的始點上看，它某種積累已經比較豐富，這種積累有可能像十多年前我們投的科大訊飛也好，現在的Face++或者人機對話這些公司，它過往的技術積累往往是比較深厚的。而它當前還沒有被很好地裝到產品里，或者它的商業模式還不夠好，所以它沒有散發出特別大的市場價值，但是它這個軸不是別人一下可以追上的。所以投這些項目，一是市場上有了更充裕的時間，另一個就是說有利於新的產業。那這些公司數據軸很長，戰線很長，會不會因為這個遇到什麼困難? 劉維：聯想有句話叫「退出畫面看畫」，行業的近期問題當然需要討論，但退得遠一點，很多公司其實還有很多戰略機會，我到底應該怎麼去認識我這個市場，我應該怎麼做這件事，我做游戲開發的是不是應該不去做發行，把這塊砍掉。但退得遠一些，推出這個行業當前的用戶數，看看這個公司，戰略結構，怎麼把價值做大，重新梳理它的商業模式。 其實你回頭看我們當年投的科大訊飛，它一直堅持它的目標：當年想做語音，這么多年它也一直堅持下來了，不像很多公司，中間做自動集成什麼的就做其它的業務去了。但其實它也分階段實現目標嘛，如果說它從一開始就一定要做現在的這些訊飛語音、語音雲這樣的互聯網雲產品，肯定做不到。因為你的技術、你的邊界條件、你的市場都做不到。所以它從很早的時候就規劃了這條路徑，先做合成、再做識別。合成上來講，我們先做怎麼去給電信運營商來提供這些產品，再怎麼去做獨立的產品。你們通常怎麼幫助這些企業去規劃路徑呢? 劉維：我們有一種方法論是「目的性極強」。聯想挺強調邏輯，但強調邏輯並不是說有洞察力——今天就能判斷好我做什麼一定是對的。你的規劃可能還是錯的，但你至少定了規劃。 從目的的角度來講，就是我覺得現在市場格局是什麼，我為什麼要做這么一件事，來解決我對這個市場格局的認知。然後規劃這個事該怎麼做，一步一步分解下來。這個東西也許在過程中會不斷的調整，也許最後會被認為是錯的，但錯了沒關系，至少你長本事了。 你回頭去看的時候，會想是我當年判斷用戶需求錯了，還是我決定以什麼產品適應什麼需求這個匹配錯了，還是我怎麼去做產品做錯了，我對哪個邊界條件判斷錯了。你下次再決策的時候，肯定就能提高。所以我覺得目的性極強，對發展到一定程度的企業，會對他們是一種啟發。如何去培養目的性? 劉維：還是從思想方法上來講，把它當成你思考問題的中心吧。需要足夠的重視，而不是說把目的性寫下來，一共有哪幾個，這樣很容易扣不住。如果說一切的工作都是圍繞一個核心目的來拆解，比如 36kr 說我們的目的是今年要創建一個很好的創業者服務平台，那這個平台就包括你怎麼去提供給創業者的功能，怎麼去聚攏創業者，怎麼去做適當的宣傳和合縱連橫，所以這個東西是層層扣緊的。這和今天我們說第一要提高 36kr 的影響力，第二要讓讀者滿意，是不一樣的。這些目的可能永遠是對的，但不是很有可辯論空間，它是很確定的這樣的一個目的。那你們投訊飛和Face++這樣的企業，最終的目的性是什麼? 劉維：我們投資這些公司的願景，可能就是兩種層面：高和低。這些公司現在看起來都是通過技術平台來入手，那他們至少能做到的事是幫助很多 app、很多人增加、改善體驗，比如說能畫能做得更好、人臉識別能控製得更好，增加體驗之後呢，能獲得自己收入、積累起盈利的可能。比如做安全認證的，可以去做 OpenID 體系，做語義理解的，返回結果的時候可以夾雜至少是你推薦、提供來源的東西，所以它是短期內能實現商業價值。它們最後被大公司買走也好，或者成為像科大訊飛一樣賺錢的公司，都是有可能的。但這是一種低的、保守的方案。更為積極的方案，我們當然是希望他們能成為入口級別的廠商。您最近比較關注哪些領域? 劉維：「數據軸」還是持續會比較關注的一個領域，雖然我們已經投了這么多了，但還是會有不斷的機會，比如剛剛說的Face++，人臉識別下一步也有聚焦，比如它下一步會聚焦到更偏表情，還是更偏識別、更聚焦 3D 人臉。別的一些項目我們還是會關注。因為這里頭有一個大背景是，雲技術的發展，大大改變了這件事的可行性，原來像科大訊飛這些公司，它得磨個五年十年花幾個億的錢，可能才能把一些參數去人工地調到規則演算法，那現在雲的發展使得這個速度大大地加快。 另一類來說，我們也會關注to B業務這一塊的機會。我自己其實最早是做 to B 業務出身的，但是過去這些年，我一直覺得中國不太存在這樣的機會，就是讓它像 salesforce 互聯網公司這樣爆發性地增長。因為中國整體的環境決定，大部分的企業在采購的時候重重黑幕，它買一個軟體、買一個 IT 的服務，根本不在乎效率。 過去幾年漸漸有些小企業成長起來了，但 2000 年之後的這一波小企業呢，最大的問題在於缺乏品味，就是它是有訴求啦，老闆說我都是自己的錢啊，沒有什麼黑幕，但是呢，我要買個 ERP，我也不知道什麼好，拿到了我也不會用。這種情況就不太適合互聯網，不是說「我是產品好，一開始可以免費用，用多了再去擴展」。但這一兩年又發生了很多改變，比如說電商，電商很多企業其實是既有訴求又有品味的。因為他們每天賺的就是通過配置 IP 參數，通過數字化去把生意做好的人。他們對於很多 CRM 的東西，很多企業軟體的東西，越來越懂。那麼為哪些領域服務的公司最有可能成為SAAS? 劉維：比如電商，比如零售。零售就在於市場上的中小企業比較多，這么說吧，石油行業肯定不適合。當然我說的小企業是相對高端一點的，有點連鎖性質的零售。它的競爭者很多，而且它的競爭就是數據的競爭，對於這樣的企業來講，你讓它花點錢、花點代價去做這件事，它很願意。因為它有這個剛需。 我自己有句話叫「融化的冰山」，中國企業市場這塊冰山這兩年開始在融化，我們這塊其實比美國落後了十幾年，我們 to C 業務就好很多。所以 to B 這塊現在在加速追趕，加速融化，很有機會。您覺得這幾年中國那些不太有品位的企業在慢慢改變的社會背景是什麼? 劉維：一個是溫飽解決了，大家的品味還是在漸漸提高嘛。另一個，其實是另一種意義上的「C to B」，或者說「C推B」。有時候企業的品味提高得慢，但企業里的人的品味提高的快。你看中國現在 to C 產品最活躍，一點都不比美國差，美國到三四線城市，很多東西根本沒人用。而在中國不一樣，現在很多二三線城市，大家玩得東西也挺潮流的，這個實際上是在提高品位。其實現在 360 和騰訊都同樣面對這個問題，不是說我什麼東西抄一下就行，一些細節做不好用戶就不買單。為什麼?其實就是用戶品位提高了。所以我覺得中國會有很多這樣的機會吧。

⑸ openld是什麼意思

OpenID 是一個以用戶為中心的數字身份識別框架，它具有開放、分散性。OpenID 的創建基於這樣一個概念：我們可以通過 URI (又叫 URL 或網站地址)來認證一個網站的唯一身份，同理，也可以通過這種方式來作為用戶的身份認證。

OpenID 系統的第一部分是身份驗證，即如何通過URI來認證用戶身份。目前的網站都是依靠用戶名和密碼來登錄認證，這就意味著大家在每個網站都需要注冊用戶名和密碼，即便你使用的是同樣的密碼。

(5)openid演算法擴展閱讀

口令方式：

當自己每天訪問自己的電子郵件伺服器、利用Telnet登錄大學或公司的計算機或者訪問互聯網上諸如E*Trade的訂閱服務時都在使用口令。伺服器要採用用戶名與口令對用戶進行認證的話，就必須維護合法用戶的用戶名與口令的資料庫。

口令的選擇應滿足的幾個原則：

1、容易記憶；不易猜中；不易分析。

2、口令管理可通過單項函數來解決，即計算機不存儲口令，只存儲口令的單項函數，其識別過程如下：

1)用戶將口令傳送給計算機；

2) 計算機完成口令單向函數值的計算。

3)計算機把單向函數值和機器存儲值比較。

許多WWW伺服器系統都用固定格式的文件來存儲用戶名和口令，避免專門建立一個資料庫系統來僅僅存儲用戶名或口令。對大的商務網站來說，不可能將用戶名和口令存儲在固定格式文件中。

這些大網站一般會用工業級的資料庫來存儲商品目錄，而用同樣的資料庫來存儲用戶名和口令就很有意義了。否則，成千上萬的顧客要同時登錄會帶來很大的延遲。

不管將登錄信息存儲在何處。最常見也是最安全的存儲方法（UNIX系統採用的方法）是以明文形式保存用戶名，而用加密方式來保存口令。在系統創建一組新的用戶名/口令時，一般採用單向加密演算法對口令進行加密（同前面講述的消息摘要演算法一樣）。

在明文的用戶名和加密的口令方式下，當用戶登錄時，系統根據資料庫中所存儲的用戶名清單來檢查用戶名以驗證用戶的合法身法。對登錄系統時用戶所輸入的口令進行加密，系統將用戶口令的加密結果同資料庫中所存儲的加密口令進行比較。

如果指定用戶的兩種加密口令相互匹配，就接受登錄。這就是UNIX操作系統上即使系統管理員也無法找到被遺忘口令的原因。這時，管理員會給你一個新的臨時口令，然後你可改成自己選定的口令。

要知道口令是不安全的。有的網站將用戶名/口令以Cookie形式存在客戶機上，以方便用戶以後再訪問網站時不用再輸入用戶名/口令就能直接登錄了。

Cookie存在的問題是信息是以明文形式存在客戶機上，如果Cookie內含登錄和口令信息，任何想訪問存儲在客戶機上Cookie人都能看到這些信息。