聊聊接口安全性問題

本文轉載自查看原文 2019-07-24 14:02 951 OAuth2/ java 基礎知識/ openid/ jwt/ 接口簽名

總結：我們寫過很多接口，有沒有想想接口的安全性呢？jwt,openid 側重於認證（就是用戶是誰），OAuth2 側重於授權（就是說這個東西是否有權限訪問），接口簽名呢側重於安全

請求來源(身份)是否合法？
請求參數被篡改？
請求的唯一性(不可復制)

簽名介紹：

AccessKey&SecretKey （開放平台）

請求身份

為開發者分配AccessKey（開發者標識，確保唯一）和SecretKey（用於接口加密，確保不易被窮舉，生成算法不易被猜測）。

防止篡改

參數簽名

按照請求參數名的字母升序排列非空請求參數（包含AccessKey），使用URL鍵值對的格式（即key1=value1&key2=value2…）拼接成字符串stringA；
在stringA最后拼接上Secretkey得到字符串stringSignTemp；
對stringSignTemp進行MD5運算，並將得到的字符串所有字符轉換為大寫，得到sign值。

請求攜帶參數AccessKey和Sign，只有擁有合法的身份AccessKey和正確的簽名Sign才能放行。這樣就解決了身份驗證和參數篡改問題，即使請求參數被劫持，由於獲取不到SecretKey（僅作本地加密使用，不參與網絡傳輸），無法偽造合法的請求。

重放攻擊

雖然解決了請求參數被篡改的隱患，但是還存在着重復使用請求參數偽造二次請求的隱患。

timestamp+nonce方案

nonce指唯一的隨機字符串，用來標識每個被簽名的請求。通過為每個請求提供一個唯一的標識符，服務器能夠防止請求被多次使用（記錄所有用過的nonce以阻止它們被二次使用）。

然而，對服務器來說永久存儲所有接收到的nonce的代價是非常大的。可以使用timestamp來優化nonce的存儲。

假設允許客戶端和服務端最多能存在15分鍾的時間差，同時追蹤記錄在服務端的nonce集合。當有新的請求進入時，首先檢查攜帶的timestamp是否在15分鍾內，如超出時間范圍，則拒絕，然后查詢攜帶的nonce，如存在已有集合，則拒絕。否則，記錄該nonce，並刪除集合內時間戳大於15分鍾的nonce（可以使用redis的expire，新增nonce的同時設置它的超時失效時間為15分鍾）。

實現

請求接口：http://api.test.com/test?name=hello&home=world&work=java

客戶端
1. 生成當前時間戳timestamp=now和唯一隨機字符串nonce=random
2. 按照請求參數名的字母升序排列非空請求參數（包含AccessKey)
  stringA="AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random";
3. 拼接密鑰SecretKey
  stringSignTemp="AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random&SecretKey=secret";
4. MD5並轉換為大寫
  sign=MD5(stringSignTemp).toUpperCase();
5. 最終請求
  http://api.test.com/test?name=hello&home=world&work=java&timestamp=now&nonce=nonce&sign=sign;
服務端

Token&AppKey（APP）

在APP開放API接口的設計中，由於大多數接口涉及到用戶的個人信息以及產品的敏感數據，所以要對這些接口進行身份驗證，為了安全起見讓用戶暴露的明文密碼次數越少越好，然而客戶端與服務器的交互在請求之間是無狀態的，也就是說，當涉及到用戶狀態時，每次請求都要帶上身份驗證信息。

Token身份驗證

用戶登錄向服務器提供認證信息（如賬號和密碼），服務器驗證成功后返回Token給客戶端；
客戶端將Token保存在本地，后續發起請求時，攜帶此Token；
服務器檢查Token的有效性，有效則放行，無效（Token錯誤或過期）則拒絕。

安全隱患：Token被劫持，偽造請求和篡改參數。

Token+AppKey簽名驗證

與上面開發平台的驗證方式類似，為客戶端分配AppKey（密鑰，用於接口加密，不參與傳輸），將AppKey和所有請求參數組合成源串，根據簽名算法生成簽名值，發送請求時將簽名值一起發送給服務器驗證。這樣，即使Token被劫持，對方不知道AppKey和簽名算法，就無法偽造請求和篡改參數。再結合上述的重發攻擊解決方案，即使請求參數被劫持也無法偽造二次重復請求。

實現

