Patent Description:
Authorization of users have taken many forms over the years. Traditionally, when a user signs up for an account for any type of online service, the user provides some amount of his/her personal information (e.g., name, email address, etc.). Each service account signup is typically met with a new request for information. The advent of OAuth has facilitated this process to some degree by providing an open standard for access delegation. OAUTH allows an end user's account information to be used by third-party services without exposing the user's password. That is, with the authorization of the user, the OAUTH mechanism may share information from one of the user's account with a third party application or website. For example, a user may permit PayPal, Inc. , to share the user's information with a third party application, such as a native application or website put out by a financial institution like Bank of America.

This sharing of information, however, occurs only in one direction (e.g., from PayPal to Bank of America) when authorized by the user. For example, this sharing of information is initiated when a request is sent, for example, by Bank of America to PayPal to obtain information about a user. An access token is returned from PayPal to Bank of America to grant access to certain information held bay PayPal. As indicated above, information only moves in one direction in this case - from PayPal to Bank of America.

Ostensibly, if a user approves sharing of information in one direction, the user will likely approve the sharing of information in the other direction as well. However, since only one access token is exchanged as a result of the request, the access is granted in only one direct. As such, there needs to be a mechanism that is capable of implementing a two-sided token to complete a bi-directional OAUTH exchange.

The Internet Draft publication <draft-ietf-oauth-reciprocal-<NUM> >, also entitled Reciprocal OAuth, by Hardt et al, which is available through the IETF discloses that while OAuth flows typically enable a user to grant a client access to a protected resource, granting the inverse access requires an additional flow, but that Reciprocal OAuth enables the user to more easily grant access to a pair of protected resources. A similar Internet publication RFC <NUM> by the same author entitled The OAuth <NUM> Authorization Framework describes the OAuth <NUM> authorisation framework that enables a third-party application to obtain limited access to an HTTP service. A Wikipedia article entitled Network Interface Controller, published on the Internet at https://en. org/wiki/Network_interface_controller, describes the history and functions of network interface controllers, and a chapter entitled<NPL> describes a decentralized pseudonymous and privacy preserving authorization management framework that leverages the consistency of blockchain technology to manage access control on behalf of constrained devices.

The invention is defined in the independent claims, with optional features being defined in the dependent claims.

Various features and advantages of the subject technology will be set forth in the description below, and in part will be apparent from the description, or may be learned by practice of the subject technology. The advantages of the subject technology will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

The accompanying drawings, which are included to provide further understanding of the subject technology and are incorporated in and constitute a part of this specification, illustrate aspects of the subject technology and together with the description serve to explain the principles of the subject technology.

By utilizing OAUTH, application nowadays provide mechanism for sharing information across applications. For example, a user with a PayPal account may authorize PayPal to share the user's information with a third-party application or website. These third-party applications or websites may provide platforms on which money or other transactions may be conducted, e.g., banking applications.

While this sharing of information occurs in one direction (e.g., from PayPal to Bank of America), it can be broadly assumed that a user authorizes the sharing of information from a first party to a second, that the user would generally have no issues with the second user sharing information with the first. To accomplish the sharing of information in both directions, however, the user must login to each of his two accounts with the two different organizations, and individually authorize information to be shared by the other account. This process generates a token to be transmitted in each direction, e.g., from Bank of America to PayPal in one instance, and from PayPal to Bank of America in another instance.

In order to solve this problem of sharing two different tokens when a company like PayPal partners with a company like Bank of America, a token exchange process is proposed. Specifically, a process where both parties issue a token during a single user journey is proposed so that the organizations do not have to ask the user to go through a separate journey for a second token exchange.

This specification includes references to "one embodiment," "some embodiments," or "an embodiment. " The appearances of these phrases do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.

"First," "Second," etc. As used herein, these terms are used as labels for nouns that they precede, and do not necessarily imply any type of ordering (e.g., spatial, temporal, logical, cardinal, etc.). Furthermore, various components may be described or claimed as "configured to" perform a task or tasks. In such contexts, "configured to" is used to connote structure by indicating that the components include structure (e.g., stored logic) that performs the task or tasks during operation. As such, the component can be said to be configured to perform the task even when the component is not currently operational (e.g., is not on). Reciting that a component is "configured to" perform one or more tasks is expressly intended not to invoke <NUM> U. § <NUM>(f) for that component.

