具体实施方式

在以下描述中，为了解释的目的，阐述具体细节以提供对示例实施例的透彻理解。但是，显然，可以在没有这些具体细节的情况下实践各种实施例。例如，系统、算法、结构、技术、网络、处理和其它组件可以以框图形式显示为组件，以免在不必要的细节中混淆实施例。附图和描述不旨在是限制性的。

示例实施例为想要登录到多个应用的用户启用单点登录(SSO)。用户也可以被称为客户端。例如，用户可以登录到企业中的多个应用。当用户尝试登录到第一应用时，用户计算机上浏览器上的应用(例如，浏览器应用)可以生成第一个公-私密钥对[Ab和Av]，其包括用于第一应用的第一公钥[Ab]和第一私钥[Av]。

浏览器可以是支持IndexedDB和加密应用编程接口(API)的任何浏览器。IndexedDB是由web浏览器提供的用于管理对象的应用编程接口。与例如web存储相比，IndexedDB可以提供大量数据存储。另外，IndexedDB不需要结构化查询语言(SQL)来检索数据。

用户计算机上的浏览器可以将第一公-私密钥对[Ab和Av]存储在与第一应用相关联的浏览器的存储器空间(例如，IndexedDB)中。IndexedDB应用可以被用于应用数据的客户端侧存储。通过在客户端侧存储数据，减少了服务器安全存储并维护数据的负担。IndexedDB IAM可以被用于服务器数据的客户端侧存储。IndexedDB也可以被称为IndexedDB或索引DB。用于第一应用的第一公-私密钥对存储在本地浏览器存储空间中，其存储与应用相关联的信息。

在第一公-私密钥对[Ab和Av]存储在浏览器的IndexedDB中之后，用户的浏览器被重定向到登录应用，其中第一公钥[Ab]是参数之一。登录应用与服务器(诸如访问管理服务器)相关联。访问管理服务器也可以被称为身份访问管理(IAM)服务器或Oracle访问管理(OAM)服务器。

登录应用在用户的浏览器中生成第二公-私密钥对[Sb，Sv]。然后经由客户端设备提示用户录入凭证信息(例如，用户名、电子邮件地址、密码、令牌等)。可以通过客户端设备上显示的表单提示用户录入他们的凭证信息。在用户录入他们的凭证之后，用户可以提交表单，并且表单被提交到与服务器相关联的登录应用。用户可以通过在录入他们的凭证信息之后选择例如提交按钮来提交表单。

如果用户输入的凭证信息是正确的(例如，用户录入了他们正确的用户名和密码)，那么用户被认证并且为用户生成安全令牌。安全令牌可以是JSON Web Token(JWT)安全令牌。在示例实施例中，JWT是签署的JWT。JWT由服务器(例如，IAM服务器)使用只有服务器知道的私钥签署。因此，不能操纵或修改示例实施例中公开的JWT。安全令牌嵌入了第二公钥[Sb]。因此，用第二公钥[Sb]为用户生成的安全令牌可以被识别为SJWT[Sb]。为服务器生成的令牌可以被称为SJWT。“S”表示JWT令牌在服务器的域中。为第一应用(应用A)生成的令牌可以是AJWT。“A”表示JWT在第一应用的域中。为第二应用(应用B)生成的令牌可以被称为BJWT。“B”表示JWT用于第二应用。

在本公开中，第一应用令牌是指为应用A生成的应用令牌，第二应用令牌是指为应用B生成的应用令牌。为服务器生成的安全令牌也可以被称为服务器令牌。应用A和应用B可以包括使用访问管理服务器的任何应用。