登陸和登出請求

后續請求

客戶端
和上述開放平台的客戶端行為類似，把AccessKey改為token即可。
服務端

方案：

// 添加攔截器
	@Override
	public void addInterceptors(InterceptorRegistry registry) {
	// 接口簽名認證攔截器，該簽名認證比較簡單，實際項目中可以使用Json Web Token或其他更好的方式替代。
	if (!"dev".equals(env)) { // 開發環境忽略簽名認證
	registry.addInterceptor(new HandlerInterceptorAdapter() {
	@Override
	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
	// 驗證簽名
	boolean pass = validateSign(request);
	if (pass) {
	return true;
	} else {
	LOGGER.warn("簽名認證失敗，請求接口：{}，請求IP：{}，請求參數：{}", request.getRequestURI(), getIpAddress(request), JSON.toJSONString(request.getParameterMap()));
	RetResult<Object> result = new RetResult<Object>();
	result.setCode(RetCode.UNAUTHORIZED).setMsg("簽名認證失敗");
	responseResult(response, result);
	return false;
	}
	}
	});
	}
	}

	/**
	* @Title: responseResult
	* @Description: 響應結果
	* @param response
	* @param result
	* @Reutrn void
	*/
	private void responseResult(HttpServletResponse response, RetResult<Object> result) {
	response.setCharacterEncoding("UTF-8");
	response.setHeader("Content-type", "application/json;charset=UTF-8");
	response.setStatus(200);
	try {
	response.getWriter().write(JSON.toJSONString(result));
	} catch (IOException ex) {
	LOGGER.error(ex.getMessage());
	}
	}

	/**
	* @Title: validateSign
	* @Description: 一個簡單的簽名認證，規則： 1. 將請求參數按ascii碼排序 2.
	* 拼接為a=value&b=value...這樣的字符串（不包含sign）3.
	* 混合密鑰（secret）進行md5獲得簽名，與請求的簽名進行比較
	* @param request
	* @Reutrn boolean
	*/
	private boolean validateSign(HttpServletRequest request) {
	String requestSign = request.getParameter("sign");// 獲得請求簽名，如sign=19e907700db7ad91318424a97c54ed57
	if (StringUtils.isEmpty(requestSign)) {
	return false;
	}
	List<String> keys = new ArrayList<String>(request.getParameterMap().keySet());
	keys.remove("sign");// 排除sign參數
	Collections.sort(keys);// 排序
	StringBuilder sb = new StringBuilder();
	for (String key : keys) {
	sb.append(key).append("=").append(request.getParameter(key)).append("&");// 拼接字符串
	}
	String linkString = sb.toString();
	linkString = StringUtils.substring(linkString, 0, linkString.length() - 1);// 去除最后一個'&'
	String secret = "Potato";// TODO 密鑰，自己修改
	String sign = DigestUtils.md5Hex(linkString + secret);// 混合密鑰md5
	return StringUtils.equals(sign, requestSign);// 比較
	}

相關的其他介紹

OAuth（開放授權）是一個開放標准，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯系人列表），而無需將用戶名和密碼提供給第三方應用。 OAuth協議為用戶資源的授權提供了一個安全的、開放而又簡易的標准。與以往的授權方式不同之處是OAuth的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAuth是安全的。同時，任何第三方都可以使用OAuth認證服務，任何服務提供商都可以實現自身的OAuth認證服務，因而OAuth是開放的。
OAuth簡史： 2007年12月4日發布了OAuth Core 1.0，此版本的協議存在嚴重的安全漏洞：OAuth Security Advisory: 2009.1，更詳細的安全漏洞介紹可以參考：Explaining the OAuth Session Fixation Attack。2009年6月24日發布了OAuth Core 1.0 Revision A：此版本的協議修復了前一版本的安全漏洞，並成為RFC5849，我們現在使用的OAuth版本多半都是以此版本為基礎。 OAuth 2.0是OAuth協議的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0關注客戶端開發者的簡易性，同時為Web應用，桌面應用和手機，和起居室設備提供專門的認證流程。
OAuth角色:

Consumer：消費方
Service Provider：服務提供者
User：用戶

OAuth流程：