<FIG> is a block diagram of an exemplary computing system on which the implementation of a two-side token for OAUTH may be performed. As shown, a computing system <NUM> may comprise or implement a plurality of servers, devices, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary servers, devices, and/or software components may include, for example, stand-alone and enterprise-class servers running an operating system (OS) such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable OS. It may be appreciated that the servers illustrated in <FIG> may be deployed in other ways and that the operations performed and/or the services provided by such servers may be combined, distributed, and/or separated for a given implementation and may be performed by a greater number or fewer number of servers. One or more servers may be operated and/or maintained by the same or different entities.

Computing system <NUM> may include, among various devices, servers, databases and other elements, one or more clients <NUM> comprising or employing one or more client devices <NUM>, such as a laptop, a mobile computing device, a tablet, a personal computer, a wearable device, and/or any other computing device having computing and/or communications capabilities in accordance with the described embodiments. Client devices <NUM> may also include a cellular telephone, smart phone, electronic wearable device (e.g., smart watch, virtual reality headset), or other similar mobile devices that a user may carry on or about his or her person and access readily.

Client devices <NUM> generally may provide one or more client programs <NUM>, such as system programs and application programs to perform various computing and/or communications operations. Exemplary system programs may include, without limitation, an operating system (e.g., MICROSOFT® OS, UNIX® OS, LINUX® OS, Symbian OS™, iOS, Android, Embedix OS, Binary Run-time Environment for Wireless (BREW) OS, JavaOS, a Wireless Application Protocol (WAP) OS, and others), device drivers, programming tools, utility programs, software libraries, application programming interfaces (APIs), and so forth. Exemplary application programs may include, without limitation, a payment system application, a web browser application, messaging application, contacts application, calendar application, electronic document application, database application, media application (e.g., music, video, television), location-based services (LBS) application (e.g., GPS, mapping, directions, positioning systems, geolocation, point-of-interest, locator) that may utilize hardware components such as an antenna, and so forth. One or more of client programs <NUM> may display various graphical user interfaces (GUIs) to present information to and/or receive information from one or more users of client devices <NUM>. In some embodiments, client programs <NUM> may include one or more applications configured to conduct some or all of the functionalities and/or processes discussed below.

As shown, client devices <NUM> may be communicatively coupled via one or more networks <NUM> to a network-based system <NUM>. Network-based system <NUM> may be structured, arranged, and/or configured to allow client <NUM> to establish one or more communications sessions between network-based system <NUM> and various client devices <NUM> and/or client programs <NUM>. Accordingly, a communications session between client devices <NUM> and network-based system <NUM> may involve the unidirectional and/or bidirectional exchange of information and may occur over one or more types of networks <NUM> depending on the mode of communication. While the embodiment of <FIG> illustrates a computing system <NUM> deployed in a client-server operating environment, it is to be understood that other suitable operating environments and/or architectures may be used in accordance with the described embodiments.

Data communications between client devices <NUM> and the network-based system <NUM> may be sent and received over one or more networks <NUM> such as the Internet, a WAN, a WWAN, a WLAN, a mobile telephone network, a landline telephone network, personal area network, as well as other suitable networks. For example, client devices <NUM> may communicate with network-based system <NUM> over the Internet or other suitable WAN by sending and or receiving information via interaction with a website, e-mail, IM session, and/or video messaging session. Any of a wide variety of suitable communication types between client devices <NUM> and system <NUM> may take place, as will be readily appreciated. In particular, wireless communications of any suitable form (e.g., Bluetooth, near-field communication, etc.) may take place between client device <NUM> and system <NUM>, such as that which often occurs in the case of mobile phones or other personal and/or mobile devices.

Network-based system <NUM> may comprise one or more communications servers <NUM> to provide suitable interfaces that enable communication using various modes of communication and/or via one or more networks <NUM>. Communications servers <NUM> may include a web server <NUM>, an API server <NUM>, and/or a messaging server <NUM> to provide interfaces to one or more application servers <NUM>. Application servers <NUM> of network-based system <NUM> may be structured, arranged, and/or configured to provide various online services to client devices that communicate with network-based system <NUM>. In various embodiments, client devices <NUM> may communicate with application servers <NUM> of network-based system <NUM> via one or more of a web interface provided by web server <NUM>, a programmatic interface provided by API server <NUM>, and/or a messaging interface provided by messaging server <NUM>. It may be appreciated that web server <NUM>, API server <NUM>, and messaging server <NUM> may be structured, arranged, and/or configured to communicate with various types of client devices <NUM>, and/or client programs <NUM> and may interoperate with each other in some implementations.