然后将安全令牌(SJWT[Sb])存储在浏览器的本地存储空间中。令牌SJWT[Sb]现在可以被用于通过对由不可提取的密钥Sv向服务器发出的签署请求来安全地与服务器应用通信(例如，sign{Sv，{request，SJWT(Sb)})。安全令牌可以存储在浏览器的IndexedDB IAM中，这是客户端浏览器存储空间，其存储与服务器相关联的信息。Sv和SWJT[Sb]都可以保存在IndexedDB IAM中。

存储在本地数据存储库中的第一私钥[Av]和第二私钥[Bv]可以被用于签署请求并且具有对应的公钥[Ab，Bb]的应用JWT(例如，AJWT、BJWT)作为授权信息被发送。

由于安全令牌SJWT[Sb]是经认证的令牌，因此经认证的令牌SJWT[Sb]可以被用于通过向服务器发出签署的请求(sign{Sv，{request(Ab)，SJWT[Sb]}})以将SJWT[Sb]交换为应用令牌AJWT[Ab]，从服务器计算机获得用于第一应用的应用令牌。用于第一应用的应用令牌可以由例如AJWT[Ab]表示。该应用令牌包括应用JWT(AJWT)以及第一公钥[Ab]。通过向服务器发出签署的请求(sign{Sv,{request(Ab),SJWT[Sb]}})以将SJWT[Sb]交换为应用令牌AJWT[Ab]，服务器令牌SJWT[Sb]被交换为应用令牌AJWT[Ab]。在用户获得用于第一应用的令牌之后，用户对于第一应用通过认证。用户现在可以访问第一应用。

如果用户想要针对第二应用获得认证，那么第二应用将为第二应用生成第三公-私密钥对[Bb和Bv]。第三公-私密钥对[Bb和Bv]可以存储在浏览器的本地存储库中。例如，第三公-私密钥对[Bb和Bv]可以存储在浏览器的IndexedDB应用中。用于第二应用的第三公-私密钥对可以存储在存储与应用相关联的信息的本地浏览器存储空间中。

在本地存储第三公-私密钥对[Bb和Bv]之后，将用户的浏览器重定向到登录应用。登录应用将向用户的浏览器返回JavaScript。JavaScript指示在浏览器上运行的脚本，该脚本生成密钥对并访问IndexedDB，该脚本嵌入在当浏览器导航到其时由应用返回的页面中。登录应用将返回JavaScript，因为当用户登录到第一应用时，创建了安全令牌SJWT[Sb]。同一个服务器JSON Web Token(SJWT)可以被用于交换另一个应用JWT。因此，用于生成第一应用令牌的同一个JWT可以被用于为第二应用创建应用令牌BJWT[Bb]。此时，用户已对于第二应用通过认证。用户现在可以访问第二应用。

在示例实施例中，服务器使用在客户端侧生成的密钥对来维持登录会话。说明书中描述的服务器可以指多种不同类型的服务器。认证服务器可以进行初始认证以开始登录会话。然后认证服务器负责验证与会话相关联的公钥。每个请求可以包括由服务器验证的数字签名。

为了联系尊重会话的其它“数据服务器”，客户端可以使用数字签名。数据服务器可以遵从认证服务器以验证用于会话的签名。通过数据服务器将签名发送到认证服务器以进行验证，数据服务器向认证服务器询问会话的公钥以便它可以进行验证，认证服务器在初始认证后向客户端发出令牌/证书(例如，JWT)，使用预先存在的其公钥与数据服务器共享的密钥对对其进行签署，数据服务器可以遵从认证服务器以验证用于会话的签名。然后，当客户端向数据服务器发出会话请求时，它使用会话私钥和来自身份服务器的令牌发送数字签名。然后，数据服务器(a)验证令牌以确定会话的公钥，以及(b)使用来自JWT的公钥验证请求的数字签名。

示例实施例使用非对称签名来代替例如使用cookie向web控制台提供专用会话。cookie是存储在用户的计算机上并存储可以被用于在用户的初始登录之后访问附加应用的数据的小文件。Cookie可以被未经授权的用户伪造、窃取或获得。因此，使用cookie使用户永久登录是不安全的。

Cookie包括标识符和唯一识别会话的字符串。浏览器会将那个cookie发送到为那个网站加载的每个页面。因此，当用户访问网站的不同页面时会验证cookie，而不是在每次访问不同页面时都要求用户重新录入其凭证。

但是，cookies常常通过不安全的连接被发送。另外，cookie可能受到网络钓鱼攻击或欺骗。例如，不同机器上的某个人可以通过欺骗用户来窃取用户的账户信息。Cookie使用双方都知道的对称秘密，并通过与所访问站点的连接以明文形式发送。因此，cookie信息存在被未授权用户识别出的风险。

示例实施例使用被签署的非对称密钥以让用户从浏览器调用API。允许客户使用为特定客户端会话签署的非对称密钥从浏览器内的JavaScript调用表征状态传输(REST)API。会话包括期望在会话期间用户与网站或web应用的整个交互过程中持续存在的信息的存储。

示例实施例调用REST API来表示与网站的经认证的会话。代替使用非对称秘密(诸如用cookie完成的)示例实施例使用仅以安全方式存储在浏览器中的非对称密钥。代替每次加载新网页时都在网线上发送秘密，使用非对称密钥。使用私钥对请求进行签署。在示例实施例中，由于公钥嵌入在JT内，因此公钥没有被注册。但是，在替代实施例中，可以向正在验证会话的网站注册公钥。

根据示例实施例，客户的浏览器可以进行API调用并且可以非对称地对API调用进行签署。使用安全地存储在浏览器中的秘密的知识证明对调用进行签署。服务器可以验证你的会话，而无需发送易受例如黑客攻击、网络钓鱼欺骗等的机密。

示例实施例提供身份管理领域中的单点登录的新颖方法。与登录服务器建立会话，该会话可以被用于跨许多站点的单点登录。用户可以通过单点登录过程登录到多个不同的应用。虽然描述了单点登录，但是示例实施例可以用于单点登录以外的情况。

身份和访问管理系统

图1是根据一些示例实施例的包括身份和访问管理系统100的计算环境的简化框图。

如图1中所示，身份和访问管理系统100包括用户110、客户端设备120、通信网络130、浏览器140、目标资源系统170、应用150、访问管理服务器160以及访问管理服务器160的数据存储库161。数据存储库161可以存储例如用于会话的密钥对的公钥。应用150可以存储在目标资源系统170上。

身份和访问管理系统100也可以被称为IAM系统。客户端也可以被称为身份和访问管理系统100的客户端。客户端设备120可以是各种类型的设备，包括但不限于移动电话、平板电脑、台式计算机等。

服务器可以包括单点登录(SSO)系统162和会话管理系统163。浏览器140也可以被称为浏览器应用。服务器还可以包括可以被用于认证用户的认证系统164。在用户录入其凭证信息之后，可以对用户进行认证。服务器还可以包括授权系统165。授权系统165可以授权用户并允许经认证的用户访问应用。

访问管理服务器160可以是例如身份访问管理(IAM)服务器或Oracle访问管理(OAM)服务器。访问管理服务器160可以是包括处理器和存储器的计算机。访问管理服务器160可以被用于执行访问管理。在整个描述中，访问管理服务器也可以被称为认证服务器或服务器。服务器160可以存储将用于登录的应用。用于确定用户是否可以登录到应用的应用可以被称为登录应用、服务器应用、认证应用、访问管理器(AM)应用或身份访问管理(IAM)应用。

服务器包括用于提供对计算环境内的受保护资源的安全访问的能力。在某些实施例中，服务器包括为访问受保护资源的用户提供单点登录(SSO)认证的能力。SSO认证可以指由服务器提供的会话和用户认证服务，该服务允许用户使用登录凭证(例如，用户名和密码)的一个集合来访问由服务器管理和/或保护的多个资源，而用户不必每次都重新录入登录凭证来访问各个受保护的资源。在某些示例中，受保护资源可以包括IAM系统中的应用、文档、文件、网页、web内容、计算资源。

身份和访问管理系统100可以由执行计算机可读指令(例如，代码、程序)以实现服务器的一个或多个计算系统实现。如图1中所描绘的，服务器包括各种子系统，包括单点登录(SSO)系统162和会话管理系统163。作为其处理的一部分由服务器使用或生成的数据或信息的部分可以存储在持久性存储器中，诸如可能经由一个或多个通信网络通信地耦合到服务器的数据存储库161。例如，数据存储库161可以存储与服务器为访问受保护资源的用户建立的SSO会话相关的信息、与用户相关的用户凭证信息等。图1中描绘的系统和子系统可以使用由计算系统的一个或多个处理单元(例如，处理器、核心)、硬件或其组合执行的软件(例如，代码、指令、程序)来实现。软件可以存储在非暂态存储介质上(例如，存储器设备上)。

客户端设备120可以包括浏览器140。浏览器140可以是用于访问互联网上的信息的web浏览器。浏览器140可以包括与浏览器140相关联的存储空间。例如，浏览器140可以包括浏览器应用存储空间143、IndexedDB App A 141、IndexedDB App B 144和IndexedDBIAM 142。IndexedDB App A 141可以存储关于第一应用的信息并且IndexedDB App B可以存储关于第二应用的信息。IndexedDB IAM142可以存储关于访问管理服务器的信息。IndexedDB也可以被称为IndexedDB。IndexedDB是由web浏览器提供的JavaScript应用编程接口(API)，用于管理对象的数据库。JavaScript在本公开中也可以被称为JavaScript代码。如图1中所示，浏览器IndexedDB App A 141、浏览器IndexedDB App B 144和浏览器IndexedDB IAM142本地存储在用户的客户端设备上。对于每个应用并且对于服务器存在分离的IndexedDB，因为IndexedDB是特定于域的。第一个域中的JavaScript将无法访问存储在用于另一个域的网站的IndexedDB中的资源。

在示例实施例中，用户可以通过录入输入统一资源定位符(URL)或识别所请求资源的其它数据使用用于应用的用户界面(UI)(其可以是图形用户界面(GUI)为应用请求对存储在目标资源系统170上的受保护资源(例如，第一应用)的访问。在某些实施例中，服务器被配置为拦截来自应用的请求，认知尝试访问受保护资源的用户，并且在成功认知后为用户创建会话并向用户提供对受保护资源的访问。在某些示例中，在同一个用户会话中(即，在仍登录到第一应用的同时)，用户可以尝试访问存储在目标资源系统170上的另一个受保护资源(例如，第二应用)。由于第二应用也受服务器保护，因此，在某些实施例中，服务器确定用户是否被授权访问第二应用以及第二应用是否是启用SSO的资源。如本文所使用的，启用SSO的资源是指可以为其启用SSO处理以提供对资源的用户访问的资源。

如果用户被授权访问第二应用并且第二应用是启用SSO的资源，那么服务器在确定用户会话是活动的并且仍然有效时，执行SSO认证以使用户能够访问受保护的资源。在一些情况下，服务器可以维护单个SSO会话，以在认证之后为用户提供对多个资源的访问。

在某些示例中，多个资源可以表示如上所述的不同应用。在其它示例中，多个资源可以表示同一应用内的不同网站、来自同一网站的不同网页等。

浏览器140可以使用Web Crypto API。Web Crypto API是可以在web应用中执行加密操作的接口。Web Crypto API是可以通过允许web应用执行加密功能来提高web应用的安全性的接口。

登录到第一应用的方法-令牌公钥

图2图示了根据一些示例实施例的用于登录到第一应用的方法200的序列图。在图2所示的示例中，公钥是令牌。

如图2中所示，在步骤210处，用户110可以请求访问第一应用。第一应用也可以被称为应用A或AppA。用户使用浏览器请求访问第一应用。图2中所示的步骤也可以被称为身份和访问管理系统100的元素之间的调用、系统调用、请求或web请求。如以上所讨论的，访问管理服务器也可以被称为IAM服务器、OAM服务器或服务器。另外，服务器可以包括用于执行登录的应用。该应用可以被称为登录应用、OAM应用、IAM应用或认证应用。登录应用可以是云基础设施登录应用。

在步骤211处，客户端设备上的浏览器140向第一应用150发送请求(例如，GET请求)，以便获得对第一应用150的访问。具体而言，诸如浏览器应用之类的应用将发送请求。GET请求可以被用于从指定的源请求数据。GET请求使用超文本传输协议(HTTP)来启用客户端和服务器之间的通信。

在步骤212处，第一应用150向浏览器140返回JavaScript。返回的JavaScript可以包括作为嵌入在由第一应用返回的页面中的脚本运行的代码，其生成密钥对并将密钥对持久保存在IndexedDB中。JavaScript可以检查浏览器的IndexedDB上是否存在有效JWT。

在步骤213处，浏览器140使用来自第一应用150的JavaScript检查是否存在有效的JSON web令牌(JWT)。JWT是签署的JWT，公钥嵌入在JWT中。JWT是具有来自客户的公钥的文档。JWT是JSON格式的证书。JWT令牌是客户端认证的安全方法。JWT文档由认证服务器签署。认证服务器可以使用用于验证公钥的任何登录机制对JWT文档进行签署。浏览器可以存储会话信息。因此，无需将数据存储在认证服务器上即可创建web会话。

在步骤214处，如果确定不存在有效JWT，那么浏览器130生成第一密钥对(例如，[Ab，Av])并将生成的第一密钥对存储在浏览器IndexedDB App A141中。具体而言，浏览器上的应用生成第一密钥对。在示例中，Ab表示第一对密钥的公钥并且Av表示私钥。私钥留在客户端侧的浏览器中，永远不会离开浏览器。例如，私钥可以存储在IndexedDB App A 141中。私钥是不可提取的，只能用于通过浏览器签署。另外，只有用于第一应用(应用A)的域可以访问第一密钥对Ab和Av。

公钥对公众可用并且可以发送给任何人。但是，私钥不能发送到任何地方。公钥可以发送到浏览器之外，诸如发送到将验证密码的服务器或系统。然后，验证密码的IAM服务器可以为会话关联那个密钥。

私钥Av在用于第一应用A的域中并且私钥Bv在用于第二应用B的域中。应用B不能访问私钥Av并且应用A不能访问私钥Bv。即，如果它们在不同的域中，那么一个应用就不能访问另一个应用的私钥。用于应用A的令牌与用于应用B的令牌不同，因为每个应用在不同的域中并且因此具有其它应用无法访问的不同私钥。

因此，没有什么是可以劫持的。例如，当使用cookie时，cookie本身常常随请求一起发送。在示例实施例中，私钥不与请求一起发送。私钥不离开浏览器存储空间。浏览器维护密钥，使其不可提取。它以无法被读取的方式存储。浏览器可以使用私钥对请求进行签署，但是浏览器不会自己发送私钥。

为了清楚和易于理解的目的，在整个描述中，密钥对被称为第一、第二和第三密钥对。第一密钥对被称为[Ab，Av]，因为它与第一应用，应用A对应。第二密钥对被称为[Sb，Sv]，因为它与用于服务器的密钥对对应。第三密钥对被称为[Bb，Bv]，因为它与第二应用，应用B对应。密钥对由浏览器140生成。

不可提取的私钥(例如，Av)存储在浏览器存储空间中并且被用于创建牢不可破的登录会话。私钥本身不会发送到浏览器存储空间之外。此外，存储在客户端侧的私钥是不可提取的。浏览器沙箱提供了用于防止提取私钥的有保障的机制。私钥以无法被读取的方式存储。浏览器使用私钥进行签署，例如数字签名或对访问管理服务器的调用。

这创建了牢不可破的登录会话，其不能被钓鱼或被盗并且不能被用于攻击用户。由于私钥无法从客户端的浏览器中提取出来。因此，可以请求使用私钥的签名，但无法获取或提取私钥本身。可以使用JavaScript中名为Web Crypto API的模块获取用于私钥的签名。

公钥可以存储在访问管理服务器上，或者公钥可以存储在客户端侧。如果公钥存储在服务器上，那么服务器将公钥存储在本地。例如，公钥可以存储在服务器的数据存储库或数据库中。公钥与用于用户的会话相关联。当期望公钥信息时，可以在服务器的数据存储库中识别和查找它。

可替代地，公钥可以存储在客户端侧。例如，公钥可以存储在与浏览器相关联的存储空间上。

图16图示了根据一些示例实施例的IndexedDb中的密钥存储。如图16中所示，密钥存储在IndexedDb中。图16是存储在应用A的IndexedDb中的密钥的示例。

在步骤215，浏览器向服务器160发送请求(例如，GET请求)，该请求包括第一密钥对的第一公钥(例如，Ab)。请求是要授权公钥。

在步骤216处，将JavaScript返回给浏览器。服务器将来自浏览器的公钥与会话相关联。如图1中所示，会话信息可以存储在服务器160的数据存储库161中。服务器160然后可以通知浏览器140用户被认证。

在步骤217处，浏览器140为服务器生成并存储第二密钥对(例如，[Sb，Sv])。第二密钥对存储在浏览器IndexedDB IAM 142中。第二密钥对位于登录应用或服务器应用的域中。第二公钥Sb和第二私钥Sv也可以被称为服务器私钥和服务器公钥。

在步骤218处，用户经由浏览器140录入他们的凭证。例如，用户为第一应用录入他们的用户名和密码。如果用户录入正确的凭证信息，那么可以对用户进行认证。

在步骤219处，浏览器140向服务器160发送请求以授权用户110登录到第一应用。成功的认证(例如，凭证信息是正确的)被传递到服务器160。浏览器140将凭证信息(例如，用户名和密码)连同公钥一起发送到服务器160。可以使用POST方法将信息发送到服务器160。POST可以被用于向服务器发送数据以在服务器中创建和/或更新信息。通过POST发送到服务器的数据存储在HTTP请求的请求正文中。

服务器接收用户名和密码并检查信息是否正确。会话信息包括诸如会话的有效期(例如，诸如12小时或一天)之类的会话信息。

此时，浏览器已经创建了公-私密钥对，并且已经将公钥与登录凭证一起发送到身份管理应用，以便登录应用可以对会话进行认证。登录应用将检查它是否是有效的会话。与服务器相关联的登录应用取得数字签名和公钥并验证数字签名。登录应用还将检查签署的材料的时间戳是否正确。在成功验证数字签名后，服务器将对调用进行认证。

在步骤220处，登录应用将创建由其自己的私钥(Sv)签署的JWT。这个JWT是为维护会话而创建的并且在其内部包含Sv、Sb。服务器160向浏览器140发送包括公钥Sb的签署的JWT(SJWT[Sb])。因此，JWT包含Sb，并且包括Sb的JWT被发送回浏览器。作为图2中创建的第一个JWT的SJWT[Sb]被创建用于维护与服务器的会话。

在步骤221处，浏览器将存储包括公钥Sb的签署的JWT。包括公钥Sb的签署的JWT(SJWT[Sb])可以存储在浏览器IndexedDB IAM 142中。

图17图示了根据一些示例实施例的存储在IndexedDb中的JWT。如图17中所示，密钥存储在IndexedDb中。图17是存储在IndexedDb IAM中的JWT的示例。

在步骤222处，浏览器将使用服务器的私钥Sv连同第一应用(Ab)的公钥对请求进行签署，并将这个请求发送到登录应用。执行这个刷新调用以便获得其内部包含Ab的JSONWeb Token(JWT)。因此，获得另一个包含Ab的JWT。

通过使用公钥来验证访问第一应用的请求。公钥被用于验证数字签名。签名是使用私钥在客户端设备上生成的。浏览器可以使用这个私钥对将要发送到登录应用的任何内容进行签署。

在步骤223处，服务器160向浏览器140发送AJWT[Ab]。此时，当用户成功登录到应用A时，AJWT返回到浏览器。在步骤222中发送的SJWT[Sb]在安全交换中交换AJWT[Ab]。

在步骤224处，浏览器能够使用用于第一应用的签署的安全令牌来访问第一应用。浏览器使用签署的JWT对应用A进行调用。请求由应用A的私钥签署。浏览器发送与由服务器签署的应用A私钥对应的JWT。由于JWT是由服务器(例如，IAM服务器)的私钥签署的，因此这个JWT可以由服务器验证。因此，第一应用可以询问服务器是否可以信任该JWT。

如果服务器授权签署的请求，那么用户现在登录。在成功登录之后，第一应用将存储与会话相关联的公钥。

应用相信它用来验证请求的公钥是与原始认证会话相关联的公钥。这可以通过将公钥放在由它知道它可以信任的服务器签署的证书中来完成。在上述示例中，公钥被放置在由服务器签署的证书中。但是，替代实施例包括将公钥存储在数据库的服务器中，下面将参考图18和19对其进行更详细的描述。

在所描述的示例中，登录应用使用其自己的密码术对JWT进行签署以返回给客户端设备。因此，登录应用不必在数据库中查找，并且公钥随请求一起发送。客户端将JWT连同嵌入在JWT中的公钥与每个请求一起发送，因而应用不需要在数据库中查找公钥。公钥在请求中，并且登录应用知道它可以信任该信息，因为JWT是由服务器本身签署的。代替将公钥存储在数据库中，存在以受信任的方式存储公钥的令牌，使得将其发送回浏览器，并且它每次发送那个令牌，因此应用不必在数据库中查找公钥。

因此，使用非对称密码术创建会话。当用户尝试登录到一个应用或多个应用时，可以应用用于创建会话的非对称密码术。另外，关于单点登录会话描述示例实施例，但是，非对称密码可以应用于单点登录会话以外的情况。

在单点登录情况下，用户不需要为他们访问的每个应用录入他们的凭证。用户无需录入其凭证即可登录到第二应用。

在用于存储第一密钥对信息的另一个示例实施例中，可以将公钥存储在浏览器侧而不是认证服务器侧。因此，代替要求认证服务器对第二会话执行验证，浏览器可以使用可以在浏览器本地使用的签名验证机制或解密机制基于来自第一会话的信息来验证第二会话。因此，可以存储数百万个会话而无需在服务器的数据库中查找密钥信息。即，示例实施例允许在没有任何服务器侧状态的情况下跟踪登录会话，同时排除中间人攻击和会话劫持攻击。

图3图示了根据另一个示例实施例的用于登录到第一应用的方法300的流程图。

如图3中所示，在步骤301处，用户想要登录到第一应用(例如，AppA)。在步骤302处，浏览器上的应用检查是否存在有效会话。如果存在有效会话，那么在步骤303处，用于浏览器的用户界面可以指示用户已经登录到应用。

在步骤304处，如果不存在有效会话，那么浏览器中的应用可以创建并存储第一密钥对。例如，第一密钥对可以是[Ab，Av]。Ab表示用于会话的公钥并且Av表示用于会话的私钥。

在步骤305处，将浏览器重定向到认证服务器，其中Ab作为请求中的公钥。

在步骤306处，认证服务器返回检查有效认证JWT是否存在于IndexedDB中的JavaScript。有效的经认证的JWT可以被指示为SJWT。

如果在步骤306处确定IndexedDB中存在有效的认证JWT，那么方法前进到步骤310。

在步骤310处，浏览器发送请求以获取其中具有Ab的应用AJWT以换取SJWT。这个请求由Sv签署。

在步骤311处，认证服务器返回其中具有Ab的应用JWT(AJWT)。即，认证服务器返回AJWT[Ab]并将用户重定向到第一应用。

在步骤312处，浏览器中的应用存储用于访问资源的AJWT。

在步骤313处，用户现在已登录。

如果在步骤306处确定不存在有效的认证JWT，那么在步骤307处认证服务器返回创建并存储第二密钥对(例如，[Sb，Sv])的JavaScript。

在步骤308处，提示用户录入他们的凭证信息。用户录入他们的凭证并发送具有第二公钥(Sb)和第一公钥(Ab)的请求。

在步骤309处，认证服务器验证凭证并创建其中具有第二公钥(Sb)的SJWT。

该方法然后前进到步骤310、311、312和313，如上所述。

在用户登录到第一应用之后，用户可以登录到第二应用，其在与第一应用不同的域中，而无需重新录入他们的凭证信息。

登录到第二应用的方法–令牌公钥

由于第二应用(应用B)和第一应用(应用A)在不同的域中，因此需要对每个应用执行访问应用的授权。即，访问应用B需要授权，并且访问应用A需要分离的授权。

用于应用A的令牌不能用于应用B，因为应用B所需的私钥在应用B的域中，并且初始令牌仅包含应用A的公钥。对应用B进行调用的脚本无法访问存储在应用A的域中的私钥，即使它们位于客户端侧。

过去，如果要与第二应用建立会话，那么用户直接与第二应用建立会话。在示例实施例中，单点登录被用于允许用户访问第二应用，而无需用户对第二应用执行第二授权。示例实施例使用具有SJWT[Sb]的第二密钥对(Sb，Sv)来为应用A和应用B生成不同的令牌，从而支持单点登录。

由于应用A和应用B位于不同的域中，因此访问每个应用将需要不同的令牌。一个令牌包含用于应用A的会话的公钥，而另一个令牌包含用于应用B的会话的公钥。但是，由于示例实施例允许单点登录，因此无需再次向用户询问凭证即可获得第二令牌。用户不需要重新录入他们的凭证信息。

位于服务器的域中的服务器令牌SJWT被用于访问两个应用。在认证完成之后，并且存在用于服务器的域的令牌(SJWT)，可以请求为其它域中的其它应用获取其它令牌。虽然描述了第二应用，但是可以对第三应用、第四应用等执行该方法。

为了登录到第二应用，浏览器140将使用在图2的步骤217中生成的第二私钥(Sv)。浏览器将对与访问第二应用155的请求相关联的材料进行签署。例如，请求可以包括当前时间戳或用户名。使用私钥创建非对称数字签名。服务器私钥是不可提取的，并且是在访问第一应用时与初始认证请求一起创建的。浏览器使用来自位于浏览器中的存储空间中的私钥以便签署请求。即，私钥是不可提取的，但可以被浏览器的API用来签署请求。

如果已经与服务器建立了会话，那么浏览器将使用它已经存储的服务器私钥来认证与第二应用的会话。浏览器可以发送请求连同用于第二应用的公钥，并且登录应用将签署该请求，从而授权对第二应用的访问。浏览器可以将签署的信息发送到第二应用，并且第二应用将认证会话并允许访问第二应用。

当向第二应用做出请求(例如，web请求)时，使用用于第二应用的私钥对请求进行签署。请求还包括AJWT。Av(应用A的私钥)将签署请求并且授权报头将具有AJWT[Ab]。当评估授权时，通过使用Av进行签署而创建的签名将用Ab进行验证。第二应用可以验证令牌来自服务器，从中提取公钥，并使用令牌来验证来自浏览器的签名。然后将认证与第二应用的会话。

图4图示了根据一些示例实施例的用于登录到第二应用的方法400的序列图。图4中所示的步骤在执行图3中的步骤并且用户已成功登录到第一应用(应用A)之后发生。在用户已经登录到第一应用之后执行将用户登录到第二应用的示例实施例。在图4所示的示例中，公钥是令牌。

在步骤410处，用户110想要访问第二应用155(例如，AppB)。此时，用户已经登录到第一应用(AppA)，并且创建了用于第一会话的私钥并将其存储在用于浏览器140的存储空间中。例如，私钥可以存储在存储空间IndexedDB IAM 142中。即，图2中所示的序列已在执行图4中所示的序列之前执行，并且用户已登录到第一应用。用户现在想要访问与第一应用(例如，AppA)不同的第二应用(例如，AppB)。

在步骤411处，浏览器140向第二应用155发送请求。请求是访问第二应用155。请求可以是例如GET请求。

在步骤412处，第二应用(应用B)将JavaScript发送回浏览器。第二应用155可以返回将用于检查有效JWT是否存在的JavaScript。

在示例实施例中，JavaScript代码可以被用于认证。因此，密钥被用于对及时数据进行签署。例如，及时数据可以包括例如时间戳和表示用户的姓名。数据以加密方式签署，使得可以使用公钥验证生成的签名，作为只有拥有浏览器认证的私钥的人才能做出那个签名的证明。浏览器将获取签名并将其连同来自服务器的对数据的请求一起发送。签名可以位于HTTP报头中以确保安全传输。

在步骤413处，JavaScript被用于检查是否存在有效JWT。用于第二应用155的JavaScript代码将识别是否存在已生成的密钥对，以及它是否在本地存储空间中可用。JWT将具有时间戳以示出它是否对会话有效。在步骤413处，浏览器140使用浏览器140从第二应用155接收的JavaScript来检查是否存在有效JWT。

在步骤414处，如果在步骤413处确定不存在用于第二应用(应用B)的有效JWT，那么浏览器将生成第三公-私密钥对(Bb和Bv)。在第三密钥对中，Bb是公钥并且Bv是私钥。私钥Bv不被发送到第二应用155或服务器160。代替地，私钥保持本地存储在浏览器140处，诸如浏览器IndexedDB App B 144中。私钥Bv被用于签署请求。

在步骤415处，公钥Bb被发送到服务器应用。浏览器140向认证服务器160发送请求，该请求包括用于授权访问第二应用155的公钥。请求可以是GET请求。发送到第二应用155的请求包括在步骤414处由浏览器生成的公钥(Bb)。

在步骤416处，服务器应用将发送回另一个JavaScript以检查是否存在有效SJWT。

在步骤417处，使用JavaScript来确定是否存在有效的服务器令牌(SJWT)。确定是否存在有效的认证服务器JWT(SJWT)。

在步骤418处，如果确定存在有效的服务器令牌SJWT，那么浏览器可以确定它们在登录应用的域中。如果存在有效的认证服务器JWT，那么在步骤418处获得JWT并用在图2的步骤217中生成的第二私钥(Sv)进行签署。

在步骤419处，由于确定存在有效的SJWT，因此浏览器将带有Bb的SJWT发送到服务器应用。浏览器140发送签署的JWT，包括第二公钥(Sb)和第三公钥(Bb)。具有包含SJWT[Sb]和Bb的请求正文的请求使用Sv签署并被发送到IAM服务器。这可以被表示为sign(Sv,{SJWT[Sb],Bb})。

在步骤420处，服务器创建具有嵌入在JWT中的公钥[Bb]的新JWT。浏览器接收用于应用B的令牌以换取SJWT。浏览器接收令牌BJWT[Bb]以换取SJWT。应用B信任由服务器签署的JWT。此时，存在包含Bb的BJWT并且它将被发送回浏览器。

在步骤421处，浏览器使用应用B私钥对应用B进行调用。浏览器发送与由服务器签署的应用B私钥对应的JWT。应用B将与服务器检查，以便确定这个令牌的真实性，因为服务器使用服务器自己的私钥对令牌进行签署。用户无需任何种类的凭证认证即可登录到应用B并且可以访问应用B。

如示例实施例中所公开的，公钥与登录会话相关联，并且使用公钥验证包括私钥的数字签名。服务器将检查例如已签署的材料的时间戳信息以确保该材料是最近签署的。在成功验证那个数字签名后，调用通过认证。

在登录到第一应用并登录到第二应用的两个示例实施例中，第一密钥对的私钥仅存储在浏览器侧。

用于应用A的会话的令牌包括用于应用A的公钥。用于应用B的会话的令牌包括用于应用B的公钥。由于用于应用B的私钥在应用B的域并且用于应用A的私钥在应用A的域中，因此为每个应用生成分离的令牌。对应用B进行调用的脚本无法访问应用A的私钥。对应用A进行调用的脚本无法访问应用B的私钥。因此，每个应用具有它们自己的公共令牌以便获得私有令牌。

用户界面

图5图示了根据一些示例实施例的显示用于访问第一应用的信息的用户界面500。

如图5中所示，当前“姓名”511、“租户名”512和“公钥ID”513信息为空白。当用户选择登录按钮514时，用户将被指引到图6中所示的界面。

图6图示了根据一些示例实施例的用于录入云租户信息的用户界面600。图6中所示的用户界面可以与位于浏览器上的应用对应。

示例实施例针对云计算系统。因此，在云计算环境中可以有多个租户。因此，如图6中所示，客户录入其租户信息以便登录到云计算环境。计算系统可以是包括多租户环境的云基础设施系统。多租户环境可以包括服务器为多个租户或客户提供服务的环境。

如用户界面600中所示，用户已提供租户信息并且提示用户登录到云计算环境。

在录入租户信息之后，用户可以选择继续按钮620。然后租户登录到云计算环境，如图7中所示。

图7图示了根据一些示例实施例的指引用户登录到特定基础设施的用户界面700。

用户可以通过选择链接720以用他们的凭证登录来选择用他们的凭证登录。

图8图示了根据一些示例实施例的用于录入凭证信息的用户界面800。

如图8中所示，提示用户录入用户名810和密码820。在用户录入他们的用户名和密码并选择登录按钮830之后，服务器处理请求。

图8可以与图2的步骤218对应，在此期间用户录入他们的凭证信息以便访问第一应用。用户录入他们的凭证信息，诸如用户名710和密码711，然后用户登录到系统。

图9图示了根据一些示例实施例的在处理请求时显示的用户界面900。

图10图示了根据一些示例实施例的显示用于访问第一应用的完整信息的用户界面1000。在用户在图8中录入他们的凭证信息并且如图9中所示处理请求之后，用户将被指引到用于第一应用的页面。如图10中所示，“姓名”、“租户名”和“公钥ID”信息现已完成。在处理完请求之后，如图9中所示，在用户界面上显示用户界面，该用户界面显示访问第一应用的完整信息。

当用户期望访问第二应用时，显示用于登录到第二应用的用户界面。

图11图示了根据一些示例实施例的显示用于访问第二应用的信息的用户界面。

如图11中所示，用于访问第二应用的信息不完整。过去，为了让用户访问第二应用，用户会对第二应用执行分离的授权处理。即，用户将执行与图6-9中所示的步骤相似的步骤，但针对第二应用。但是，代替要求用户重新录入凭证信息，当用户选择登录按钮1114时，用于访问第二应用的信息被自动填充。

用户不必重新录入凭证信息。当获得访问第一应用的授权时生成的信息被用于访问第二应用。具体而言，SJWT[Sb]被用于获取BJWT[Bb]。

图12图示了根据一些示例实施例的显示用于访问第二应用的完整信息的用户界面。如图12中所示，完成用于访问第二应用的信息。当用户选择图11中的登录按钮1114时，用户不必录入附加信息并且系统自动将用户指引到图12中所示的界面。

虽然描述了针对两个应用的登录，但是令牌SJWT可以被用于针对多个应用认证用户。例如，用户无需录入他们的凭证信息即可登录到三个或四个应用。代替要求凭证信息的重新录入，使用SJWT。

登录到第一应用的方法-服务器数据库

图18图示了根据一些示例实施例的用于使用服务器数据库登录到第一应用的方法的序列图。在图18所示的示例中，公钥不是令牌，并且公钥维护在用于服务器的数据库中。由于公钥存储在数据库中，因此可以在数据库中查找公钥。

图18包括与图2相似的元素，但是，图18包括服务器数据库180(例如，IAM数据库)。服务器数据库可以被配置为存储公钥。

如图18中所示，在步骤1810，用户110可以请求访问第一应用。第一应用也可以被称为应用A或AppA。图18中所示的步骤也可以被称为身份和访问管理系统100的元素之间的调用、系统调用、请求或网络请求。如以上所讨论的，访问管理服务器也可以被称为IAM服务器、OAM服务器或服务器。另外，服务器可以包括用于执行登录的应用。应用可以被称为登录应用、OAM应用、IAM应用或认证应用。登录应用可以是云基础设施登录应用。

在步骤1811处，客户端设备上的浏览器140向第一应用150发送请求(例如，GET请求)，以便获得对第一应用150的访问。具体而言，诸如浏览器应用之类的应用将发送请求。GET请求可以被用于从指定的源请求数据。GET请求使用超文本传输协议(HTTP)来启用客户端和服务器之间的通信。

在步骤1812处，第一应用150向浏览器140返回检查是否存在有效JWT的JavaScript。返回的JavaScript可以包括作为嵌入在由第一应用返回的页面中的脚本运行的代码，生成密钥对，并将密钥对持久保存在IndexedDB中。

在步骤1813处，浏览器140使用来自第一应用150的JavaScript检查是否存在有效的JSON网络令牌(JWT)。JWT是签署的JWT，公钥嵌入在JWT中。JWT是具有来自客户的公钥的文档。JWT是JSON格式的证书。JWT令牌是客户端认证的安全方法。JWT文档由认证服务器签署。认证服务器可以使用用于验证公钥的任何登录机制对JWT文档进行签署。浏览器可以存储会话信息。因此，无需将数据存储在认证服务器上即可创建web会话。

在步骤1814处，如果确定不存在有效JWT，那么浏览器130生成第一密钥对(例如，[Ab，Av])并将生成的第一密钥对存储在浏览器IndexedDB App A 141中。

这由客户端应用通过检查是否存在有效JWT来验证。如果不存在有效JWT，那么JavaScript生成公-私密钥对并将公-私密钥对存储在浏览器IndexedDb中。

具体而言，浏览器上的应用生成第一密钥对。在示例中，Ab表示第一密钥对的公钥并且Av表示私钥。私钥留在客户端的浏览器中，永远不会离开浏览器。例如，私钥可以存储在IndexedDB App A 141中。私钥是不可提取的，只能用于通过浏览器签署。另外，只有用于第一应用(应用A)的域可以访问第一密钥对Ab和Av。

公钥对公众可用并且可以发送给任何人。但是，私钥不能发送到任何地方。公钥可以发送到浏览器之外，诸如发送到将验证密码的服务器或系统。然后，验证密码的服务器可以为会话关联那个密钥。

私钥Av在用于第一应用A的域中并且私钥Bv在用于第二应用B的域中。应用B不能访问私钥Av并且应用A不能访问私钥Bv。即，如果它们在不同的域中，那么一个应用就不能访问另一个应用的私钥。用于应用A的令牌与用于应用B的令牌不同，因为每个应用在不同的域中并且因此具有其它应用无法访问的不同私钥。

因此，没有什么是可以劫持的。例如，当使用cookie时，cookie本身常常随请求一起发送。在示例实施例中，私钥不与请求一起发送。私钥不离开浏览器存储空间。浏览器维护密钥，使其不可提取。它以无法被读取的方式存储。浏览器可以使用私钥对请求进行签署，但是浏览器不会自己发送私钥。

为了清楚和易于理解的目的，在整个描述中，密钥对被称为第一、第二和第三密钥对。第一密钥对被称为[Ab，Av]，因为它与第一应用，应用A对应。第二密钥对被称为[Sb，Sv]，因为它与用于服务器的密钥对对应。第三密钥对被称为[Bb，Bv]，因为它与第二应用，应用B对应。密钥对由浏览器140生成。

不可提取的私钥(例如，Av)存储在浏览器存储空间中并且被用于创建牢不可破的登录会话。私钥本身不会发送到浏览器存储空间之外。此外，存储在客户端侧的私钥是不可提取的。浏览器沙箱提供了用于防止提取私钥的有保障的机制。私钥以无法被读取的方式存储。浏览器使用私钥进行签署，例如数字签名或对访问管理服务器的调用。

这创建了牢不可破的登录会话，其不能被钓鱼或被盗并且不能被用于攻击用户。由于私钥无法从客户端的浏览器中提取出来。因此，可以请求使用私钥的签名，但无法获取或提取私钥本身。可以使用JavaScript中名为Web Crypto API的模块获取用于私钥的签名。

公钥可以存储在访问管理服务器上，或者公钥可以存储在客户端侧。在图18所示的示例中，公钥存储在访问管理服务器的数据库中。当公钥存储在服务器上时，服务器将公钥存储在本地。例如，公钥可以存储在服务器的数据存储库或数据库中。公钥与用于用户的会话相关联。当期望公钥信息时，可以在服务器的数据存储库中识别和查找它。

在步骤1815处，浏览器向服务器160发送包括第一密钥对的第一公钥(例如，Ab)的请求(例如，GET请求)。请求是要授权公钥。JavaScript然后用在步骤1812、1813和1814中生成的公钥[Ab]将用户的浏览器重定向到IAM服务器。

在步骤1816处，服务器返回LoginView和JavaScript。IAM服务器用生成公-私密钥对[Sb和Sv]的JavaScript进行响应。这些密钥将被用于维护与IAM的单点登录会话。IAM服务器可以经由LoginView控件向用户呈现登录屏幕。

在步骤1817处，浏览器140生成并存储用于服务器的第二密钥对(例如，[Sb，Sv])。第二密钥对存储在用户浏览器的浏览器IndexedDB IAM 142中。第二密钥对位于登录应用或服务器应用的域中。第二公钥Sb和第二私钥Sv也可以被称为服务器私钥和服务器公钥。

在步骤1818处，用户经由浏览器140录入他们的凭证。例如，用户为第一应用录入他们的用户名和密码。可以在登录屏幕上录入用户名和密码。表单提交也会提交Sb和Ab。

在步骤1819处，浏览器140向服务器160发送请求以授权用户110登录到第一应用。浏览器140将凭证信息(例如，用户名和密码)连同公钥一起发送到服务器160。可以使用POST方法将信息发送到服务器160。POST可以被用于向服务器发送数据以在服务器中创建和/或更新信息。通过POST发送到服务器的数据存储在HTTP请求的请求正文中。

服务器接收用户名和密码并检查信息是否正确。如果正确，那么认证成功，服务器将公钥存储在表示会话的数据库中。会话信息包括诸如会话的有效期(例如，诸如12小时或一天)之类的会话信息。

在步骤1820处，IAM服务器创建具有标识符“abc”的令牌SJWT并将令牌SJWT存储在表中，密钥是“abc”并且值是Sb。SJWT被发送回浏览器以存储在IndexedDb中以供将来的会话使用。

在步骤1821处，浏览器将存储具有标识符“abc”的令牌SJWT。令牌SJWT存储在表中，密钥是“abc”并且值是Sb。SJWT存储在IndexedDb中以供将来的会话使用。

在步骤1822处，浏览器向IAM发出签署的请求以刷新端点。请求由Sv签署并且授权报头具有SJWT[id＝abc]。

在步骤1823处，IAM服务器从SJWT检索id。在这个示例中，id＝abc。id表示标识符。服务器从数据库中获取用于密钥“abc”的公钥。这被用于匹配API调用的签名。如果签名有效，那么IAM服务器创建带有id＝'xyz'的AJWT并将其存储在IAM数据库中。

在步骤1824处，AJWT被返回给浏览器。在步骤1824处，服务器160向浏览器140发送AJWT[id＝xyz]。此时，AJWT被返回给浏览器，因为用户已成功登录到应用A。

在步骤1825处，用户被指引到具有AJWT[id＝'xyz']的应用A以进行任何签署的调用，并且验证与如何用刷新端点完成签名验证相似地进行。

在步骤1825处，浏览器能够使用用于第一应用的签署的安全令牌来访问第一应用。浏览器使用签署的JWT对应用A进行调用。请求由应用A的私钥签署。浏览器发送与由服务器签署的应用A私钥对应的JWT。由于JWT是由服务器(例如，IAM服务器)的私钥签署的，因此这个JWT可以由服务器验证。因此，第一应用可以询问服务器是否可以信任该JWT。

在图18和19所示的示例中，使用ID的签署的版本。参见例如图18的步骤1820、1821和1822，以及图19的步骤1917、1918和1919。即，使用SJWT。但是，在其它示例实施例中，可以不使用ID的签署的版本。即，不能使用SJWT。代替地，可以直接使用ID(例如，ID-abc)。服务器通过确保签名与服务器数据库(例如，IAM数据库)中存储的公钥匹配来认证用户。

在所描述的示例中，可以使用签名来代替cookie，无论签署的密钥是否在IAM数据库中是持久的，或者签署密钥是否由客户端保存在它对于每个请求重新发送的SJWT/证书中。

登录到第二应用的方法-服务器数据库

在单点登录情况下，用户不需要为他们访问的每个应用录入他们的凭证。用户无需录入凭证即可登录第二应用。

由于第二应用(应用B)和第一应用(应用A)在不同的域中，因此需要对每个应用执行访问应用的授权。即，访问应用B需要授权，并且访问应用A需要分离的授权。

用于应用A的公钥不能用于应用B，因为应用B所需的私钥在应用B的域中，并且初始令牌仅包含应用A的公钥。对应用B进行调用的脚本无法访问存储在应用A的域中的私钥，即使它们位于客户端侧。

过去，如果要与第二应用建立会话，那么用户直接与第二应用建立会话。在示例实施例中，单点登录被用于允许用户访问第二应用，而无需用户对第二应用执行第二授权。

由于应用A和应用B位于不同的域中，因此访问每个应用将需要不同的公钥。用于应用A的会话的公钥和用于应用B的会话的另一个公钥。但是，由于示例实施例允许单点登录，因此无需再次向用户询问凭证即可获得第二公钥。用户不需要重新录入他们的凭证信息。

为了登录到第二应用，浏览器140将使用在图18的步骤1817中生成的第二私钥(Sv)。浏览器将对与访问第二应用155的请求相关联的材料进行签署。例如，请求可以包括当前时间戳或用户名。使用私钥创建非对称数字签名。服务器私钥是不可提取的，并且是在访问第一应用时与初始认证请求一起创建的。浏览器使用来自位于浏览器中的存储空间中的私钥以便签署请求。即，私钥是不可提取的，但可以被浏览器的API用来签署请求。

如果已经与服务器建立了会话，那么浏览器将使用它已经存储的服务器私钥来认证与第二应用的会话。浏览器可以发送请求连同用于第二应用的公钥，并且登录应用将签署该请求，从而授权对第二应用的访问。浏览器可以将签署的信息发送到第二应用，并且第二应用将认证会话并允许访问第二应用。

图19图示了根据一些示例实施例的用于使用服务器数据库登录到第二应用的方法1900的序列图。在图19所示的示例中，公钥不是令牌，而是维护在服务器上。

图19与图4相似，但是，图19包括服务器数据库180(例如，IAM数据库)。服务器数据库可以被配置为存储公钥。

图19中所示的步骤发生在图18中的步骤被执行并且用户已成功登录到第一应用(应用A)之后。在用户已经登录到第一应用之后执行将用户登录到第二应用的示例实施例。

在步骤1910处，用户110想要访问第二应用155(例如，App B)。此时，用户已经登录到第一应用(AppA)，并且创建了用于第一会话的私钥并将其存储在用于浏览器140的存储空间中。例如，私钥可以存储在存储空间IndexedDB IAM 142中。即，图18中所示的序列已在执行图19中所示的序列之前执行，并且用户已登录到第一应用。用户现在想要访问与第一应用(例如，App A)不同的第二应用(例如，App B)。

在步骤1911处，浏览器140向第二应用155发送请求。请求是访问第二应用155。请求可以是例如GET请求。

在步骤1912处，第二应用(应用B)将JavaScript发送回浏览器。第二应用155可以返回将用于检查有效JWT是否存在的JavaScript。

在示例实施例中，JavaScript代码可以被用于认证。因此，代替像现有技术中所公开的那样仅发送cookie，密钥被用于对及时数据进行签署。例如，及时数据可以包括例如时间戳和表示用户的姓名。数据以加密方式签署，使得可以使用公钥验证生成的签名，作为只有拥有浏览器认证的私钥的人才能做出那个签名的证明。浏览器将获取签名并将其连同来自服务器的对数据的请求一起发送。签名可以位于HTTP报头中以确保安全传输。

在步骤1913处，JavaScript被用于检查是否存在有效JWT。应用向浏览器返回检查是否存在有效会话的JavaScript。会话通过客户端应用检查是否存在有效JWT来验证。如果不存在有效JWT，那么JavaScript生成公-私密钥对并将其存储在浏览器IndexedDb中。

用于第二应用155的JavaScript代码将识别是否存在已生成的密钥对，以及它是否在本地存储空间中可用。JWT将具有示出它是否对会话有效的时间戳。在步骤1913处，浏览器140使用浏览器140从第二应用155接收的JavaScript来检查是否存在有效JWT。

在步骤1914处，如果在步骤1913处确定不存在用于第二应用(应用B)的有效JWT，那么浏览器将生成第三公-私密钥对(Bb和Bv)。在第三密钥对中，Bb是公钥并且Bv是私钥。私钥Bv不被发送到第二应用155或服务器160。代替地，私钥保持本地存储在浏览器140处，诸如浏览器IndexedDB App B 144中。私钥Bv被用于签署请求。

在步骤1915处，公钥Bb被发送到服务器应用。浏览器140向认证服务器160发送请求，该请求包括用于授权访问第二应用155的公钥。请求可以是GET请求。发送到第二应用155的请求包括在步骤1914处由浏览器生成的公钥(Bb)。JavaScript然后用在步骤1912、1913和1914中生成的公钥[Bb]将用户的浏览器重定向到IAM服务器。

在步骤1916处，服务器应用将发送回另一个JavaScript以检查是否存在有效JWT。

在步骤1917处，使用JavaScript来确定是否存在有效的服务器令牌(SJWT)。确定是否存在有效的认证服务器JWT(SJWT)IAM服务器返回检查是否存在SJWT的JavaScript。

在步骤1918处，如果确定存在有效的服务器令牌SJWT，那么浏览器可以确定它们在登录应用的域中。如果存在有效的认证服务器JWT，那么在步骤1918处获得JWT并用在图18的步骤1817中生成的第二私钥(Sv)签署。如果存在SJWT，那么可以使用它对IAM进行签署的调用以获取BJWT。

在步骤1919处，由于确定存在有效SJWT，因此浏览器使用刷新端点向IAM发送签署的请求。请求由Sv签署，并且授权报头具有SJWT[id＝abc]。

在步骤1920处，IAM服务器从SJWT检索id，并从数据库中获取密钥“abc”的公钥。这被用于匹配API调用的签名。如果签名有效，那么IAM创建id＝'pqr'的BJWT，并将用于密钥“pqr”的Bb存储在IAM数据库中。

在步骤1921处，BJWT被返回到浏览器并且用户被指引到具有BJWT[id＝'pqr']的应用B以进行任何签署的调用。验证与如何用刷新端点完成签名验证相似地进行。

如示例实施例中所公开的，使用存储在数据库中的公钥来验证存储在服务器数据库中并与登录会话相关联的公钥和包括私钥的数字签名。服务器将检查例如已签署的材料的时间戳信息以确保该材料是最近签署的。在成功验证那个数字签名后，调用通过认证。

在登录到第一应用和登录到第二应用的两个示例实施例中，第一密钥对的私钥都仅存储在浏览器侧。

为每个应用获得分离的公钥，因为用于应用B的私钥在应用B的域中，而用于应用A的私钥在应用A的域中。对应用B进行调用的脚本无法访问应用A的私钥。对应用A进行调用的脚本无法访问应用B的私钥。因此，每个应用具有其自己的公钥以便获得私有令牌。

计算机系统

图13、14和15图示了在各种实施例中使用的示例性硬件和/或软件配置。

图13图示了用于实现一些示例实施例的分布式系统的简化图。在所示实施例中，分布式系统1300包括一个或多个客户端计算设备1302、1304、1306和1308，它们被配置为通过一个或多个网络1310执行和操作客户端应用，诸如web浏览器、专有客户端(例如，OracleForms)等。服务器1312可以经由网络1310与远程客户端计算设备1302、1304、1306和1308通信耦合。

在各种实施例中，服务器1312可以适用于运行一个或多个服务或软件应用，诸如提供代码和/或数据用于为在服务器1312或另一个服务器处执行的应用执行高效应用配置修补的服务和应用。在某些实施例中，服务器1312还可以提供可以包括非虚拟和虚拟环境的其它服务或软件应用。在一些实施例中，这些服务可以作为基于web的或云服务或在软件即服务(SaaS)模型下提供给客户端计算设备1302、1304、1306和/或1308的用户。操作客户端计算设备1302、1304、1306和/或1308的用户进而可以利用一个或多个客户端应用与服务器1312交互以利用由这些组件提供的服务。

在图13所描绘的配置中，系统1300的软件组件1318、1320和1322被示为在服务器1312上实现。作为一个示例，组件中的一个或多个(例如，软件组件1318)可以是贯穿本申请讨论的配置补丁模块或二进制补丁模块。

在其它实施例中，系统1300的一个或多个组件和/或由这些组件提供的服务可以也可以由客户端计算设备1302、1304、1306和/或1308中的一个或多个来实现。然后，操作客户端计算设备的用户可以利用一个或多个客户端应用来使用由这些组件提供的服务。这些组件可以用硬件、固件、软件或其组合来实现。应该理解的是，各种不同的系统配置是可能的，其可以与分布式系统1300不同。因此，图13中所示的实施例是用于实现实施例系统的分布式系统的一个示例，而不是限制性的。

客户端计算设备1302、1304、1306和/或1308可以包括各种类型的计算系统。例如，客户端计算设备可以包括便携式手持设备(例如，蜂窝电话、、计算平板、个人数字助理(PDA))或可穿戴设备(例如，Google头戴式显示器)，其运行诸如Microsoft Windows 之类的软件和/或诸如iOS、Windows Phone、Android、BlackBerry，Palm OS之类的各种移动操作系统。设备可以支持各种应用(诸如各种互联网相关的应用、电子邮件、短消息服务(SMS)应用)，并且可以使用各种其它通信协议。客户端计算设备还可以包括通用个人计算机，作为示例，运行各种版本的Microsoft、Apple 和/或Linux操作系统的个人计算机和/或膝上型计算机。客户端计算设备可以是运行任何各种商用的或类UNIX操作系统(包括但不限于诸如像Google Chrome OS的各种GNU/Linux操作系统)的工作站计算机。客户端计算设备还可以包括能够提供(一个或多个)网络1310通信的电子设备(诸如瘦客户端计算机、启用互联网的游戏系统(例如，具有或不具有手势输入设备的Microsoft游戏控制台)和/或个人消息传送设备)。

虽然图13中的分布式系统1300被示出具有四个客户端计算设备，但是可以支持任何数量的客户端计算设备。其它设备(例如具有传感器的设备等)可以与服务器1312交互。

分布式系统1300中的(一个或多个)通信网络1310可以是可以支持使用多种可用协议中的任一种进行数据通信的任何类型的网络，其中各种协议包括但不限于TCP/IP(传输控制协议/互联网协议)、SNA(系统网络体系架构)、IPX(互联网分组交换)、AppleTalk等。仅仅作为示例，(一个或多个)网络1310可以是局域网(LAN)、基于以太网的网络、令牌环、广域网(WAN)、互联网、虚拟网络、虚拟专用网络(VPN)、内联网、外联网、公共交换电话网络(PSTN)、红外(IR)网络、无线网络(例如，在任何电气和电子协会(IEEE)802.11协议套件、和/或任何其它无线协议下操作的网络)和/或这些和/或其它网络的任意组合。

服务器1312可以由一个或多个通用计算机、专用服务器计算机(作为示例，包括PC(个人计算机)服务器、服务器、中档服务器、大型计算机、机架安装的服务器等)、服务器场、服务器集群或任何其它适当的布置和/或组合组成。服务器1312可以包括运行虚拟操作系统的一个或多个虚拟机，或涉及虚拟化的其它计算体系架构。一个或多个灵活的逻辑存储设备池可以被虚拟化，以维护用于服务器的虚拟存储设备。虚拟网络可以由服务器1312利用软件定义的联网来控制。在各种实施例中，服务器1312可以适于运行在前述公开内容中描述的一个或多个服务或软件应用。

服务器1312可以运行包括以上讨论的任何操作系统的操作系统，以及任何商用的服务器操作系统。服务器1312还可以运行任何各种附加的服务器应用和/或中间层应用，包括HTTP(超文本传输协议)服务器、FTP(文件传输协议)服务器、CGI(公共网关接口)服务器、服务器、数据库服务器等。示例性数据库服务器包括但不限于可从Oracle、Microsoft、Sybase、IBM(国际商业机器)等商业获得的数据库服务器。

分布式系统1300还可以包括一个或多个数据库1314和1316。这些数据库可以提供用于存储诸如用户交互信息、使用模式信息、适配规则信息和由示例实施例使用的其它信息之类的信息的机制。数据库1314和1316可以驻留在各种位置。举例来说，数据库1314和1316中的一个或多个可以驻留在服务器1312本地(和/或驻留在其中)的非暂态存储介质上。可替代地，数据库1314和1316可以远离服务器1312并且经由基于网络的或专用连接与服务器1312通信。在一组实施例中，数据库1314和1316可以驻留在存储区域网络(SAN)中。类似地，用于执行归属于服务器1312的功能的任何必要文件都可以适当地本地存储在服务器1312上和/或远程存储。在一组实施例中，数据库1314和1316可以包括关系数据库，诸如由Oracle提供的数据库，其适于响应于SQL格式的命令而存储、更新和检索数据。但是，数据库1314和1316可以提供关系数据库、面向对象的数据库、对象-关系数据库、NoSQL数据库等，并且可以是也可以不是基于SQL的。例如，数据库1314和/或1316可以是Oracle数据库、PostgreSQL、Microsoft SQL Server、MySQL、MemSQL、Memcached、Redis、MongoDB、BigTable、Cassandra、DB2、Solr等。

在一些实施例中，用于执行高效应用配置修补的代码和/或数据可以作为服务经由云环境提供。图14是根据本公开的一些实施例的系统环境1400的一个或多个组件的简化框图，其中服务可以作为云服务提供。在图14所示的实施例中，系统环境1400包括一个或多个客户端计算设备1404、1406和1408，用户可以使用它们与提供云服务的云基础设施系统1402交互。此外，在一些实施例中，“客户端”计算设备1404、1406、1408实际上可以是在客户端-服务器关系中充当客户端的服务器计算机，其中服务器可以提供应用配置修补服务。云基础设施系统1402可以包括一个或多个计算机和/或服务器，这些计算机和/或服务器可以包括上面针对服务器1312描述的那些。

应当认识到的是，图14中描绘的云基础设施系统1402可以具有不同于所描绘的组件的其它组件。另外，图14中所示的实施例是可以结合示例实施例的云基础设施系统的一个示例。在一些其它实施例中，云基础设施系统1402可以具有比图中所示更多或更少的组件，可以组合两个或更多个组件，或者可以具有不同的组件配置或布置。

客户端计算设备1404、1406和1408可以是与上面针对1302、1304、1306和1308描述的那些设备相似的设备。客户端计算设备1404、1406和1408可以被配置为操作客户端应用，诸如web浏览器、专有客户端应用(例如，Oracle Forms)或某个其它应用，它们可以由客户端计算设备的用户用来与云基础设施系统1402交互以使用由云基础设施系统1402提供的服务。虽然示例性系统环境1400被示为具有三个客户端计算设备，但是可以支持任意数量的客户端计算设备。其它设备(诸如具有传感器的设备等)可以与云基础设施系统1402交互。

(一个或多个)通信网络1310可以促进客户端1404、1406和1408与云基础设施系统1402之间的通信和数据交换。每个网络都可以是任何类型的网络，该网络可以使用多种商用协议中的任何一种支持数据通信，包括上文针对(一个或多个)通信网络1310所描述的那些。

在某些实施例中，由云基础设施系统1402提供的服务可以包括按需使云基础设施系统的用户可用的大量服务。除了与提供代码和/或数据以执行高效应用配置修补操作相关的服务外，还可以提供各种其它服务，包括但不限于在线数据存储和备份解决方案、基于Web的电子邮件服务、托管的办公室套件和文档协作服务、数据库处理、受管理的技术支持服务等。由云基础设施系统提供的服务可以动态扩展以满足其用户的需求。

在某些实施例中，由云基础设施系统1402提供的服务的具体实例化在本文中可以被称为“服务实例”。一般而言，从云服务提供商的系统经由通信网络(诸如互联网)使用户可用的任何服务都被称为“云服务”。通常，在公共云环境中，构成云服务提供商系统的服务器和系统不同于客户自己的本地服务器和系统。例如，云服务提供商的系统可以托管应用，并且用户可以通过诸如互联网之类的通信网络按需订购和使用该应用。

在一些示例中，计算机网络云基础设施中的服务可以包括对存储装置、托管的数据库、托管的web服务器、软件应用或者由云供应商向用户提供的其它服务的受保护的计算机网络访问，或者如本领域中另外已知的。例如，服务可以包括通过互联网对云上的远程存储的受密码保护的访问。作为另一个示例，服务可以包括基于web服务的托管的关系数据库和脚本语言中间件引擎，用于由联网的开发人员私人使用。作为另一个示例，服务可以包括对在云供应商的网站上托管的电子邮件软件应用的访问。

在某些实施例中，云基础设施系统1402可以包括以自助服务、基于订阅、弹性可扩展、可靠、高度可用和安全的方式交付给消费者的应用套件、中间件和数据库服务产品。这种云基础设施系统的示例是由本受让人提供的Oracle Public Cloud(Oracle公共云)。

云基础设施系统1402还可以提供与“大数据”相关的计算和分析服务。术语“大数据”一般用来指可由分析员和研究者存储和操纵以可视化大量数据、检测趋势和/或以其它方式与数据交互的极大数据集。这种大数据和相关应用可以在许多级别和不同规模上由基础设施系统托管和/或操纵。并行链接的数十个、数百个或数千个处理器可以作用于这种数据，以便呈现其或者模拟对数据或其所表示的内容的外力。这些数据集可以涉及结构化数据，诸如在数据库中组织或以其它方式根据结构化模型组织的数据，和/或者非结构化数据(例如，电子邮件、图像、数据blob(二进制大对象)、网页、复杂事件处理)。通过利用实施例相对快速地将更多(或更少)的计算资源聚焦在目标上的能力，云基础设施系统可以更好地用于基于来自企业、政府机构、研究组织、私人个人、一群志同道合的个人或组织或其它实体的需求在大数据集上执行任务。

在各种实施例中，云基础设施系统1402可以适于自动地供应、管理和跟踪消费者对由云基础设施系统1402提供的服务的订阅。云基础设施系统1402可以经由不同的部署模型提供云服务。例如，服务可以在公共云模型下提供，其中云基础设施系统1402由销售云服务的组织拥有(例如，由Oracle公司拥有)并且使服务对一般公众或不同的工业企业可用。作为另一个示例，服务可以在私有云模型下提供，其中云基础设施系统1402仅针对单个组织操作，并且可以为组织内的一个或多个实体提供服务。云服务还可以在社区云模型下提供，其中云基础设施系统1402和由云基础设施系统1402提供的服务由相关社区中的若干个组织共享。云服务还可以在混合云模型下提供，混合云模型是两个或更多个不同模型的组合。

在一些实施例中，由云基础设施系统1402提供的服务可以包括在软件即服务(SaaS)类别、平台即服务(PaaS)类别、基础设施即服务(IaaS)类别、或包括混合服务的服务的其它类别下提供的一个或多个服务。消费者经由订阅订单可以订购由云基础设施系统1402提供的一个或多个服务。云基础设施系统1402然后执行处理，以提供消费者的订阅订单中的服务。

在一些实施例中，由云基础设施系统1402提供的服务可以包括但不限于应用服务、平台服务和基础设施服务。在一些示例中，应用服务可以由云基础设施系统经由SaaS平台提供。SaaS平台可以被配置为提供属于SaaS类别的云服务。例如，SaaS平台可以提供在集成的开发和部署平台上构建和交付点播应用套件的能力。SaaS平台可以管理和控制用于提供SaaS服务的底层软件和基础设施。通过利用由SaaS平台提供的服务，消费者可以利用在云基础设施系统上执行的应用。消费者可以获取应用服务，而无需消费者单独购买许可证和支持。可以提供各种不同的SaaS服务。示例包括但不限于为大型组织提供用于销售绩效管理、企业集成和业务灵活性的解决方案的服务。

在一些实施例中，平台服务可以由云基础设施系统1402经由PaaS平台提供。PaaS平台可以被配置为提供属于PaaS类别的云服务。平台服务的示例可以包括但不限于使组织(诸如Oracle)能够在共享的共同体系架构上整合现有应用的服务，以及利用由平台提供的共享服务构建新应用的能力。PaaS平台可以管理和控制用于提供PaaS服务的底层软件和基础设施。消费者可以获取由云基础设施系统1402提供的PaaS服务，而无需消费者购买单独的许可证和支持。平台服务的示例包括但不限于Oracle Java云服务(JCS)、Oracle数据库云服务(DBCS)以及其它。

通过利用由PaaS平台提供的服务，消费者可以采用由云基础设施系统支持的编程语言和工具，并且还控制所部署的服务。在一些实施例中，由云基础设施系统提供的平台服务可以包括数据库云服务、中间件云服务(例如，OracleFusion Middleware服务)和Java云服务。在一个实施例中，数据库云服务可以支持共享服务部署模型，其使得组织能够汇集数据库资源并且以数据库云的形式向消费者提供数据库即服务(DaaS)。中间件云服务可以为消费者提供开发和部署各种业务应用的平台，以及Java云服务可以在云基础设施系统中为消费者提供部署Java应用的平台。

可以由云基础设施系统中的IaaS平台提供各种不同的基础设施服务。基础设施服务促进底层计算资源(诸如存储装置、网络和其它基本计算资源)的管理和控制，以便消费者利用由SaaS平台和PaaS平台提供的服务。

在某些实施例中，云基础设施系统1402还可以包括基础设施资源1430，用于提供用来向云基础设施系统的消费者提供各种服务的资源。在一个实施例中，基础设施资源1430可以包括执行由PaaS平台和SaaS平台提供的服务的硬件(诸如服务器、存储装置和联网资源)的预先集成和优化的组合，以及其它资源。

在一些实施例中，云基础设施系统1402中的资源可以由多个用户共享并且按需动态地重新分配。此外，资源可以分配给在不同时区中的用户。例如，云基础设施系统1402可以使第一时区内的第一用户集合能够利用云基础设施系统的资源指定的小时数，然后使得能够将相同资源重新分配给位于不同时区中的另一用户集合，从而最大化资源的利用率。

在某些实施例中，可以提供由云基础设施系统1402的不同组件或模块共享，以使得能够由云基础设施系统1402供应服务的多个内部共享服务1432。这些内部共享服务可以包括，但不限于，安全和身份服务、集成服务、企业储存库服务、企业管理器服务、病毒扫描和白名单服务、高可用性、备份和恢复服务、用于启用云支持的服务、电子邮件服务、通知服务、文件传输服务等。

在某些实施例中，云基础设施系统1402可以在云基础设施系统中提供云服务(例如，SaaS、PaaS和IaaS服务)的综合管理。在一个实施例中，云管理功能可以包括用于供应、管理和跟踪由云基础设施系统1402等接收到的消费者的订阅的能力。

在一个实施例中，如图14中所绘出的，云管理功能可以由诸如订单管理模块1420、订单编排模块1422、订单供应模块1424、订单管理和监控模块1426以及身份管理模块1428的一个或多个模块提供。这些模块可以包括或可以利用一个或多个计算机和/或服务器提供，该一个或多个计算机和/或服务器可以是通用计算机、专用服务器计算机、服务器场，服务器集群或任何其它适当的布置和/或组合。

在示例性操作中，在1434处，使用诸如客户端设备1404、1406或1408之类的客户端设备的客户可以通过请求由云基础设施系统1402提供的一个或多个服务并且对由云基础设施系统1402提供的一个或多个服务的订阅下订单来与云基础设施系统1402交互。在某些实施例中，消费者可以访问诸如云UI 1412、云UI 1414和/或云UI1416的云用户界面(UI)并经由这些UI下订阅订单。响应于消费者下订单而由云基础设施系统1402接收到的订单信息可以包括识别消费者和消费者打算订阅的由云基础设施系统1402提供的一个或多个服务的信息。

在1436处，从消费者接收到的订单信息可以存储在订单数据库1418中。如果这是新的订单，则可以为该订单创建新的记录。在一个实施例中，订单数据库1418可以是由云基础设施系统1418操作以及与其它系统元素结合操作的若干数据库当中的一个。

在1438处，订单信息可以被转发到订单管理模块1420，订单管理模块1420可以被配置为执行与订单相关的计费和记帐功能，诸如验证订单，并且在通过验证时，预订订单。

在1440处，关于订单的信息可以被传送到订单编排模块1422，订单编排模块1422被配置为编排用于由消费者下的订单的服务和资源的供应。在一些情况下，订单编排模块1422可以使用订单供应模块1424的服务用于供应。在某些实施例中，订单编排模块1422使得能够管理与每个订单相关联的业务过程，并且应用业务逻辑来确定订单是否应当继续供应。

如图14中绘出的实施例所示，在步骤1442处，在接收到新订阅的订单时，订单编排模块1422向订单供应模块1424发送分配资源和配置履行订购订单所需的资源的请求。订单供应模块1424使得能够为由消费者订购的服务分配资源。订单供应模块1424提供由云基础设施系统1400提供的云服务和用来供应用于提供所请求的服务的资源的物理实现层之间的抽象级别。这使得订单编排模块1422能够与实现细节隔离，诸如服务和资源是否实际上实时供应，或者预先供应并且在请求时进行分配/指派。

在1444处，一旦供应了服务和资源，就可以向订阅的消费者发送指示所请求的服务现在已准备好用于使用的通知。在一些情况下，可以向消费者发送使得消费者能够开始使用所请求的服务的信息(例如，链接)。

在1446处，可以由订单管理和监控模块1426来管理和跟踪消费者的订阅订单。在一些情况下，订单管理和监控模块1426可以被配置为收集关于消费者使用所订阅的服务的使用统计。例如，可以针对所使用的存储量、所传送的数据量、用户的数量以及系统启动时间和系统停机时间的量等来收集统计数据。

在某些实施例中，云基础设施系统1400可以包括身份管理模块1428，其被配置为提供身份服务，诸如云基础设施系统1400中的访问管理和授权服务。在一些实施例中，身份管理模块1428可以控制关于希望利用由云基础设施系统1402提供的服务的消费者的信息。这种信息可以包括认证这些消费者的身份的信息和描述那些消费者被授权相对于各种系统资源(例如，文件、目录、应用、通信端口、存储器段等)执行的动作的信息。身份管理模块1428还可以包括关于每个消费者的描述性信息以及关于如何和由谁来访问和修改描述性信息的管理。

图15图示了示例性计算机系统1500，其可以被用于实现根据一些示例实施例的某些组件。在一些实施例中，计算机系统1500可以用于实现上述各种服务器和计算机系统中的任何一种。如图15所示，计算机系统1500包括各种子系统，包括经由总线子系统1502与多个外围子系统通信的处理单元1504。这些外围子系统可以包括处理加速单元1506、I/O子系统1508、存储子系统1518和通信子系统1524。存储子系统1518可以包括有形计算机可读存储介质1522和系统存储器1510。

总线子系统1502提供用于使计算机系统1500的各种组件和子系统按照期望彼此通信的机制。虽然总线子系统1502被示意性地示为单条总线，但是总线子系统的可替代实施例可以利用多条总线。总线子系统1502可以是若干种类型的总线结构中的任何一种，包括存储器总线或存储器控制器、外围总线和利用任何各种总线体系架构的局部总线。例如，此类体系架构可以包括工业标准体系架构(ISA)总线、微通道体系架构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线和外围组件互连(PCI)总线，其可以实现为根据IEEE P1386.1标准制造的夹层(Mezzanine)总线，等等。

处理子系统1504控制计算机系统1500的操作并且可以包括一个或多个处理单元1532、1534等。处理单元可以包括一个或多个处理器，其中包括单核或多核处理器、处理器的一个或多个核、或其组合。在一些实施例中，处理子系统1504可以包括一个或多个专用协处理器，诸如图形处理器(GPU)、数字信号处理器(DSP)等。在一些实施例中，处理子系统1504的处理单元中的一些或全部可以利用定制电路来实现，诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA)。

在一些实施例中，处理子系统1504中的处理单元可以执行存储在系统存储器1510中或计算机可读存储介质1522上的指令。在各种实施例中，处理单元可以执行各种程序或代码指令，并且可以维护多个并发执行的程序或进程。在任何给定的时间，要执行的程序代码中的一些或全部可以驻留在系统存储器1510中和/或计算机可读存储介质1522上，潜在地包括在一个或多个存储设备上。通过合适的编程，处理子系统1504可以提供上述用于执行高效应用配置修补操作的各种功能。

在某些实施例中，可以提供处理加速单元1506，用于执行定制的处理或用于卸载由处理子系统1504执行的一些处理，以便加速由计算机系统1500执行的整体处理。

I/O子系统1508可以包括用于向计算机系统1500输入信息和/或用于从或经由计算机系统1500输出信息的设备和机制。一般而言，术语“输入设备”的使用旨在包括用于向计算机系统1500输入信息的所有可能类型的设备和机制。用户接口输入设备可以包括，例如，键盘、诸如鼠标或轨迹球的指示设备、结合到显示器中的触摸板或触摸屏、滚轮、点拨轮、拨盘、按钮、开关、键板、具有语音命令识别系统的音频输入设备、麦克风以及其它类型的输入设备。用户接口输入设备也可以包括使用户能够控制输入设备并与其交互的诸如Microsoft 运动传感器的运动感测和/或姿势识别设备、Microsoft 360游戏控制器、提供用于接收利用姿势和口语命令的输入的接口的设备。用户接口输入设备也可以包括眼睛姿势识别设备，诸如从用户检测眼睛活动(例如，当拍摄图片和/或进行菜单选择时的“眨眼”)并将眼睛姿势转换为到输入设备(例如，Google)中的输入的Google 眨眼检测器。此外，用户接口输入设备可以包括使用户能够通过语音命令与语音识别系统(例如，导航器)交互的语音识别感测设备。

用户接口输入设备的其它示例包括但不限于三维(3D)鼠标、操纵杆或指示杆、游戏板和图形平板、以及音频/视频设备，诸如扬声器、数字相机、数字摄像机、便携式媒体播放器、网络摄像机、图像扫描仪、指纹扫描仪、条形码读取器3D扫描仪、3D打印机、激光测距仪、以及眼睛注视跟踪设备。此外，用户接口输入设备可以包括，例如，医疗成像输入设备，诸如计算机断层摄影、磁共振成像、位置发射断层摄影、医疗超声检查设备。用户接口输入设备也可以包括，例如，音频输入设备，诸如MIDI键盘、数字乐器等。

用户接口输出设备可以包括显示子系统、指示器灯或诸如音频输出设备的非可视显示器等。显示子系统可以是阴极射线管(CRT)、诸如利用液晶显示器(LCD)或等离子体显示器的平板设备、投影设备、触摸屏等。一般而言，术语“输出设备”的使用旨在包括用于从计算机系统1500向用户或其它计算机输出信息的所有可能类型的设备和机制。例如，用户接口输出设备可以包括但不限于，可视地传达文本、图形和音频/视频信息的各种显示设备，诸如监控器、打印机、扬声器、耳机、汽车导航系统、绘图仪、语音输出设备和调制解调器。

存储子系统1518提供用于存储由计算机系统1500使用的信息的储存库或数据存储。存储子系统1518提供有形非瞬态计算机可读存储介质，用于存储提供一些实施例的功能的基本编程和数据结构。当由处理子系统1504执行时提供上述功能的软件(程序、代码模块、指令)可以存储在存储子系统1518中。软件可以由处理子系统1504的一个或多个处理单元执行。存储子系统1518也可以提供用于存储根据示例实施例使用的数据的储存库。

存储子系统1518可以包括一个或多个非瞬态存储器设备，包括易失性和非易失性存储器设备。如图15所示，存储子系统1518包括系统存储器1510和计算机可读存储介质1522。系统存储器1510可以包括多个存储器，包括用于在程序执行期间存储指令和数据的易失性主随机存取存储器(RAM)和其中存储固定指令的非易失性只读存储器(ROM)或闪存存储器。在一些实现中，包含帮助在诸如启动期间在计算机系统1500内的元件之间传送信息的基本例程的基本输入/输出系统(BIOS)通常可以存储在ROM中。RAM通常包含当前由处理子系统1504操作和执行的数据和/或程序模块。在一些实现中，系统存储器1510可以包括多个不同类型的存储器，诸如静态随机存取存储器(SRAM)或动态随机存取存储器(DRAM)。

作为示例而非限制，如在图15中所绘出的，系统存储器1510可以存储应用程序1512，其可以包括客户端应用、Web浏览器、中间层应用、关系数据库管理系统(RDBMS)等、程序数据1514和操作系统1516。作为示例，操作系统1516可以包括各种版本的MicrosoftApple和/或Linux操作系统、各种商用或类UNIX操作系统(包括但不限于各种GNU/Linux操作系统、GoogleOS等)和/或诸如iOS、Phone、OS、10OS和OS操作系统的移动操作系统。

计算机可读存储介质1522可以存储提供一些实施例的功能的编程和数据结构。当由处理子系统1504执行时使处理器提供上述功能的软件(程序、代码模块、指令)可以存储在存储子系统1518中。作为示例，计算机可读存储介质1522可以包括非易失性存储器，诸如硬盘驱动器、磁盘驱动器、诸如CD ROM、DVD、Blu-(蓝光)盘或其它光学介质的光盘驱动器。计算机可读存储介质1522可以包括但不限于，驱动器、闪存存储器卡、通用串行总线(USB)闪存驱动器、安全数字(SD)卡、DVD盘、数字视频带等。计算机可读存储介质1522也可以包括基于非易失性存储器的固态驱动器(SSD)(诸如基于闪存存储器的SSD、企业闪存驱动器、固态ROM等)、基于易失性存储器的SSD(诸如基于固态RAM、动态RAM、静态RAM、DRAM的SSD、磁阻RAM(MRAM)SSD)，以及使用基于DRAM和基于闪存存储器的SSD的组合的混合SSD。计算机可读介质1522可以为计算机系统1500提供计算机可读指令、数据结构、程序模块和其它数据的存储。

在某些实施例中，存储子系统1500也可以包括计算机可读存储介质读取器1520，其可以进一步连接到计算机可读存储介质1522。可选地，与系统存储器1510一起和组合，计算机可读存储介质1522可以全面地表示远程、本地、固定和/或可移动存储设备加上用于存储计算机可读信息的存储介质。

在某些实施例中，计算机系统1500可以提供对执行一个或多个虚拟机的支持。计算机系统1500可以执行诸如管理程序之类的程序，以便促进虚拟机的配置和管理。每个虚拟机可以被分配存储器、计算(例如，处理器、内核)、I/O和联网资源。每个虚拟机通常运行其自己的操作系统，其可以与由计算机系统1500执行的其它虚拟机执行的操作系统相同或不同。相应地，多个操作系统可以潜在地由计算机系统1500并发地运行。每个虚拟机一般独立于其它虚拟机运行。

通信子系统1524提供到其它计算机系统和网络的接口。通信子系统1524用作用于从计算机系统1500的其它系统接收数据和向其发送数据的接口。例如，通信子系统1524可以使计算机系统1500能够经由互联网建立到一个或多个客户端设备的通信信道，用于从客户端设备接收信息和发送信息到客户端设备。

通信子系统1524可以支持有线和/或无线通信协议两者。例如，在某些实施例中，通信子系统1524可以包括用于(例如，使用蜂窝电话技术、高级数据网络技术(诸如3G、4G或EDGE(全球演进的增强数据速率)、WiFi(IEEE802.11族标准)、或其它移动通信技术、或其任意组合)接入无线语音和/或数据网络的射频(RF)收发器组件、全球定位系统(GPS)接收器组件和/或其它组件。在一些实施例中，作为无线接口的附加或替代，通信子系统1524可以提供有线网络连接(例如，以太网)。

通信子系统1524可以以各种形式接收和发送数据。例如，在一些实施例中，通信子系统1524可以以结构化和/或非结构化的数据馈送1526、事件流1528、事件更新1530等形式接收输入通信。例如，通信子系统1524可以被配置为实时地从社交媒体网络的用户和/或诸如馈送、更新、诸如丰富站点摘要(RSS)馈送的web馈送的其它通信服务接收(或发送)数据馈送1526，和/或来自一个或多个第三方信息源的实时更新。

在某些实施例中，通信子系统1524可以被配置为以连续数据流的形式接收本质上可能是连续的或无界的没有明确结束的数据，其中连续数据流可以包括实时事件的事件流1528和/或事件更新1530。生成连续数据的应用的示例可以包括例如传感器数据应用、金融报价机、网络性能测量工具(例如网络监控和流量管理应用)、点击流分析工具、汽车流量监控等。

通信子系统1524也可以被配置为向一个或多个数据库输出结构化和/或非结构化的数据馈送1526、事件流1528、事件更新1530等，其中所述一个或多个数据库可以与耦合到计算机系统1500的一个或多个流数据源计算机通信。

计算机系统1500可以是各种类型中的一种，包括手持便携式设备(例如，蜂窝电话、计算平板、PDA)、可穿戴设备(例如，Google头戴式显示器)、个人计算机、工作站、大型机、信息站、服务器机架或任何其它数据处理系统。

由于计算机和网络的不断变化的性质，图15中描绘的计算机系统1500的描述仅旨在作为具体示例。比图15中描绘的系统具有更多或更少组件的许多其它配置是可能的。可以有其它方式和/或方法来实现各种实施例。

虽然已经描述了具体的示例实施例，但是各种修改、变更、替代构造和等效物也涵盖在示例实施例的范围内。示例实施例不限于在某些具体数据处理环境内操作，而是可以在多个数据处理环境内自由操作。此外，虽然已经使用特定系列的事务和步骤描述了实施例，但是示例实施例不限于所描述的一系列事务和步骤。上述实施例的各种特征和方面可以单独或联合使用。

另外，虽然已经使用硬件和软件的特定组合描述了实施例，但是应当认识到的是，硬件和软件的其它组合也在示例实施例的范围内。实施例可以只用硬件、或只用软件、或利用其组合来实现。本文描述的各种进程可以在同一处理器或以任何组合的不同处理器上实现。因而，在组件或模块被描述为被配置为执行某些操作的情况下，这种配置可以例如通过设计电子电路来执行操作、通过对可编程电子电路(诸如微处理器)进行编程来执行操作、或其任意组合来实现。进程可以利用各种技术来通信，包括但不限于用于进程间通信(IPC)的常规技术，并且不同的进程对可以使用不同的技术，或者同一对进程可以在不同时间使用不同的技术。

因而，说明书和附图应当在说明性而不是限制性的意义上考虑。但是，将显而易见的是，在不背离权利要求中阐述的更广泛精神和范围的情况下，可以对其进行添加、减少、删除和其它修改和改变。因此，虽然已描述了具体的示例实施例，但是这些实施例不旨在进行限制。各种修改和等效物都在以下权利要求的范围之内。