用戶訪問客戶端的網站，想操作用戶存放在服務提供方的資源。
客戶端向服務提供方請求一個臨時令牌。
服務提供方驗證客戶端的身份后，授予一個臨時令牌。
客戶端獲得臨時令牌后，將用戶引導至服務提供方的授權頁面請求用戶授權。在這個過程中將臨時令牌和客戶端的回調連接發送給服務提供方。
用戶在服務提供方的網頁上輸入用戶名和密碼，然后授權該客戶端訪問所請求的資源。
授權成功后，服務提供方引導用戶返回客戶端的網頁。
客戶端根據臨時令牌從服務提供方那里獲取訪問令牌。
服務提供方根據臨時令牌和用戶的授權情況授予客戶端訪問令牌。
客戶端使用獲取的訪問令牌訪問存放在服務提供方上的受保護的資源。

有腿的OAuth 我們前面描述的OAuth，被稱為三條腿的OAuth（3-Legged OAuth），這也是OAuth的標准版本。這里所謂的“三條腿”，指的是授權過程中涉及前面提到的三種角色，也就是：消費方，服務提供者，用戶。不過有些情況下，不需要用戶的參與，此時就產生了一個變體，被稱作兩條腿的OAuth（2-Legged OAuth），一般來說，訪問私有數據的應用需要三條腿的OAuth，訪問公共數據的應用需要兩條腿的OAuth。兩條腿的OAuth和三條腿的OAuth相比，因為沒有用戶的參與，所以在流程中就不會涉及用戶授權的環節，也就不需要使用Token，而主要是通過Consumer Key和Consumer Secret來完成簽名的，此時的Consumer Key和Consumer Secret基本等價於賬號和密碼的作用。
OAuth和OpenID的區別： OAuth關注的是authorization授權，即：“用戶能做什么”；而OpenID側重的是authentication認證，即：“用戶是誰”。 OpenID、OAuth聯合使用例子：

OpenID 用戶希望訪問其在example.com的賬戶
example.com(在OpenID的黑話里面被稱為“Relying Party”) 提示用戶輸入他/她/它的OpenID
用戶給出了他的OpenID，比如說"http://user.myopenid.com"
example.com 跳轉到了用戶的OpenID提供商“mypopenid.com”
用戶在"myopenid.com"(OpenID provider)提示的界面上輸入用戶名密碼登錄
“myopenid.com" (OpenID provider) 問用戶是否要登錄到example.com
用戶同意后，"myopenid.com" (OpenID provider) 跳轉回example.com
example.com 允許用戶訪問其帳號
用戶在使用example.com時希望從mycontacts.com導入他的聯系人
example.com (在OAuth的黑話里面叫“Consumer”)把用戶送往mycontacts.com (黑話是“Service Provider”)
用戶在mycontacts.com 登錄(可能也可能不用了他的OpenID)
mycontacts.com問用戶是不是希望授權example.com訪問他在mycontact.com的聯系人
用戶確定
mycontacts.com 把用戶送回example.com
example.com 從mycontacts.com拿到聯系人
example.com 告訴用戶導入成功

上面的例子告訴我們，OpenID是用來認證協議，OAuth是授權協議，二者是互補的。OAuth來自Twitter，可以讓A網站的用戶共享B網站上的他自己的資源，而不需泄露用戶名和密碼給另外一個網站。OAuth可以把提供的Token，限制在一個網站特定時間段的的特定資源。
Google Connect(基於OpenID + OAuth思想的定制)：

OAuth 2.0的新特性 - 6種全新流程:

User-Agent Flow – 客戶端運行於用戶代理內（典型如web瀏覽器）。
Web Server Flow – 客戶端是web服務器程序的一部分，通過http request接入，這是OAuth 1.0提供的流程的簡化版本。
Device Flow – 適用於客戶端在受限設備上執行操作，但是終端用戶單獨接入另一台電腦或者設備的瀏覽器
Username and Password Flow – 這個流程的應用場景是，用戶信任客戶端處理身份憑據，但是仍然不希望客戶端儲存他們的用戶名和密碼，這個流程僅在用戶高度信任客戶端時才適用。
Client Credentials Flow – 客戶端使用它的身份憑據去獲取access token，這個流程支持2-legged OAuth的場景。
Assertion Flow – 客戶端用assertion去換取access token，比如SAML assertion。