Web server <NUM> may be arranged to communicate with web clients and/or applications such as a web browser, web browser toolbar, desktop widget, mobile widget, web-based application, web-based interpreter, virtual machine, mobile applications, and so forth. API server <NUM> may be arranged to communicate with various client programs <NUM> comprising an implementation of API for network-based system <NUM>. Messaging server <NUM> may be arranged to communicate with various messaging clients and/or applications such as e-mail, IM, SMS, MMS, telephone, VoIP, video messaging, IRC, and so forth, and messaging server <NUM> may provide a messaging interface to enable access by client <NUM> to the various services and functions provided by application servers <NUM>.

Application servers <NUM> of network-based system <NUM> may be servers that provide various services such as tools for verifying URLs based on information collected about customers. Application servers <NUM> may include multiple servers and/or components. For example, application servers <NUM> may include a request generation engine <NUM>, response generation engine <NUM>, token generation engine <NUM>, and/or event queuing engine <NUM>. These servers and/or components, which may be in addition to other servers, may be structured and arranged to implement a two-side token for OAUTH.

Application servers <NUM>, in turn, may be coupled to and capable of accessing one or more databases <NUM> including system call database <NUM>, application database <NUM>, and/or user account database <NUM>. Databases <NUM> generally may store and maintain various types of information for use by application servers <NUM> and may comprise or be implemented by various types of computer storage devices (e.g., servers, memory) and/or database structures (e.g., relational, object-oriented, hierarchical, dimensional, network) in accordance with the described embodiments.

<FIG> illustrates an exemplary computer system <NUM> in block diagram format suitable for implementing on one or more devices of the computing system in <FIG>. In various implementations, a device that includes computer system <NUM> may comprise a personal computing device (e.g., a smart or mobile phone, a computing tablet, a personal computer, laptop, wearable device, PDA, etc.) that is capable of communicating with a network. A service provider and/or a content provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users, service providers, and content providers may be implemented as computer system <NUM> in a manner as follows. Additionally, as more and more devices become communication capable, such as smart devices using wireless communication to report, track, message, relay information and so forth, these devices may be part of computer system <NUM>.

Computer system <NUM> may include a bus <NUM> or other communication mechanisms for communicating information data, signals, and information between various components of computer system <NUM>. Components include an input/output (I/O) controller <NUM> that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, links, actuatable elements, etc., and sends a corresponding signal to bus <NUM>. I/O controller <NUM> may also include an output component, such as a display <NUM> and a cursor control <NUM> (such as a keyboard, keypad, mouse, touchscreen, etc.). In some examples, I/O controller <NUM> may include an image sensor for capturing images and/or video, such as a complementary metal-oxide semiconductor (CMOS) image sensor, and/or the like. An audio I/O component <NUM> may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component <NUM> may allow the user to hear audio.

A transceiver or network interface <NUM> transmits and receives signals between computer system <NUM> and other devices, such as another user device, a merchant server, an email server, application service provider, web server, a payment provider server, and/or other servers via a network. In various embodiments, such as for many cellular telephone and other mobile device embodiments, this transmission may be wireless, although other transmission mediums and methods may also be suitable. A processor <NUM>, which may be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on computer system <NUM> or transmission to other devices over a network <NUM> via a communication link <NUM>. Again, communication link <NUM> may be a wireless communication in some embodiments. Processor <NUM> may also control transmission of information, such as cookies, IP addresses, images, and/or the like to other devices.

Components of computer system <NUM> also include a system memory <NUM> (e.g., RAM), a static storage component <NUM> (e.g., ROM), and/or a disk drive <NUM>. Computer system <NUM> performs specific operations by processor <NUM> and other components by executing one or more sequences of instructions contained in system memory <NUM>. Logic may be encoded in a computer-readable medium, which may refer to any medium that participates in providing instructions to processor <NUM> for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and/or transmission media. In various implementations, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory such as system memory <NUM>, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus <NUM>. In one embodiment, the logic is encoded in a non-transitory machine-readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.

Some common forms of computer readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.

In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by computer system <NUM>. In various other embodiments of the present disclosure, a plurality of computer systems <NUM> coupled by communication link <NUM> to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another. Modules described herein may be embodied in one or more computer readable media or be in communication with one or more processors to execute or process the techniques and algorithms described herein.

A computer system may transmit and receive messages, data, information and instructions, including one or more programs (i.e., application code) through a communication link and a communication interface. Received program code may be executed by a processor as received and/or stored in a disk drive component or some other non-volatile storage component for execution.

Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.

Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer-readable media. It is also contemplated that software identified herein may be implemented using one or more computers and/or computer systems, networked and/or otherwise. Such software may be stored and/or used at one or more locations along or throughout the system, at client <NUM>, network-based system <NUM>, or both. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.

