WEB使用OAuth2协议实现开放接口的设计方案(待完善)

术语

developer:开发者,第三方应用的开发者。

openPlat:开放平台,发放App Key(相当于第三方应用的ID)、App Secret(私钥,验证ID是否唯一有效,需要妥善保管)。

Authorization Server:授权服务端,发放Code、Access Token,验证App Key、App Secret、Code的有效性。

Resource Server:资源服务器,验证Access Token,提供资源的访问接口。

Client:客户端(第三方应用),发送访问受保护资源的请求,获取Code、Access Token。

Resource Owner:资源拥有者,对保护资源有访问许可控制的实体(一般是指个人)。

Protected Resource:受保护的资源,能够通过OAuth2.0获取访问控制权的资源。

Authorization Code:授权码

Refresh Token:刷新令牌,Access Token失效后刷新Access Token的一个标识。

Access Token:访问令牌

API:资源封装为接口对外开放,得到访问授权的第三方应用可以调用API。

架构

开放平台

功能

发放App Key、App Secret

第三方应用在WEB提供的开放平台注册,提供回调地址;开放平台生成App Key、App Secret,并返回给第三方应用。授权服务器通过App Key、App Secret、回调地址验证第三方应用是否被授权了。

接口设计

获取App Key、App Secret的接口

传入的参数:

Client name:第三方应用的名称

Callback_url:回调地址

content:介绍内容

以及第三方应用的其他属性。

传出的参数:

App key:第三方应用的ID

App Secret:密钥

页面设计

申请获取App Key、App Secret页面

收集以下参数:

Client name:第三方应用的名称

Callback_url:回调地址

content:介绍内容

以及第三方应用的其他属性。

返回App Key、App Secret页面

呈现第三方应用的App Key、App Secret给开发者。

授权服务端

功能

发放Code

授权服务器验证用户的凭证(一般是用户名、密码,授权服务器存储了大量的用户信息,每个用户都有自己的受保护的资源)有效,则给发放Code,并将Code返回给第三方应用。Code是明文传输。

发放Access Token

第三方应用使用Code去换取Access Token。此时验证第三方的ID(App Key、App Secret)、Code的有效性。

验证App Key、App Secret

授权服务器保存已经注册的第三方应用的App Key、App Public Secret(公钥),通过私钥验证第三方应用是否已经注册。

验证Code

验证Authorization Code是否有效。

接口设计

设计两个接口:a、获取Code的接口;b、获取Access Token的接口。

获取Authorization Code的接口

客户端向资源拥有者请求授权,资源请求直接发给资源拥有者,若资源拥有者同意该客户端授权,则给客户端返回一个访问许可。

传入的参数:

App Key

App Secret

Callback_url

返回的信息:

未登陆、微授权:跳转到登陆页面;

已经登陆、未授权:跳转到授权页面;

已经登陆、已经授权:跳转到传入的callback_url页面,并返回一个访问许可。

获取Access Token的接口

客户端向用户出示自己的私有证书和Authorization Code请求访问令牌;授权服务器验证客户端的私有证书和访问许可的有效性,验证有效则向客户端发送一个访问令牌,令牌包括了作用域、有效时间以及其他属性。

传入参数:

App Key:应用的ID

App Secret:第三方应用的私钥。

Callback_url:回调url

传出的参数:

Access Token:Access Token中包含了AppId和用户信息UserIdd等。

获取到Access Token

之后,就可以向资源服务器出示Access Token,访问受保护资源。

页面设计

设计两个页面:a、登陆页面;b、授权页面

登陆页面

展示给资源拥有者,输入用户名的、密码。登录成功后,如果未授权,则跳转到授权页面;如果已经授权,直接跳转到callback_url页面,并返回一个访问许可。

授权页面

展示给资源拥有者,如果用户已经授权,则直接跳转到callback_url页面,并返回一个访问许可;如果未授权,则出现授权页面,授权成功后,跳转到callback_url,并返回一个访问许可。

第三方应用接入WEB

接口设计

与授权服务器的接口

与资源服务器的接口

与WEB的接口

页面设计

引导用户登录的页面

资源展示的页面

时间: 2024-10-11 02:18:22

WEB使用OAuth2协议实现开放接口的设计方案(待完善)的相关文章

App开放接口api安全性—Token签名sign的设计与实现

前言 在app开放接口api的设计中,避免不了的就是安全性问题,因为大多数接口涉及到用户的个人信息以及一些敏感的数据,所以对这些 接口需要进行身份的认证,那么这就需要用户提供一些信息,比如用户名密码等,但是为了安全起见让用户暴露的明文密码次数越少越好,我们一般在web项目 中,大多数采用保存的session中,然后在存一份到cookie中,来保持用户的回话有效性.但是在app提供的开放接口中,后端服务器在用户登录后 如何去验证和维护用户的登陆有效性呢,以下是参考项目中设计的解决方案,其原理和大多