OAuth 2.0的新特性: 持信人token - OAuth 2.0 提供一種無需加密的認證方式，此方式是基於現存的cookie驗證架構，token本身將自己作為secret，通過HTTPS發送，從而替換了通過 HMAC和token secret加密並發送的方式，這將允許使用cURL發起APIcall和其他簡單的腳本工具而不需遵循原先的request方式並進行簽名。簽名簡化 - 對於簽名的支持，簽名機制大大簡化，不需要特殊的解析處理，編碼，和對參數進行排序。使用一個secret替代原先的兩個secret。短期token和長效的身份憑據 - 原先的OAuth，會發行一個有效期非常長的token(典型的是一年有效期或者無有效期限制)，在OAuth 2.0中，server將發行一個短有效期的access token和長生命期的refresh token。這將允許客戶端無需用戶再次操作而獲取一個新的access token，並且也限制了access token的有效期。角色分開 - OAuth 2.0將分為兩個角色： Authorization server負責獲取用戶的授權並且發布token； Resource負責處理API calls。參考： OAuth2.0 OpenID&Oauth The OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-31 安全聲明（斷言）標記語言 saml（Security Assertion Markup Language）

OpenID_Oauth.zip (2.7 MB)

摘要：OAuth協議為用戶資源的授權提供了一個安全的、開放而又簡易的標准。與以往的授權方式不同之處是OAuth的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAuth是安全的。同時，任何第三方都可以使用 OAuth認證服務，任何服務提供商都可以實現自身的OAuth認證服務，因而OAuth是開放的。業界提供了OAuth的多種實現如 PHP，JavaScript，Java，Ruby等各種語言開發包，大大節約了程序員的時間，因而OAuth是簡易的。目前互聯網很多服務如Open API，很多大頭公司如Google，Yahoo，Microsoft等都提供了OAuth認證服務，這些都足以說明OAuth標准逐漸成為開放資源授權的標准。

一、OAuth產生的背景

典型案例：如果一個用戶擁有兩項服務：一項服務是圖片在線存儲服務A，另一個是圖片在線打印服務B。如下圖所示。由於服務A與服務B是由兩家不同的服務提供商提供的，所以用戶在這兩家服務提供商的網站上各自注冊了兩個用戶，假設這兩個用戶名各不相同，密碼也各不相同。當用戶要使用服務B打印存儲在服務A上的圖片時，用戶該如何處理？法一：用戶可能先將待打印的圖片從服務A上下載下來並上傳到服務B上打印，這種方式安全但處理比較繁瑣，效率低下；法二：用戶將在服務A上注冊的用戶名與密碼提供給服務B，服務B使用用戶的帳號再去服務A處下載待打印的圖片，這種方式效率是提高了，但是安全性大大降低了，服務B可以使用用戶的用戶名與密碼去服務A上查看甚至篡改用戶的資源。

很多公司和個人都嘗試解決這類問題，包括Google、Yahoo、Microsoft，這也促使OAuth項目組的產生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同發起的，目的在於為API訪問授權提供一個開放的標准。OAuth規范的1.0版於2007年12月4日發布。通過官方網址：http://OAuth.net可以閱讀更多的相關信息。

二、OAuth簡介

在官方網站的首頁，可以看到下面這段簡介：

An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

大概意思是說OAuth是一種開放的協議，為桌面程序或者基於BS的web應用提供了一種簡單的，標准的方式去訪問需要用戶授權的API服務。OAuth 類似於Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。OAuth認證授權具有以下特點：

1. 簡單：不管是OAuth服務提供者還是應用開發者，都很容易於理解與使用；

2. 安全：沒有涉及到用戶密鑰等信息，更安全更靈活；

3. 開放：任何服務提供商都可以實現OAuth，任何軟件開發商都可以使用OAuth；

三、OAuth相關術語

在弄清楚OAuth流程之前，我們先了解下OAuth的一些術語的定義：

OAuth相關的三個URL：
- Request Token URL: 獲取未授權的Request Token服務地址；
- User Authorization URL: 獲取用戶授權的Request Token服務地址；
- Access Token URL: 用授權的Request Token換取Access Token的服務地址；