The foregoing networks, systems, devices, and numerous variations thereof may be used to implement one or more services, such as the services discussed above and in more detail below.

<FIG> illustrates an exemplary process <NUM> for implementing a two-side token for OAUTH is described. Continuing the example described above, the steps in <FIG> is described from the perspective of an authorization server <NUM> managed by the party (e.g., PayPal) that's providing the user's account information to a partner (e.g., Bank of America). In step <NUM>, a request is sent from the partner app server <NUM> to the PayPal auth server <NUM>. This request, which may include a client identification, a client secret, an indication of commons scopes, and an indication for two-way authorization, seeks authorization from the PayPal auth server <NUM> to access certain user information. This action may occur when, for example, a user wishes to link his PayPal account to his Bank of America account. An option to link the account may first be provided by Bank of America, whether via a Bank of America application or through Bank of America's website. Once prompted by the user to link PayPal back to his Bank of America account, a request is sent from the partner (i.e., Bank of America) app server <NUM> to the PayPal auth server <NUM>.

In some embodiments, the PayPal auth server <NUM> will verify that a two-way authorization is permissible based on a partner profile. For example, PayPal must determine that its partner (e.g., Bank of America) has the authority to request two-way authorization PayPal. Alternatively or additionally, the two-way authorization verification may be determined based on a particular user account. In some instances, a user's preference may be taken into account whether or not two-way authorization will be permitted for that user's account.

In some embodiments, a request is issued by PayPal to authorize this exchange. For example, the user may already be logged into his PayPal account (e.g., either on the browser being operated or within a native application running on a mobile device, which the user is also logged into), so no additional authentication would be required unless a predefined rule triggers additional security via the PayPal application or browser. Alternatively, if the user is not already logged in, the user may be prompted to enter credentials before an authorization occurs.

Once authorized, a response is returned from the PayPal auth server <NUM> to the partner app sever <NUM> in step <NUM>. This response includes an access token that, when in possession of the partner, may be used by the partner to access certain user account information. The limitations to the access (i.e., an indication of what information the partner has access to) is defined by the common scopes indicated in the request. As such, the partner may not have free reign over all of the user's account information in PayPal's possession unless the partner is authorized to have it.

Concurrent to the PayPal auth server <NUM> sending the response to the partner app server <NUM>, the response is written to an event queue engine <NUM> in step <NUM>. In some instances, the PayPal auth server <NUM> detects that the request provided an indication that a two-way authorization is being sought, and thus triggering the write operation. The event includes an identification of the partner and the common scopes. The event may further include an indication that the PayPal auth server <NUM> has provided a token to the partner app server <NUM>, and that a two-way authorization is being sought.

The event queue is accessible by multiple other applications within PayPal. For example, the PayPal app server <NUM> may be listening in on the event queue for certain events. In this case, the PayPal app server <NUM> may detect, in step <NUM>, that a response including an access token was sent from the PayPal auth server <NUM> to the partner app server <NUM>. That the request included a two-way authorization may also be detected. In some embodiments, the event posted may be a message, that when picked up by the PayPal app server <NUM>, suggesting a request be sent to the partner auth server <NUM> for a reciprocal access token. As such, a request is sent from the PayPal app server <NUM> to the partner auth server <NUM>. This request may similarly include a client identification, a client secret, and common scopes. What differs from the previous request, however, is that this request will not indicate a two-way authorization since this request is the back end of that two-way authorization.

As indicated above, the common scope provides a definition of how much user account information PayPal will make available to a partner. In some embodiments, when a two-sided token is generated, the scopes are symmetrical. In other words, whatever fields of information that's shared by PayPal to its partner will be shared back by the partner to PayPal. This symmetry can be particularly useful because different individuals may use different accounts for different purposes. For example, if a two-sided token is created to cross-share information between a user's Facebook and Linkedin accounts, the different types of information offered by each may, in combination, build a fairly comprehensive profile, where Facebook provides data that's more socially oriented where as Linkedin provides profession oriented information.

Alternatively, the token may define different levels of access provided by each partner to a corresponding partner. For instance, a user may not want to share his Linkedin connections with his Facebook account if the user does not wish to add his contacts from a professional forum to his contacts in a social forum. As such, the user may define what the token looks like from a common scopes perspective, and this relationship may be asymmetrical in nature.

