YD/T 2912-2015
基本信息
标准号： YD/T 2912-2015
中文名称：移动互联网应用编程接口的授权技术要求
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：26402325
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2912-2015.Technical requirements of authorization framework for mobile internet API.
1范围
YD/T 2912规定了移动互联网应用编程接口授权框架，该框架能使用户通过开放的网络能力API,尤其是RESTFul API,授权第三方应用(桌面、移动终端与web应用)，以代表访问用户访问网络资源。
YD/T 2912适用于运营商为移动互联网应用访问网络资源提供安全授权机制。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本( 包括所有的修改单)适用于本文件。
IETF RFC2045 因特网邮件协议之消息体(Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies)
IETF RFC2046 互联网邮件协议之媒体类型(Multipurpose Intermet Mail Extensions(MIME) Part Two: Media Types)
IETF RFC2119 RFC中关键词的解释(Key words for use in RFCs to Indicate Requirement Levels)
IETF RFC3986 统一资源标识(Uniform Resource Identifier (URI): Generic Syntax)
1范围
YD/T 2912规定了移动互联网应用编程接口授权框架，该框架能使用户通过开放的网络能力API,尤其是RESTFul API,授权第三方应用(桌面、移动终端与web应用)，以代表访问用户访问网络资源。
YD/T 2912适用于运营商为移动互联网应用访问网络资源提供安全授权机制。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本( 包括所有的修改单)适用于本文件。
IETF RFC2045 因特网邮件协议之消息体(Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies)
IETF RFC2046 互联网邮件协议之媒体类型(Multipurpose Intermet Mail Extensions(MIME) Part Two: Media Types)
IETF RFC2119 RFC中关键词的解释(Key words for use in RFCs to Indicate Requirement Levels)
IETF RFC3986 统一资源标识(Uniform Resource Identifier (URI): Generic Syntax)
标准图片预览
标准内容
ICS33.030
中华人民共和国通信行业标准
YD/T2912-2015
移动互联网应用编程接口的授权技术要求Technical requirements of authorization frameworkfomobileinternetAPl
2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前言
1范围·
2规范性引用文件
3术语、定义和缩略语·
3.1术语和定义.
3.2缩略语
4概述
4.1Autho4API的制定内容..
抽象协议流程
5需求
概述·
高层次功能要求
安全需求·
计费：www.bzxz.net
管理和配置
可用性
互通性·
隐私性“
共享多服务提供商的情况·
体系结构
相关性/依赖性：
架构图·
功能组件和接口/参考点定义
7技术规范
客户端注册
协议端点
服务参数发现（参考性信息）
获取授权
发出访问令牌
更新访间令牌-
访问受保护的资源
多业务提供商环境（消息环境）安全考虑
YD/T2912-2015
YD/T2912-2015
8OMNA考患·
附录A（资料性附录）部署场景·..附录B（资料性附录）范围值（ScopeValues）的定义**附录B（资料性附录）“授予资源的URL前缀”资源的定义·参考文献
本标准按照GB/T1.1-2009给出的规则起草。YD/T2912-2015
本标准参考了OMA引擎Autho4APIv1.0规范OMA-RD-Autho4API-V1_0-20120327-C和OMA-ER-Autho4API-V1_0-20120327-C，与这两个规范章节和内容的对应关系如下：本标准中第3章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第3章，增加了3个定义：机密类型客户端、公开类型客户端、RESTful；，本标准中第4章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第4章，技术细节保持一致：
一本标准中第5章，对应于OMA规范的OMA-RD-Autho4API-V1_0-20120327-C的第5章，技术细节保持一致；
本标准中第6章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第6章，技术细节保持一致；
一本标准中第7章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第7章，技术细节保持一致：
本标准中第8章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第8章，技术细节保持一致：
一本标准中附录A，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的附录C，技术细节保持一致：
一本标准中附录B，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的附录D，技术细节保持一致：
本标准中附录C，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的附录E，技术细节保持一致。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：上海贝尔股份有限公司、中国联合网络通信集团有限公司、中国信息通信研究院、中国移动通信集团有限公司、南京爱立信熊猫通信有限公司。本标准主要起草人：胡志远、孙群英、刘镝、张尼、董慧、逢淑宁、王静、刘斐、李钢。Ⅲ
1范围
移动互联网应用编程接口的授权技术要求YD/T2912-2015
本标准规定了移动互联网应用编程接口授权框架，该框架能使用户通过开放的网络能力API，尤其是RESTFulAPI，授权第三方应用（桌面、移动终端与web应用），以代表访问用户访问网络资源。本标准适用于运营商为移动互联网应用访问网络资源提供安全授权机制。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC2045
IETFRFC2046
IETFRFC2119
IETFRFC3986
IETFRFC4234
IETFRFC4346
IETFRFC5246
IETFRFC2616
IETFRFC2617
IETFRFC6749（2012)
IETFRFC6750
IETFRFC7009
FIPSAES
FIPS AESMode
GSMARCSREQ
OMAAUTHO4API_RD_10
OMAAUTHO4API_ER_10
因特网邮件协议之消息体（MultipurposeInternetMailExtensions(MIME)PartOne:Format of Internet MessageBodies)互联网邮件协议之媒体类型（MultipurposeInternetMailExtensions(MIME)PartTwo:MediaTypes)
RFC中关键词的解释(KeywordsforuseinRFCstoIndicateRequirement Levels)
统一资源标识（UniformResourceIdentifier（URD：GenericSyntax）ABNF语法规范（AugmentedBNFforSyntaxSpecifications:ABNF）传输层安全（TransportLayerSecurity（TLS）Version1.1）传输层安全（TransportLayerSecurity(TLS）Version1.2）超文本协议（HypertextTransferProtocol--HTTP/1.1）HTTP Digest认证 (HTTP Authentication:Basic and Digest AccessAuthentication)
OAuth2.0授权协议（TheOAuth2.0AuthorizationProtocol）OAuth2.0承载令牌（TheOAuth2.0Protocol:BearerTokens）令牌撤销(TokenRevocation）
高级加密算法标准（ThespecificationofAdvancedEncryptionStandard
AES块加密模式（RecommendationofBlockCipherModesofOperation)
GSMA富媒体需求（RichCommunication Suite--RCSAPIDetailedRequirements 1.1)
网络API授权框架需求（AuthorizationFrameworkforNetworkAPIsRequirements
网络API授权框架（AuthorizationFrameworkforNetworkAPIs）1
YD/T2912-2015
OMAOMNA_Autho4API
OMAOSE
OMASCRRULES
OMASECCF-VI_1
W3CHTML 4.01
3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。3.1.1
访问令牌AccessToken
OMA命名中心Autho4API范围值注册（OpenMobileNamingAuthority\Autho4API Scope Values Registry)OMA业务环境（OMAServiceEnvironment）SCR规则和流程（SCRRulesandProcedures）应用层公共安全功能（SecurityCommonFunctions）HTML4.01规范（HTML4.01Specification）用于访问受保护资源的信任凭证。在IETFRFC6749(2012)的1.4中有进一步的定义。3.1.2
授权许可AuthorizationGrant
代表资源拥有者授权（访问其受保护资源）的一种信任凭证，Autho4API客户端可以凭借授权许可获取一个访问令牌。
更新令牌RefreshToken
获取一个新的访问令牌的信任凭证。在IETFRFC6749(2012)的1.5中有进一步的定义。3.1.4
资源拥有者ResourceOwner
许可访问受保护资源的实体，例如终端用户。3.1.5
表述性状态转移RESTFu
REST(RepresentationalStateTransfer表述性状态转移）是一种针对网络应用的设计和开发方式，指的是一组架构约束条件和原则，可以降低开发的复杂性，提高系统的可伸缩性。满足REST定义的约束条件和原则的应用程序或设计就是RESTful。3.1.6
范围Scope
Autho4API客户端请求或以访问令牌的形式分发给Autho4API客户端的授权过程中资源访问权限，由一系列范围值构成。
范围值ScopeValue
在网络API资源上的一系列已定义好的授权操作。3.1.8
机密类型客户端ConfidentialClient2
YD/T2912-2015
能安全管理其认证凭证的机密性（如实现在安全服务器上且能限制访问其认证凭证的客户端）或能使用其他方式执行客户端的安全认证的客户端。3.1.9
公开类型客户端
PublicClient
不能确保其认证凭证的机密性（如执行在资源拥有者的设备上类似如本地应用或基于browser的应用）且不能使用其他方式执行客户端的安全认证的客户端。3.2缩略语
下列缩略语适用于本文件。
Autho4API
MSISDN
4概述
Advanced Encryption StandardApplication Program InterfaceAuthorization Framework forNetwork APIsCipher Block Chaining
Global SystemforMobile communications AssociationHyperText Transfer Protocol
JavaScript Object Notation
Mobile Subscriber ISDN NumberOpen Mobile Alliance
Open Mobile Naming AuthorityOperating System
Rich Communication Suite
Short Message Service
Transport Layer Security
Unified Resource Identifier
Uniform Resource Locator
Uniform Resource Name
WholesaleApplicationsCommunityeXtensible Markup Language
4.1Autho4API的制定内容
高级加密算法标准
应用编程接口
网络API授权框架
密码块链模式
全球移动通信系统联盟
超文本传输协议
javascript对象表示
移动用户ISDN号码
开放移动联盟
开放移动命名方
操作系统
富通信组件
短消息业务
传输层安全
统一资源标识
统一资源位置
统一资源命名
应用程序社区
可扩展标记语言
OMARESTful网络API结合基于IETFOAuth2.0协议的通用授权框架，以通过这些API实现授权第三方应用访问用户的网络资源。授权框架，可允许网络资源拥有者通过OMARESTfulAPI开放资源，可基于资源拥有者的需求授权第三方应用(包括桌面、手机和互联网应用)代表该用户访问资源。Auth04API基于IETFOAuth2.0系列规范（IETFRFC6749,IETFRFC6750、IETFRFC7009制定，此外还定义了以下部分：
一为授权范围值定义了OMNA注册。一第二通道，即在发送授权请求响应时，可选进行HTTP重定向。3
YD/T2912-2015
一多服务提供商提供相同服务环境下的部署场景。一根据发布的访问令牌解析资源服务器位置。一次性访问令牌。
一在以下方面的考虑：
授权范围值定义：
自包含访问令牌格式：
?服务发现；
●本地应用；
?HTTP重定向捕获机制。
4.2抽象协议流程
Autho4API的抽象流程见图1。
Autho4API
客户端
图1中的步骤描述如下：
授权请求
授权许可
授权许可
授权令牌
授权令牌
受保护的资源
图1抽象协议流程
a）Autho4API客户端请求资源拥有者的授权。资源拥有者
用户代理
Autho4API
授权服务器
Autho4APr
访问控制服务器
b）Autho4API客户端收到一个授权许可，授权许可是一个资源拥有者的授权许可凭证。c）Autho4API客户端向授权服务器请求访问令牌，提交授权许可并请求Autho4API授权服务器认证。
d）Autho4API授权服务器认证Autho4API客户端，并验证授权许可，如果验证成功则为Autho4API客户端发布访问令牌。
e）Autho4API客户端向Autho4API访问控制服务器请求访问受保护的资源，并提交访问令牌。f）Autho4API访问控制服务器验证访问令牌，如果验证成功则响应请求。5需求
5.1概述
本节描述了有关引擎Autho4API的要求。该要求的主要部分来源于GSMA的RCSAPI中授权相关的要求，可参见文档GSMARCSREQ。OMA引擎Autho4API涵盖了参考授权的相关要求，除此之外致力于提供一个更通用的授权方法，以适用于广泛的RESTful网络API。为构建该框架，本文参考了GSMARCSREQ中有关授权的可适用要求，还定义了附加要求。5.2高层次功能要求
本节描述的是有关引擎Autho4API的高层次功能要求，见表1。4
表1高层次功能要求
Autho4API-HLF-001
授权框架不可阻止应用实例访问同一资源所有者的多个资源5.3安全需求
5.3.1认证
（用户、应用或开发者有关的）认证超出了引擎Autho4API的范围。5.3.2授权
5.3.2.1通用授权
本节描述的是有关引擎Autho4API的通用授权要求。应用于该引擎的GSMARCSGSMARCSREQ中的通用授权要求见表2。表2通用授权要求一
Autho4API-RCAZ-001
Autho4API-RCAZ-002
Autho4API-RCAZ-003
Autho4API-RCAZ-004
Autho4API-RCAZ-005
Auth04API-RCAZ-006
Auth04API-RCAZ-007
Autho4API-RCAZ-008
Auth04API-RCAZ-009
Auth04API-RCAZ-010
来自GSMARCS
YD/T2912-2015
Autho4API V1.0
授权框架应使拥有RESTfulAPI公开的网络资源的用户，能够授权第三方应用，通过该RESTfulAPI，代表该用户访问这些资源授权框架应支持网络端Web应用，该应用通过用户的Web浏览器访问授权框架应该支持客户端独立的安装在用户终端的Widget应用，并支持在Web浏览器外运行
授权框架应该支持安装在用户终端的客户端本地应用授权框架应通过引导用户到服务提供商门户，来支持第三方应用启动授权请求
授权框架应使资源所有者能够对每一个请求的资源和业务操作进行授权或者拒绝访问
在用户授权第三方应用访问用户资源的情况下，授权框架应能够向第三方应用提供代表用户授权的访间令牌访问令牌应仅能由第三方应用用于限定的范围（资源操作），该范围是由用户在有授权请求时进行授权授权框架应支持在向RESTfilAPI公开的资源发送请求时，包含一个访问令牌（例如，为了该请求的范围，由第三方应用从服务提供商处获得）发送到第三方应用的通知，应在发放给第三方应用的授权的基础上，进行过滤，因此服务器不可对没有授权的应用发放通知此外，OMA还增加了一些通用授权要求，见表3。表3通用授权请求
Autho4API-AZ-001
Autho4API-AZ-002
Auth04API-AZ-003
Autho4API-AZ-004
Auth04API-AZ-005
依据请求的类型（例如计费），授权框架应支持一次性访问令牌授权框架应验证从第三方应用接收的访间令牌，确保令牌没有过期并且其范围涵盖所请求的资源
授权框架可在资源所有者授权第三方应用访间他/她的网络资源之前，方便地向资源所有者呈现第三方应用的可信赖性授权框架应该能够告知第三方应用关于所分发的访问令牌的失效时间授权框架应该支持访问令牌以特定格式进行分发和处理，以及由第三方应用作为不透明信息处理。在这种特定的访问令牌格式中，应该尽可能省略影响用户隐私的参数
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API Future versions
Autho4API V1.0
Autho4API V1.0
YD/T2912-2015
5.3.2.2OAuth2.0的特定授权
本节描述了有关引擎Autho4API的OAuth2.0的特定授权要求。应用于该引擎的GSMARCSRCSREQ中的特定授权要求，见表4。表4OAuth2.0的特定授权要求-来自GSMARCS标号
Autho4API-RCOAZ-001
Autho4API-RCOAZ-002
Autho4API-RCOAZ-003
Auth04API-RCOAZ-004
Auth04API-RCOAZ-005
Auth04API-RCOAZ-006
Auth04API-RCOAZ-007
Auth04API-RCOAZ-008
Auth04API-RCOAZ-009
Autho4API-RCOAZ-010
Autho4API-RCOAZ-011
Autho4API-RCOAZ-012
正如IETFRFC6749所指明的，授权框架应基于IETFOAuth2.0构建授权框架应支持OAuth2.0中的“授权代码工作流程”，在这里第三方应用是一个服务器端的网络应用
授权框架应支持OAuth2.0中的以下情况，第三方应用的类型可以是客户端安装的Widget应用或客户端的本地应用对于授权代码（“授权代码工作流程”）访问令牌（“隐式授权工作流程”）向客户端安装的应用（Widget或本地应用）的传递，授权框架应支持至少一种操作系统不可知和应用类型不可知的传送机制，这种机制不要求终端用户交互，比如人工输入授权代码不同于“授权代码工作流程”，授权框架可支持OAuth2.0工作流程授权框架应支持OAuth2.0中“授权服务器”和“资源服务器”的角色功能授权框架应把用户从RESTfiulAPI获取的资源作为OAuth2.0的“被保护资源”
当遵循授权代码工作流程时，每当用户授权时，授权框架应产生一个OAuth2.0授权代码
根据OAuth2.0，授权框架应支持访间令牌的授权代码的交互授权框架应将已验证用户的身份与已生成的授权代码和访间令牌进行绑定
授权框架应能够通过从应用中接收访问令牌，来确定用户的身份（例如，MSISDN)
根据OAuth2.0，授权框架应验证从应用中接收到的访问令牌另外，OMA还增加了一些特定授权要求，见表5。表5OAuth2.0的特定授权要求
Autho4API-OAZ-001
Autho4API-OAZ-002
Autho4API-OAZ-003
5.3.3数据完整性
不管那些用于规定OAuth2.0访问令牌范围的值在何处定义，都应遵从IETFRFC6749
不管那些用于规定OAuth2.0访问令牌范围的值在何处定义，只要它们的定义与IETFRFC6749保持一致性，授权框架就应能够接收和处理这些值授权框架应该制定指导方针或促进机制，用以管理那些用于规定OAuth2.0访问令牌范围的值，从而支持这些通过标准定义的值以及由服务供应商定义的作为标准值扩展的值
数据完整性不属于本标准规定的内容。5.3.4机密性
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
凭证（比如，访问令牌）可以使用纯文本格式，并以HTTP请求和应答的方式传送。IETFOAuth2.0见IETFRFC6749中的要求在传输访问令牌时应支持TLS。应用于引擎Autho4API的机密性要求，见表6。6
Auth04API-CONF-001
Autho4API-CONF-002
5.4计费
表6机密性要求
当权限授予和访问令牌以明文传输时，授权框架应支持其机密性保护授权框架可支持在第三方应用和授权框架间传输的用户信息（例如，用户email地址、MSISDN等）的机密性保护计费不属于本标准规定的内容。5.5管理和配置
本节描述了有关引擎Autho4API的管理和配置要求。应用于本标准的GSMARCS见GSMARCSREQ中的要求，见表7。表7管理和配置要求一—来自GSMARCS标号
Auth04API-RCADM-001
Auth04API-RCADM-002
Autho4API-RCADM-003
Auth04API-RCADM-004
5.6可用性
授权框架应允许第三方应用从服务提供商（例如，通过提取或动态发现）获得所需的参数，用于请求用户授权和访问用户的网络资源授权框架可使资源所有者能够规定他的/她的权限授予的持续时间授权框架应该便于以下可能性，检索先前已被授权的第三方应用的名单和哪些资源已被用户授权于每个第三方应用授权框架应该便于以下可能性，让用户删除任何先前已被授权的第三方应用的权限
本节描述了有关引擎Autho4API的可用性要求。应用于本标准中的GSMARCS见GSMARCSREQ中的要求，见表8。表8可用性要求一来自GSMARCS
Auth04API-RCUSE-001
Autho4API-RCUSE-002
Auth04API-RCUSE-003
5.7互通性
授权框架应支持以一个明确的授权对话框或用户同意请求的形式，向资源所有者呈现第三方应用的授权请求授权框架应该便于向资源所有者至少呈现第三方应用的身份、资源和这些请求授权资源上的操作
授权框架应该便于呈现资源所有者的首选语言和终端能力不属于本标准规定的内容。
5.8隐私性
本节描述了有关引擎Autho4API的隐私要求。应用于本标准中的GSMARCS见GSMARCSREQ中的要求，见表9。来自GSMARCS
表9隐私要求——
Autho4API-RCPRV-001
授权框架不能将用于向服务供应商进行认证的的用户认证凭证透漏给第三方应用
另外，OMA还增加了以下隐私要求，见表10。YD/T2912-2015
Autho4API v1.0
Autho4API v1.0
Autho4API V1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T2912-2015
移动互联网应用编程接口的授权技术要求Technical requirements of authorization frameworkfomobileinternetAPl
2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前言
1范围·
2规范性引用文件
3术语、定义和缩略语·
3.1术语和定义.
3.2缩略语
4概述
4.1Autho4API的制定内容..
抽象协议流程
5需求
概述·
高层次功能要求
安全需求·
计费：www.bzxz.net
管理和配置
可用性
互通性·
隐私性“
共享多服务提供商的情况·
体系结构
相关性/依赖性：
架构图·
功能组件和接口/参考点定义
7技术规范
客户端注册
协议端点
服务参数发现（参考性信息）
获取授权
发出访问令牌
更新访间令牌-
访问受保护的资源
多业务提供商环境（消息环境）安全考虑
YD/T2912-2015
YD/T2912-2015
8OMNA考患·
附录A（资料性附录）部署场景·..附录B（资料性附录）范围值（ScopeValues）的定义**附录B（资料性附录）“授予资源的URL前缀”资源的定义·参考文献
本标准按照GB/T1.1-2009给出的规则起草。YD/T2912-2015
本标准参考了OMA引擎Autho4APIv1.0规范OMA-RD-Autho4API-V1_0-20120327-C和OMA-ER-Autho4API-V1_0-20120327-C，与这两个规范章节和内容的对应关系如下：本标准中第3章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第3章，增加了3个定义：机密类型客户端、公开类型客户端、RESTful；，本标准中第4章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第4章，技术细节保持一致：
一本标准中第5章，对应于OMA规范的OMA-RD-Autho4API-V1_0-20120327-C的第5章，技术细节保持一致；
本标准中第6章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第6章，技术细节保持一致；
一本标准中第7章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第7章，技术细节保持一致：
本标准中第8章，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的第8章，技术细节保持一致：
一本标准中附录A，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的附录C，技术细节保持一致：
一本标准中附录B，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的附录D，技术细节保持一致：
本标准中附录C，对应于OMA规范的OMA-ER-Autho4API-V1_0-20120327-C的附录E，技术细节保持一致。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：上海贝尔股份有限公司、中国联合网络通信集团有限公司、中国信息通信研究院、中国移动通信集团有限公司、南京爱立信熊猫通信有限公司。本标准主要起草人：胡志远、孙群英、刘镝、张尼、董慧、逢淑宁、王静、刘斐、李钢。Ⅲ
1范围
移动互联网应用编程接口的授权技术要求YD/T2912-2015
本标准规定了移动互联网应用编程接口授权框架，该框架能使用户通过开放的网络能力API，尤其是RESTFulAPI，授权第三方应用（桌面、移动终端与web应用），以代表访问用户访问网络资源。本标准适用于运营商为移动互联网应用访问网络资源提供安全授权机制。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC2045
IETFRFC2046
IETFRFC2119
IETFRFC3986
IETFRFC4234
IETFRFC4346
IETFRFC5246
IETFRFC2616
IETFRFC2617
IETFRFC6749（2012)
IETFRFC6750
IETFRFC7009
FIPSAES
FIPS AESMode
GSMARCSREQ
OMAAUTHO4API_RD_10
OMAAUTHO4API_ER_10
因特网邮件协议之消息体（MultipurposeInternetMailExtensions(MIME)PartOne:Format of Internet MessageBodies)互联网邮件协议之媒体类型（MultipurposeInternetMailExtensions(MIME)PartTwo:MediaTypes)
RFC中关键词的解释(KeywordsforuseinRFCstoIndicateRequirement Levels)
统一资源标识（UniformResourceIdentifier（URD：GenericSyntax）ABNF语法规范（AugmentedBNFforSyntaxSpecifications:ABNF）传输层安全（TransportLayerSecurity（TLS）Version1.1）传输层安全（TransportLayerSecurity(TLS）Version1.2）超文本协议（HypertextTransferProtocol--HTTP/1.1）HTTP Digest认证 (HTTP Authentication:Basic and Digest AccessAuthentication)
OAuth2.0授权协议（TheOAuth2.0AuthorizationProtocol）OAuth2.0承载令牌（TheOAuth2.0Protocol:BearerTokens）令牌撤销(TokenRevocation）
高级加密算法标准（ThespecificationofAdvancedEncryptionStandard
AES块加密模式（RecommendationofBlockCipherModesofOperation)
GSMA富媒体需求（RichCommunication Suite--RCSAPIDetailedRequirements 1.1)
网络API授权框架需求（AuthorizationFrameworkforNetworkAPIsRequirements
网络API授权框架（AuthorizationFrameworkforNetworkAPIs）1
YD/T2912-2015
OMAOMNA_Autho4API
OMAOSE
OMASCRRULES
OMASECCF-VI_1
W3CHTML 4.01
3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。3.1.1
访问令牌AccessToken
OMA命名中心Autho4API范围值注册（OpenMobileNamingAuthority\Autho4API Scope Values Registry)OMA业务环境（OMAServiceEnvironment）SCR规则和流程（SCRRulesandProcedures）应用层公共安全功能（SecurityCommonFunctions）HTML4.01规范（HTML4.01Specification）用于访问受保护资源的信任凭证。在IETFRFC6749(2012)的1.4中有进一步的定义。3.1.2
授权许可AuthorizationGrant
代表资源拥有者授权（访问其受保护资源）的一种信任凭证，Autho4API客户端可以凭借授权许可获取一个访问令牌。
更新令牌RefreshToken
获取一个新的访问令牌的信任凭证。在IETFRFC6749(2012)的1.5中有进一步的定义。3.1.4
资源拥有者ResourceOwner
许可访问受保护资源的实体，例如终端用户。3.1.5
表述性状态转移RESTFu
REST(RepresentationalStateTransfer表述性状态转移）是一种针对网络应用的设计和开发方式，指的是一组架构约束条件和原则，可以降低开发的复杂性，提高系统的可伸缩性。满足REST定义的约束条件和原则的应用程序或设计就是RESTful。3.1.6
范围Scope
Autho4API客户端请求或以访问令牌的形式分发给Autho4API客户端的授权过程中资源访问权限，由一系列范围值构成。
范围值ScopeValue
在网络API资源上的一系列已定义好的授权操作。3.1.8
机密类型客户端ConfidentialClient2
YD/T2912-2015
能安全管理其认证凭证的机密性（如实现在安全服务器上且能限制访问其认证凭证的客户端）或能使用其他方式执行客户端的安全认证的客户端。3.1.9
公开类型客户端
PublicClient
不能确保其认证凭证的机密性（如执行在资源拥有者的设备上类似如本地应用或基于browser的应用）且不能使用其他方式执行客户端的安全认证的客户端。3.2缩略语
下列缩略语适用于本文件。
Autho4API
MSISDN
4概述
Advanced Encryption StandardApplication Program InterfaceAuthorization Framework forNetwork APIsCipher Block Chaining
Global SystemforMobile communications AssociationHyperText Transfer Protocol
JavaScript Object Notation
Mobile Subscriber ISDN NumberOpen Mobile Alliance
Open Mobile Naming AuthorityOperating System
Rich Communication Suite
Short Message Service
Transport Layer Security
Unified Resource Identifier
Uniform Resource Locator
Uniform Resource Name
WholesaleApplicationsCommunityeXtensible Markup Language
4.1Autho4API的制定内容
高级加密算法标准
应用编程接口
网络API授权框架
密码块链模式
全球移动通信系统联盟
超文本传输协议
javascript对象表示
移动用户ISDN号码
开放移动联盟
开放移动命名方
操作系统
富通信组件
短消息业务
传输层安全
统一资源标识
统一资源位置
统一资源命名
应用程序社区
可扩展标记语言
OMARESTful网络API结合基于IETFOAuth2.0协议的通用授权框架，以通过这些API实现授权第三方应用访问用户的网络资源。授权框架，可允许网络资源拥有者通过OMARESTfulAPI开放资源，可基于资源拥有者的需求授权第三方应用(包括桌面、手机和互联网应用)代表该用户访问资源。Auth04API基于IETFOAuth2.0系列规范（IETFRFC6749,IETFRFC6750、IETFRFC7009制定，此外还定义了以下部分：
一为授权范围值定义了OMNA注册。一第二通道，即在发送授权请求响应时，可选进行HTTP重定向。3
YD/T2912-2015
一多服务提供商提供相同服务环境下的部署场景。一根据发布的访问令牌解析资源服务器位置。一次性访问令牌。
一在以下方面的考虑：
授权范围值定义：
自包含访问令牌格式：
?服务发现；
●本地应用；
?HTTP重定向捕获机制。
4.2抽象协议流程
Autho4API的抽象流程见图1。
Autho4API
客户端
图1中的步骤描述如下：
授权请求
授权许可
授权许可
授权令牌
授权令牌
受保护的资源
图1抽象协议流程
a）Autho4API客户端请求资源拥有者的授权。资源拥有者
用户代理
Autho4API
授权服务器
Autho4APr
访问控制服务器
b）Autho4API客户端收到一个授权许可，授权许可是一个资源拥有者的授权许可凭证。c）Autho4API客户端向授权服务器请求访问令牌，提交授权许可并请求Autho4API授权服务器认证。
d）Autho4API授权服务器认证Autho4API客户端，并验证授权许可，如果验证成功则为Autho4API客户端发布访问令牌。
e）Autho4API客户端向Autho4API访问控制服务器请求访问受保护的资源，并提交访问令牌。f）Autho4API访问控制服务器验证访问令牌，如果验证成功则响应请求。5需求
5.1概述
本节描述了有关引擎Autho4API的要求。该要求的主要部分来源于GSMA的RCSAPI中授权相关的要求，可参见文档GSMARCSREQ。OMA引擎Autho4API涵盖了参考授权的相关要求，除此之外致力于提供一个更通用的授权方法，以适用于广泛的RESTful网络API。为构建该框架，本文参考了GSMARCSREQ中有关授权的可适用要求，还定义了附加要求。5.2高层次功能要求
本节描述的是有关引擎Autho4API的高层次功能要求，见表1。4
表1高层次功能要求
Autho4API-HLF-001
授权框架不可阻止应用实例访问同一资源所有者的多个资源5.3安全需求
5.3.1认证
（用户、应用或开发者有关的）认证超出了引擎Autho4API的范围。5.3.2授权
5.3.2.1通用授权
本节描述的是有关引擎Autho4API的通用授权要求。应用于该引擎的GSMARCSGSMARCSREQ中的通用授权要求见表2。表2通用授权要求一
Autho4API-RCAZ-001
Autho4API-RCAZ-002
Autho4API-RCAZ-003
Autho4API-RCAZ-004
Autho4API-RCAZ-005
Auth04API-RCAZ-006
Auth04API-RCAZ-007
Autho4API-RCAZ-008
Auth04API-RCAZ-009
Auth04API-RCAZ-010
来自GSMARCS
YD/T2912-2015
Autho4API V1.0
授权框架应使拥有RESTfulAPI公开的网络资源的用户，能够授权第三方应用，通过该RESTfulAPI，代表该用户访问这些资源授权框架应支持网络端Web应用，该应用通过用户的Web浏览器访问授权框架应该支持客户端独立的安装在用户终端的Widget应用，并支持在Web浏览器外运行
授权框架应该支持安装在用户终端的客户端本地应用授权框架应通过引导用户到服务提供商门户，来支持第三方应用启动授权请求
授权框架应使资源所有者能够对每一个请求的资源和业务操作进行授权或者拒绝访问
在用户授权第三方应用访问用户资源的情况下，授权框架应能够向第三方应用提供代表用户授权的访间令牌访问令牌应仅能由第三方应用用于限定的范围（资源操作），该范围是由用户在有授权请求时进行授权授权框架应支持在向RESTfilAPI公开的资源发送请求时，包含一个访问令牌（例如，为了该请求的范围，由第三方应用从服务提供商处获得）发送到第三方应用的通知，应在发放给第三方应用的授权的基础上，进行过滤，因此服务器不可对没有授权的应用发放通知此外，OMA还增加了一些通用授权要求，见表3。表3通用授权请求
Autho4API-AZ-001
Autho4API-AZ-002
Auth04API-AZ-003
Autho4API-AZ-004
Auth04API-AZ-005
依据请求的类型（例如计费），授权框架应支持一次性访问令牌授权框架应验证从第三方应用接收的访间令牌，确保令牌没有过期并且其范围涵盖所请求的资源
授权框架可在资源所有者授权第三方应用访间他/她的网络资源之前，方便地向资源所有者呈现第三方应用的可信赖性授权框架应该能够告知第三方应用关于所分发的访问令牌的失效时间授权框架应该支持访问令牌以特定格式进行分发和处理，以及由第三方应用作为不透明信息处理。在这种特定的访问令牌格式中，应该尽可能省略影响用户隐私的参数
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API Future versions
Autho4API V1.0
Autho4API V1.0
YD/T2912-2015
5.3.2.2OAuth2.0的特定授权
本节描述了有关引擎Autho4API的OAuth2.0的特定授权要求。应用于该引擎的GSMARCSRCSREQ中的特定授权要求，见表4。表4OAuth2.0的特定授权要求-来自GSMARCS标号
Autho4API-RCOAZ-001
Autho4API-RCOAZ-002
Autho4API-RCOAZ-003
Auth04API-RCOAZ-004
Auth04API-RCOAZ-005
Auth04API-RCOAZ-006
Auth04API-RCOAZ-007
Auth04API-RCOAZ-008
Auth04API-RCOAZ-009
Autho4API-RCOAZ-010
Autho4API-RCOAZ-011
Autho4API-RCOAZ-012
正如IETFRFC6749所指明的，授权框架应基于IETFOAuth2.0构建授权框架应支持OAuth2.0中的“授权代码工作流程”，在这里第三方应用是一个服务器端的网络应用
授权框架应支持OAuth2.0中的以下情况，第三方应用的类型可以是客户端安装的Widget应用或客户端的本地应用对于授权代码（“授权代码工作流程”）访问令牌（“隐式授权工作流程”）向客户端安装的应用（Widget或本地应用）的传递，授权框架应支持至少一种操作系统不可知和应用类型不可知的传送机制，这种机制不要求终端用户交互，比如人工输入授权代码不同于“授权代码工作流程”，授权框架可支持OAuth2.0工作流程授权框架应支持OAuth2.0中“授权服务器”和“资源服务器”的角色功能授权框架应把用户从RESTfiulAPI获取的资源作为OAuth2.0的“被保护资源”
当遵循授权代码工作流程时，每当用户授权时，授权框架应产生一个OAuth2.0授权代码
根据OAuth2.0，授权框架应支持访间令牌的授权代码的交互授权框架应将已验证用户的身份与已生成的授权代码和访间令牌进行绑定
授权框架应能够通过从应用中接收访问令牌，来确定用户的身份（例如，MSISDN)
根据OAuth2.0，授权框架应验证从应用中接收到的访问令牌另外，OMA还增加了一些特定授权要求，见表5。表5OAuth2.0的特定授权要求
Autho4API-OAZ-001
Autho4API-OAZ-002
Autho4API-OAZ-003
5.3.3数据完整性
不管那些用于规定OAuth2.0访问令牌范围的值在何处定义，都应遵从IETFRFC6749
不管那些用于规定OAuth2.0访问令牌范围的值在何处定义，只要它们的定义与IETFRFC6749保持一致性，授权框架就应能够接收和处理这些值授权框架应该制定指导方针或促进机制，用以管理那些用于规定OAuth2.0访问令牌范围的值，从而支持这些通过标准定义的值以及由服务供应商定义的作为标准值扩展的值
数据完整性不属于本标准规定的内容。5.3.4机密性
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4APIV1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
凭证（比如，访问令牌）可以使用纯文本格式，并以HTTP请求和应答的方式传送。IETFOAuth2.0见IETFRFC6749中的要求在传输访问令牌时应支持TLS。应用于引擎Autho4API的机密性要求，见表6。6
Auth04API-CONF-001
Autho4API-CONF-002
5.4计费
表6机密性要求
当权限授予和访问令牌以明文传输时，授权框架应支持其机密性保护授权框架可支持在第三方应用和授权框架间传输的用户信息（例如，用户email地址、MSISDN等）的机密性保护计费不属于本标准规定的内容。5.5管理和配置
本节描述了有关引擎Autho4API的管理和配置要求。应用于本标准的GSMARCS见GSMARCSREQ中的要求，见表7。表7管理和配置要求一—来自GSMARCS标号
Auth04API-RCADM-001
Auth04API-RCADM-002
Autho4API-RCADM-003
Auth04API-RCADM-004
5.6可用性
授权框架应允许第三方应用从服务提供商（例如，通过提取或动态发现）获得所需的参数，用于请求用户授权和访问用户的网络资源授权框架可使资源所有者能够规定他的/她的权限授予的持续时间授权框架应该便于以下可能性，检索先前已被授权的第三方应用的名单和哪些资源已被用户授权于每个第三方应用授权框架应该便于以下可能性，让用户删除任何先前已被授权的第三方应用的权限
本节描述了有关引擎Autho4API的可用性要求。应用于本标准中的GSMARCS见GSMARCSREQ中的要求，见表8。表8可用性要求一来自GSMARCS
Auth04API-RCUSE-001
Autho4API-RCUSE-002
Auth04API-RCUSE-003
5.7互通性
授权框架应支持以一个明确的授权对话框或用户同意请求的形式，向资源所有者呈现第三方应用的授权请求授权框架应该便于向资源所有者至少呈现第三方应用的身份、资源和这些请求授权资源上的操作
授权框架应该便于呈现资源所有者的首选语言和终端能力不属于本标准规定的内容。
5.8隐私性
本节描述了有关引擎Autho4API的隐私要求。应用于本标准中的GSMARCS见GSMARCSREQ中的要求，见表9。来自GSMARCS
表9隐私要求——
Autho4API-RCPRV-001
授权框架不能将用于向服务供应商进行认证的的用户认证凭证透漏给第三方应用
另外，OMA还增加了以下隐私要求，见表10。YD/T2912-2015
Autho4API v1.0
Autho4API v1.0
Autho4API V1.0
Autho4APIV1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
Autho4API V1.0
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。