OAuth相關的參數定義：
- OAuth_consumer_key: 使用者的ID，OAuth服務的直接使用者是開發者開發出來的應用。所以該參數值的獲取一般是要去OAuth服務提供商處注冊一個應用，再獲取該應用的OAuth_consumer_key。如Yahoo該值的注冊地址為：https://developer.yahoo.com/dashboard/
- OAuth_consumer_secret：OAuth_consumer_key對應的密鑰。
- OAuth_signature_method: 請求串的簽名方法，應用每次向OAuth三個服務地址發送請求時，必須對請求進行簽名。簽名的方法有：HMAC-SHA1、RSA-SHA1與PLAINTEXT等三種。
- OAuth_signature: 用上面的簽名方法對請求的簽名。
- OAuth_timestamp: 發起請求的時間戳，其值是距1970 00:00:00 GMT的秒數，必須是大於0的整數。本次請求的時間戳必須大於或者等於上次的時間戳。
- OAuth_nonce: 隨機生成的字符串，用於防止請求的重放，防止外界的非法攻擊。
- OAuth_version: OAuth的版本號，可選，其值必須為1.0。

OAuth HTTP響應代碼：

HTTP 400 Bad Request 請求錯誤
- Unsupported parameter 參數錯誤
- Unsupported signature method 簽名方法錯誤
- Missing required parameter 參數丟失
- Duplicated OAuth Protocol Parameter 參數重復
HTTP 401 Unauthorized 未授權
- Invalid Consumer Key 非法key
- Invalid / expired Token 失效或者非法的token
- Invalid signature 簽名非法
- Invalid / used nonce 非法的nonce

四、OAuth認證授權流程

在弄清楚了OAuth的術語后，我們可以對OAuth認證授權的流程進行初步認識。其實，簡單的來說，OAuth認證授權就三個步驟，三句話可以概括：

1. 獲取未授權的Request Token

2. 獲取用戶授權的Request Token

3. 用授權的Request Token換取Access Token

當應用拿到Access Token后，就可以有權訪問用戶授權的資源了。大家肯能看出來了，這三個步驟不就是對應OAuth的三個URL服務地址嘛。一點沒錯，上面的三個步驟中，每個步驟分別請求一個URL，並且收到相關信息，並且拿到上步的相關信息去請求接下來的URL直到拿到Access Token。具體的步驟如下圖所示：

具體每步執行信息如下：

A. 使用者（第三方軟件）向OAuth服務提供商請求未授權的Request Token。向Request Token URL發起請求，請求需要帶上的參數見上圖。

B. OAuth服務提供商同意使用者的請求，並向其頒發未經用戶授權的OAuth_token與對應的OAuth_token_secret，並返回給使用者。

C. 使用者向OAuth服務提供商請求用戶授權的Request Token。向User Authorization URL發起請求，請求帶上上步拿到的未授權的token與其密鑰。

D. OAuth服務提供商將引導用戶授權。該過程可能會提示用戶，你想將哪些受保護的資源授權給該應用。此步可能會返回授權的Request Token也可能不返回。如Yahoo OAuth就不會返回任何信息給使用者。

E. Request Token 授權后，使用者將向Access Token URL發起請求，將上步授權的Request Token換取成Access Token。請求的參數見上圖，這個比第一步A多了一個參數就是Request Token。

F. OAuth服務提供商同意使用者的請求，並向其頒發Access Token與對應的密鑰，並返回給使用者。

G. 使用者以后就可以使用上步返回的Access Token訪問用戶授權的資源。

從上面的步驟可以看出，用戶始終沒有將其用戶名與密碼等信息提供給使用者（第三方軟件），從而更安全。用OAuth實現背景一節中的典型案例：當服務 B（打印服務）要訪問用戶的服務A（圖片服務）時，通過OAuth機制，服務B向服務A請求未經用戶授權的Request Token后，服務A將引導用戶在服務A的網站上登錄，並詢問用戶是否將圖片服務授權給服務B。用戶同意后，服務B就可以訪問用戶在服務A上的圖片服務。整個過程服務B沒有觸及到用戶在服務A的帳號信息。如下圖所示，圖中的字母對應OAuth流程中的字母：

五、OAuth服務提供商

OAuth標准提出到現在不到兩年，但取得了很大成功。不僅提供了各種語言的版本庫，甚至Google，Yahoo，Microsoft等等互聯網大頭都實現了OAuth協議。由於OAuth的client包有很多，所以我們就沒有必要在去自己寫，避免重復造輪子，直接拿過來用就行了。我使用了這些庫去訪問Yahoo OAuth服務，很不錯哦！下面就貼出一些圖片跟大家一起分享下！

下圖是OAuth服務提供商引導用戶登錄（若用戶開始沒有登錄）