In some embodiments, the client identification and client secret may be unique to each party. For example, PayPal will have one set of client identifications and client secrets while the partner has another set unique from PayPal's. As such, in order for this process to be accomplished, the partners are required to have certain amount of information from each other because the client identifications and client secrets are generally specific to an organization.

In some embodiments, a third-party authorization server that's common to PayPal and its partner(s) can be used to generate the token. For example, the authorization server may generates and maintains the common token. One characteristic of the common token is that both PayPal and its partner can decode the access token, and from the access token, determine who the client is and what are the common scopes shared by the two partners.

Instead of using a third-party authorization, a blockchain-based approach may alternatively be contemplated. In this approach again, both the parties issue a token each, but they are written to a Partner-PayPal blockchain that must be synced. <FIG> illustrates an alternative exemplary process <NUM> for implementing a two-side token for OAUTH using a blockchain. The blockchain-based approach is substantially similar to the process described in <FIG>, except that instead of sending the access token from one party's auth server to another party's app server, the token is written to a blockchain. For example, in step <NUM>, a request is sent from the partner app server <NUM> to the PayPal auth server <NUM>. This request, which may include a client identification, a client secret, an indication of commons scopes, and an indication for two-way authorization. In addition, the request may include a shared user identification that's used to uniquely identify the user on the blockchain.

