聊聊接口安全性问题

总结：我们写过很多接口，有没有想想接口的安全性呢？jwt,openid 侧重 于 认证（就是用户是谁），OAuth2 侧重于授权（就是说这个东西是否有权限访问），接口签名呢 侧重于安全

  1. 请求来源(身份)是否合法？
  2. 请求参数被篡改？
  3. 请求的唯一性(不可复制)

     

 

 

    签名介绍： 

AccessKey&SecretKey （开放平台）

请求身份

为开发者分配AccessKey（开发者标识，确保唯一）和SecretKey（用于接口加密，确保不易被穷举，生成算法不易被猜测）。

防止篡改

参数签名

  1. 按照请求参数名的字母升序排列非空请求参数（包含AccessKey），使用URL键值对的格式（即key1=value1&key2=value2…）拼接成字符串stringA；
  2. 在stringA最后拼接上Secretkey得到字符串stringSignTemp；
  3. 对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身份验证

  1. 用户登录向服务器提供认证信息（如账号和密码），服务器验证成功后返回Token给客户端；
  2. 客户端将Token保存在本地，后续发起请求时，携带此Token；
  3. 服务器检查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）



  摘 要：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验证流程

  1. 终端用户请求登录RP网站，用户选择了以OpenID方式来登录
  2. RP将OpenId的登录界面返回给终端用户
  3. 终端用户以OpenID登陆RP网站
  4. RP网站对用户的OpenID进行标准化，此过程非常负责。由于OpenID可能是URI，也可能是XRI，所以标 准化方式各不相同。具体标准化过程是：如果OpenID以xri://、xri://$ip或者xri://$dns开头，先去掉这些符号；然后对如下的 字符串进行判断，如果第一个字符是=、@、+、$、!，则视为标准的XRI，否则视为HTTP URL（若没有http,为其增加http://）。
  5. RP发现OP，如果OpenId是XRI，就采用XRI解析，如果是URL，则用Yadis协议解析，若Yadis解析失败，则用Http发现。
  6. RP跟OP建立一个关联。两者之间可以建立一个安全通道，用于传输信息并降低交互次数。
  7. OP处理RP的关联请求
  8. RP请求OP对用户身份进行鉴权
  9. OP对用户鉴权，请求用户进行登录认证
  10. 用户登录OP
  11. OP将鉴权结果返回给RP
  12. RP对OP的结果进行分析

原文地址：http://www.biaodianfu.com/learn-openid.html

http://www.cnblogs.com/likebeta/archive/2012/06/28/2568781.html

前面两篇文章（OAuth和OpenID）都说了可以用来认证身份，但是他们之间到底有哪些不同，哪些情况应该用OAuth，哪些情况应该用OpenID呢?下面就一起来看下他们之间的区别。

简短的说，OAuth关注的是authorization；而OpenID侧重的是authentication。从表面上看，这两个英文单词很容易混淆，但实际上，它们的含义有本质的区别：

  • authorization: n. 授权，认可；批准，委任
  • authentication: n. 证明；鉴定；证实

OAuth关注的是授权，即：“用户能做什么”；而OpenID关注的是证明，即：“用户是谁”。下面就分别来说两者的功能。

OpenID

  1. 用户希望访问其在example.com的账户
  2. example.com (在OpenID的黑话里面被称为“Relying Party”) 提示用户输入他/她/它的OpenID
  3. 用户给出了他的OpenID，比如说”http://user.myopenid.com”
  4. example.com 跳转到了用户的OpenID提供商“mypopenid.com”
  5. 用户在”myopenid.com”(OpenID provider)提示的界面上输入用户名密码登录
  6. “myopenid.com” (OpenID provider) 问用户是否要登录到example.com
  7. 用户同意后，”myopenid.com” (OpenID provider) 跳转回example.com
  8. example.com 允许用户访问其帐号

OAuth

  1. 用户在使用example.com时希望从mycontacts.com导入他的联系人
  2. example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”)
  3. 用户在mycontacts.com 登录(可能也可能不用了他的OpenID)
  4. mycontacts.com问用户是不是希望授权example.com访问他在mycontact.com的联系人
  5. 用户确定
  6. mycontacts.com 把用户送回example.com
  7. example.com 从mycontacts.com拿到联系人
  8. example.com 告诉用户导入成功

OpenID是用来验证的，就是说可以用一个url来唯一表明身份（不用挨个记每个网站的用户密码）。OAuth是用来授权的（俺可以授权一个网站访问俺在另外一个网站的数据，而俺不用把俺的密码给第一个网站。

很多人现在错误的把OAuth当做OpenID使用。但是其实也不会照成什么影响。如水煮鱼开发的WordPress插件

 

原文就是下面地址：

http://www.biaodianfu.com/oauth-openid.html

http://www.cnblogs.com/likebeta/archive/2012/06/28/2568786.html

https://www.jianshu.com/p/ad410836587a
https://www.jianshu.com/p/c8483eee7c48
 

 

posted @ 2019-07-24 14:02  川流不息&  阅读(3091)  评论(0)  编辑  收藏  举报