下圖是提示用戶將要授權給第三方應用，是否同意授權的頁面

下圖提示用戶已授權成功的信息

一些服務提供商不僅僅僅實現了OAuth協議上的功能，還提供了一些更友好的服務，比如管理第三方軟件的授權服務。下圖就是YAHOO管理軟件授權的頁面，用戶可以取消都某些應用的授權。

原文地址： http://blog.csdn.net/hereweare2009/article/details/3968582

擴展閱讀：

http://zh.wikipedia.org/wiki/OAuth

http://baike.baidu.com/view/3948029.htm

一、OpenID簡介

OpenId是一個以用戶為中心的數字身份識別框架，它具有開放、分散、自由等特性。OpenId的創建是基於這樣一個概念：我們可以通過URI（或者URL網址）來識別一個網站。同樣，我們也可以通過這樣的方式來識別一個用戶的身份。OpenId系統的身份認證就是通過 URI來認證用戶身份。目前絕大部分網站都是通過用戶名與密碼來登錄認證用戶身份，這就要求大家在每個你要使用的網站上注冊一個帳號。如果使用 OpenId，你可以在一個提供OpenId的網站上注冊一個OpenId，以后你可以使用這個OpenId去登錄支持OpenId的網站。這正是一處注冊，到處使用的體現。

登錄一個支持 OpenID 的網站非常簡單（即便你是第一次訪問這個網站也是一樣）。只需要輸入你注冊好的 OpenID 用戶名，然后你登錄的網站會跳轉到你的 OpenID 服務網站，在你的 OpenID 服務網站輸入密碼（或者其它需要填寫的信息）驗證通過后，你會回到登錄的網站並且已經成功登錄。 OpenID 系統可以應用於所有需要身份驗證的地方，既可以應用於單點登錄系統，也可以用於共享敏感數據時的身份認證。

除了一處注冊到處通行以外，OpenID 給所有支持 OpenID 的網站帶來了價值－－共享用戶資源。用戶可以清楚的控制哪些信息可以被共享，例如姓名、地址、電話號碼等。今天，OpenID 作為以用戶為中心的身份驗證系統已經為數百萬的用戶提供了服務。

二、OpenID相關術語

End User：終端用戶，使用OP與RP的服務
Relying Party依賴方：簡稱RP，服務提供者，需要OP鑒權終端用戶的身份
OpenID Provider：OpenID提供者，簡稱OP，對用戶身份鑒權
Identifier標識符：標識符可以是一個HTTP、HTTPS或者XRI(可擴展的資源標識)
User-Agent：實現了HTTP1.1協議的用戶瀏覽器
OP Endpoint URL：OP鑒權的URL，提供給RP使用
OP Identifier：OP提供給終端用戶的一個URI或者XRI,RP根據OP Identifier來解析出OP Endpoint URL與OP Version
User-Supplied Identifier：終端用戶使用的ID，可能是OP提供的OpenID，也可以是在RP注冊的ID。RP可以根據User-Supplied Identifier來解析出OP Endpoint URL、OP Version與OP_Local Identifer
Claimed Identifier：終端用戶聲明自己身份的一個標志，可以是一個URI或者XRI
OP-Local Identifier：OP提供的局部ID

三、OpenID驗證流程

終端用戶請求登錄RP網站，用戶選擇了以OpenID方式來登錄
RP將OpenId的登錄界面返回給終端用戶
終端用戶以OpenID登陸RP網站
RP網站對用戶的OpenID進行標准化，此過程非常負責。由於OpenID可能是URI，也可能是XRI，所以標准化方式各不相同。具體標准化過程是：如果OpenID以xri://、xri://$ip或者xri://$dns開頭，先去掉這些符號；然后對如下的字符串進行判斷，如果第一個字符是=、@、+、$、!，則視為標准的XRI，否則視為HTTP URL（若沒有http,為其增加http://）。
RP發現OP，如果OpenId是XRI，就采用XRI解析，如果是URL，則用Yadis協議解析，若Yadis解析失敗，則用Http發現。
RP跟OP建立一個關聯。兩者之間可以建立一個安全通道，用於傳輸信息並降低交互次數。
OP處理RP的關聯請求
RP請求OP對用戶身份進行鑒權
OP對用戶鑒權，請求用戶進行登錄認證
用戶登錄OP
OP將鑒權結果返回給RP
RP對OP的結果進行分析