如何做一个简单的开放接口(1)-功能设计

1.缘起 最初,系统系统间都是孤立的.业务是贯穿的,系统间也必然需要交互数据. 实现数据交互的方式有好多种,可以通过ftp交互Excel文件,可以通过互相读写的中间库,可以通过Web Services. 系统间可能是点对点交互,可能是一对多广播,可能是多对一汇总,可能是多对多协同. 在复杂IT场景中,多信息系统各司其职,协作完成工作.交互数据的事情怎样做呢? 数据交互有两个核心问题要解决:一是协议,二是数据格式.这两个都需要通信双方协商. 如果是企业内部的各信息系统,可以搭建统一的数据交互平台解

Spring Cloud 开放接口平台

1.什么是微服务开放平台2.Oauth2.0开放授权协议3.常用开放平台接口4.QQ互联网授权平台5.演示QQ互联网接口6.基于SpringCloudOauth2 搭建微服务开放平台https://github.com/spring-cloud/spring-cloud-security 什么是开放平台接口 在一些大型互联网公司,随着公司的业务发展逐渐庞大,需要和外部合伙伙伴进行合作,需要将公司的接口开放给外部其他合伙伙伴进行调用. 比如腾讯的QQ互联网.微信开放平台.蚂蚁金服开放平台 .微博开

如何做一个简单的开放接口(2)-核心引擎(上)

1.要实现的功能 书接上回,本回书我们要完成开放接口平台核心引擎的多Handler支持机制. 如图1所示. 图1 开放接口服务器端架构 2.Filter还是装饰模式 装饰者模式貌似是一个实现的候选,类似Java的I/O实现. 多"装饰"一层,就获得了新的功能,原来的功能还在. 对我现在的应用场景来说,这种实现方式过于复杂了. 相对而言,Filter更简洁. 当前的应用场景对性能是有极高要求的,不适合使用哪怕稍微复杂的模式. 3.Handler接口定义 我的Handler接口定义如下.

开放接口/RESTful/Api服务的设计和安全方案

总体思路 这个涉及到两个方面问题:一个是接口访问认证问题,主要解决谁可以使用接口(用户登录验证.来路验证)一个是数据数据传输安全,主要解决接口数据被监听(HTTPS安全传输.敏感内容加密.数字签名) 用户身份验证:Token与Session开放接口Api服务其实就是客户端与服务端无状态交互的一种形式,这有点类似REST(Representational State Transfer)风格.普通网站应用一般使用session进行登录用户信息的存储和验证(有状态),而开放接口服务/REST资源请求则

使用 EWS(Exchange Web Service)协议读取邮件、发送邮件

问题: 公司之前可以通过POP3协议收发邮件,因而在SoapUI中用JavaMail可以读取邮件,后来配置了Office 365,POP3协议端口不再开放,邮件全部读取失败,报login timeout,需要改用EWS(Exchange Web Service)协议. 参考 : http://blog.csdn.net/yangcheng33/article/details/55049629 需要导入此JAR包 : ews-java-api-2.0.jar import java.net.URI

TCP/IP协议与HTTP协议区别SOCKET接口详解

网络由下往上分为:      物理层--                       数据链路层-- 网络层--                       IP协议 传输层--                       TCP协议 会话层-- 表示层和应用层--           HTTP协议   socket则是对TCP/IP协议的封装和应用(程序员层面上).也可以说,TPC/IP协议是传输层协议,主要解决数据 如何在网络中传输,而HTTP是应用层协议,主要解决如何包装数据.关于TCP/

用协议来统一接口

效果 源码 https://github.com/YouXianMing/ProtocolDesign // // CellHeightProtocol.h // TableViewDemo // // Created by YouXianMing on 15/6/17. // Copyright (c) 2015年 YouXianMing. All rights reserved. // #import <Foundation/Foundation.h> #import <UIKit/

基于http协议的api接口对于客户端的身份认证方式以及安全措施[转]

基于http协议的api接口对于客户端的身份认证方式以及安全措施 由于http是无状态的,所以正常情况下在浏览器浏览网页,服务器都是通过访问者的cookie(cookie中存储的jsessionid)来辨别客户端的身份的,当客户端进行登录服务器也会将登录信息存放在服务器并与客户端的cookie中的jsessionid关联起来,这样客户端再次访问我们就可以识别用户身份了. 但是对于api服务器,我们不能让访问者先登录再进行访问这样不安全,也不友好.所以一般情况我们都是需要客户端提供一个key(每个