As indicated above in reference to <FIG>, the partner seeks authorization from the PayPal auth server <NUM> to access certain user information. This action may occur when a user wishes to link his PayPal account to a partner account (e.g., user's Bank of America account). The request is sent from the partner (i.e., Bank of America) app server <NUM> to the PayPal auth server <NUM> when prompted by the user to link the two accounts.

Once authorized, a response is returned from the PayPal auth server <NUM> to the partner app sever <NUM> in step <NUM>, indicating a successful authorization. Concurrently with the sending of the response, the PayPal auth server <NUM> also writes an access token onto the PayPal node of the Partner-PayPal shared blockchain <NUM> in step <NUM>. After the access token is written to the PayPal node of the Partner-PayPal shared blockchain, the blockchain is synced with the partner node of the Partner-PayPal shared blockchain <NUM> in step <NUM>. In some embodiments, this syncing may occur on a periodic basis. Alternatively, the syncing may be performed each time data is written to the Partner-PayPal shared blockchain.

Once synced, the access token is read by the partner app server <NUM> off the partner node of the Partner-PayPal shared blockchain <NUM> in step <NUM>. Each of the access tokens written to the Partner-PayPal shared blockchain may include some information that facilitates identification of who the access refers to. For example, the access token may include some combination of the client identification, the client secret and the shared user identification. In reading the blockchain, the partner app server <NUM> is able to obtain the access token from the partner node of the Partner-PayPal shared blockchain <NUM> in step <NUM>.

At or around the same time that the access token is written to the PayPal node of the Partner-PayPal shared blockchain <NUM>, an event is written by the PayPal auth server <NUM> to the event queue engine <NUM>. The event that's written includes a partner identification and the commons scopes, and may provide an indication that the PayPal auth server <NUM> has provided a token to the PayPal node of the Partner-PayPal shared blockchain <NUM>, and that a two-way authorization is being sought.

The PayPal app server <NUM> may detect, in step <NUM>, that a response including an access token was sent from the PayPal auth server <NUM> to the PayPal node of the Partner-PayPal shared blockchain <NUM>. That the request included a two-way authorization may also be detected. As such, a request is sent from the PayPal app server <NUM> to the partner auth server <NUM>. This request may similarly include a client identification, a client secret, a shared user identification, and common scopes. This request will, however, indicate that a two-way authorization is not being sought since this request is the back end of that two-way authorization.

Upon receipt of the request from the PayPal app server <NUM>, a response is returned from the partner auth server <NUM> to the PayPal app sever <NUM> in step <NUM>, indicating a successful authorization. Concurrently with the sending of the response, the partner auth server <NUM> also writes an access token onto the partner node of the Partner-PayPal shared blockchain <NUM> in step <NUM>. After the access token is written to the partner node of the Partner-PayPal shared blockchain, the blockchain is synced with the PayPal node of the Partner-PayPal shared blockchain <NUM> in step <NUM>.

Once synced, the access token is read by the PayPal app server <NUM> off the PayPal node of the Partner-PayPal shared blockchain <NUM> in step <NUM>. Each of the access tokens written to the Partner-PayPal shared blockchain may, as indicated above, include some information that facilitates identification of who the access refers to. For example, the access token may include some combination of the client identification, the client secret and the shared user identification. In reading the blockchain, the PayPal app server <NUM> is able to obtain the access token from the PayPal node of the Partner-PayPal shared blockchain <NUM> in step <NUM>. Once the access tokens have been obtained by PayPal and the partner, user account information may be traded between PayPal and the partner limited only by the common scopes.

One advantage of writing the access tokens to a common blockchain is that the access tokens are not sent over the wire. In other words, access tokens are not sent over a standard hypertext transfer protocol (http) response. Furthermore, the access token is not placed in the control of either party. These elements provide additional elements of security that aren't necessarily available over convention channels of communication.

While the above description is provided with PayPal as the central organization to the exchange of tokens, authorization, and information, it can be appreciated that this process may be applied/adapted to any two or more partner organizations that possess user account information and want to share such information. For example, Facebook may provide an authorization tool to a third-party so that the third-party wouldn't have to build its own authorization tool. As long as the third-party considers Facebook a trusted source, it can choose to rely on Facebook for authorization.

The user device (i.e., the computing device) described above may be one of a variety of devices including but not limited to a smartphone, a tablet, a laptop and a pair of augmented reality spectacles. Each of these devices embodies some processing capabilities and an ability to connect to a network (e.g., the internet, a LAN, a WAN, etc.). Each device also includes a display element for displaying a variety of information. The combination of these features (display element, processing capabilities and connectivity) on the mobile communications enables a user to perform a variety of essential and useful functions.

The foregoing description is provided to enable a person skilled in the art to practice the various configurations described herein. While the subject technology has been particularly described with reference to the various figures and configurations, it should be understood that these are for illustration purposes only and should not be taken as limiting the scope of the subject technology.

There may be many other ways to implement the subject technology. Various functions and elements described herein may be partitioned differently from those shown without departing from the scope of the subject technology. Various modifications to these configurations will be readily apparent to those skilled in the art, and generic principles defined herein may be applied to other configurations. Thus, many changes and modifications may be made to the subject technology, by one having ordinary skill in the art, without departing from the scope of the subject technology.

It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously.

A phrase such as "an aspect" does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. An aspect may provide one or more examples of the disclosure. A phrase such as an "aspect" may refer to one or more aspects and vice versa. A phrase such as an "implementation" does not imply that such implementation is essential to the subject technology or that such implementation applies to all configurations of the subject technology. A disclosure relating to an implementation may apply to all implementations, or one or more implementations. An implementation may provide one or more examples of the disclosure. A phrase such an "implementation" may refer to one or more implementations and vice versa. A configuration may provide one or more examples of the disclosure. A phrase such as a "configuration" may refer to one or more configurations and vice versa.

Furthermore, to the extent that the terms "include," "have," and "the like" are used in the description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprise" as "comprise" is interpreted when employed as a transitional word in a claim.

Claim 1:
A host authorization system for implementing a two-side token for open authorization, OAUTH, comprising:
a non-transitory memory storing instructions; and
one or more hardware processors coupled to the non-transitory memory and configured to read the instructions from the non-transitory memory to cause the system to perform operations comprising:
determining, in response to receiving, at a host authorization server (<NUM>), a first request (<NUM>) from a partner application server (<NUM>) for access to a first user account information for a user account maintained by the host authorization server (<NUM>), an authorization to share the first user account information by the host authorization server (<NUM>), wherein a scope defines how much of the first user account information may be shared;
returning, upon determining the authorization to share the first user account information, a response (<NUM>) to the partner application sever first scope of multiple scopes of an access token, wherein the access token is usable by the partner application server (<NUM>) to access the first user account information at a first level of the multiple levels of access;
causing, in response to returning the access token to the partner application server (<NUM>), a submission, from a host application server (<NUM>) associated with the host authorization server (<NUM>) to a partner authorization server (<NUM>) associated with the partner application server (<NUM>), of a second request (<NUM>) for a reciprocal access token, wherein the reciprocal access token is usable by the host application server (<NUM>) to access a second user account information for the user account maintained by the partner authorization server (<NUM>) at a second scope of multiple scopes of access; and
wherein causing the submission of the second request (<NUM>) comprises writing (<NUM>) an event to an event queue, the event providing an indication that the first request (<NUM>) for access was received and that the corresponding response (<NUM>) with the access token was returned,
wherein the event, when read by the host application server (<NUM>), causes the host application server (<NUM>) to submit the second request (<NUM>) to the partner authorization server (<NUM>) for the reciprocal access token.