---恢复内容开始---
本篇论文发表在计算机工程与设计，感觉写的还是很有水准的。实验部分交代的比较清楚
本篇论文的创新点： 使用Scyther工具 主要是在 DY模型下面 形式化分析了 OAuth2.0协议的安全性。 首先 OAuth2.0协议定义了四种角色分别是： 资源拥有者、资源服务器、客户端、授权服务器、 原文指出，根据应用环境的不同，OAuth2.0协议定义了四种授权模式： 授权码模式、简化模式、客户端模式、密码模式。 其次本篇论文知识讨论了OAuth2.0的中的授权码模型，
本论文中作者将认证服务器和资源服务器作为同一个服务器（方便实验操作） 。给出了顺序图，形象的展示授权码模式下各个参数信息的传递情况：
角色中需要定义的是本角色中使用的数据类型，（变量和常量的声明-------本作者在原文中没有说明）：从图中可以看到 User角色中包括5个事件，
我下面将协议关于授权码模式的 形式化描述过程 重新写了一遍
根据作者的解释如下：在用户角色描述 User ：------
User ：------ 第一行为User角色定义，程序在实例化的时候会根据 U角色实例化 User运行实例，角色中首先需要定义的是本角色中使用到的数据类型，就是变量和常量。User 角色中主要包括5个事件，第3行使用用户和客户端的共享秘钥由用户（user）向客户端（client）发送数据req ，第4行表示表示使用共享秘钥加密接受从客户端到用户的消息，第5行表示使用共享秘钥加密客户端（user）向服务器（server）发送授权码请求，并向服务器出示必要的参数信息如：已注册的重定向 uri 、状态码等。 第6行表示接受服务器端的授权码响应，第7行表示授权码重定向客户端。 接下来讨论安全属性的问题：Scyther 定义一对属性 （Running ,Commit）用来表示谢意双方对传输数据的认可，如果角色 I 认可角色 R的数据 （随机数 ni 和 nr），则在角色 I 的定义末尾插入语句 Claim （I，Commit， R ，ni, nr）;同样在 R中send 事件之前插入语句 claim（R，Running，ni ,nr）---恢复内容结束---
本篇论文发表在计算机工程与设计，感觉写的还是很有水准的。实验部分交代的比较清楚本篇论文的创新点： 使用Scyther工具 主要是在 DY模型下面 形式化分析了 OAuth2.0协议的安全性。 首先 OAuth2.0协议定义了四种角色分别是： 资源拥有者、资源服务器、客户端、授权服务器、 原文指出，根据应用环境的不同，OAuth2.0协议定义了四种授权模式： 授权码模式、简化模式、客户端模式、密码模式。 其次本篇论文知识讨论了OAuth2.0的中的授权码模型，
角色中需要定义的是本角色中使用的数据类型，（变量和常量的声明-------本作者在原文中没有说明）：从图中可以看到 User角色中包括5个事件，
我下面将协议关于授权码模式的 形式化描述过程 重新写了一遍
根据作者的解释如下：在用户角色描述 User ：------
User ：------ 第一行为User角色定义，程序在实例化的时候会根据 U角色实例化 User运行实例，角色中首先需要定义的是本角色中使用到的数据类型，就是变量和常量。User 角色中主要包括5个事件，第3行使用用户和客户端的共享秘钥由用户（user）向客户端（client）发送数据req ，第4行表示表示使用共享秘钥加密接受从客户端到用户的消息，第5行表示使用共享秘钥加密客户端（user）向服务器（server）发送授权码请求，并向服务器出示必要的参数信息如：已注册的重定向 uri 、状态码等。 第6行表示接受服务器端的授权码响应，第7行表示授权码重定向客户端。 接下来讨论安全属性的问题：Scyther 定义一对属性 （Running ,Commit）用来表示谢意双方对传输数据的认可，如果角色 I 认可角色 R的数据 （随机数 ni 和 nr），则在角色 I 的定义末尾插入语句 Claim （I，Commit， R ，ni, nr）;同样在 R中send 事件之前插入语句 claim（R，Running，ni ,nr） 现在对实验结果解释： 通过实验分析得到实验结果，Scyther本身采用的是黑盒的验证思想，各个角色从自己的角度考虑观察问题，是否能够满足安全目标和安全属性，如果安全属性不满足则可能存在攻击路径，（实验输出攻击路径图），分别从三个角色出发分析攻击：‘ 首先是 User 端角色观察到的攻击图。
解释如下： 只有客户端认为自己是和攻击者通信的， User端认为通信三方为：角色 U为自己 ，角色C为 Client ，角色 S为 Server Client端认为通信三方 ： 角色U为 User，同时可能存在另一个User进程 Eve（攻击者），角色C为自己 ，角色S为 Server Server 端认为： 角色U为User ，角色C为Client ，角色S为自己 ，此项攻击为中间人攻击，首先攻击者监听到用户向Client端发送授权码信息，如果这个通信信道未受到保护户，攻击者将原有的信息截获、原有的通道阻塞，保证授权码的有效性，之后攻击者以User的身份发起另一个会话，使用监听到的授权码嘻嘻获取资源。 Server端观察到的攻击路径如下：
解释如下： 只有Server端认为自己是和攻击者进行通信的， User端认为通信三方为 ：角色 U为自己 ，角色C为Client ，角色 S为Server Client端认为通信三方为： 角色U为 User ，角色C为自己 ，角色S为Server， Sever端认为：角色U为Eve（攻击者），角色C为Client ，角色S为自己 ， 首先监听者User发送到Server的授权码请求消息，然后对信息进行修改，转发给Server，Server做出授权码响应，将授权码转发给攻击者Eve。 ’