Application programming interface authorization conversion system

Abstract

An application programming interface authorization translation system is provided. In one embodiment, a method of translating API authorization to access functionality or services of a network system is provided, comprising: receiving at an API of the network system from a third party application a request to access an internal service not supported by the third party application on behalf of a user, the request including an access token previously granted to the third party application; translating by an authorization server of the network system the access token to an internal access token to access the internal service; and receiving at the API of the network system a response to the internal service, forwarding it as an API response to the third party application.

Description

[0001] This application is a divisional application of the Chinese Patent Application No. 202010846436.8 filed on August 20, 2020 with the title of “Application Programming Interface Authorization Conversion System”. TECHNICAL FIELD

[0002] The subject matter disclosed herein generally relates to machines configured to authorize access to a network system, and to techniques that improve such specialized machines as compared to other machines that authorize access to a network system. In particular, the present disclosure addresses systems and methods that convert API authorizations to access UX sessions or to obtain responses from internal services of a network system. BACKGROUND

[0003] Conventionally, third-party developers have access to a public application programming interface (API) of a network system. Typically, the third-party developers build a user interface (e.g., a third-party application) on their side by leveraging the public API. However, in some cases, the third-party application needs an experience capability that exists on the network system.

[0004] A user of the third-party application logs into the network system through the third-party software tool (e.g., the third-party application) and is granted an Open Authorization (OAuth) token that authorizes the third-party application to call network system APIs on behalf of the user. When the user wants to access a service / functionality that is not supported by the third-party application, the user is typically redirected to the network system where the user is requested to log in again to access a page at the network system that hosts the service / functionality. SUMMARY

[0005] According to an aspect of the present invention, there is provided a method comprising:

[0006] receiving, at an authorization server, a request from a third-party application developed by a third-party to access a user experience (UX) session on behalf of a user, the request comprising an access token previously granted to the third-party application by the authorization server in response to the user agreeing to allow the third-party application to perform an action on behalf of the user;

[0007] converting, by the authorization server, the access token to a single sign-on (SSO) link with a session token in response to receiving the request and based on the access token; and

[0008] sending, by the authorization server, the SSO link with the session token to the third-party application developed by the third-party, the SSO link causing the third-party application to redirect the user to the UX session corresponding to the SSO link.

[0009] According to another aspect of the present invention, there is provided a system comprising:

[0010] one or more hardware processors; and

[0011] a storage device storing instructions that, when executed by the one or more hardware processors, cause the one or more hardware processors to perform operations comprising:

[0012] receiving, from a third-party application developed by a third party, a request to access a user experience (UX) session on behalf of a user, the request including an access token previously granted to the third-party application by the user in response to the user agreeing to allow the third-party application to perform actions on behalf of the user;

[0013] in response to receiving the request, and based on the access token, converting, by the authorization server, the access token to a single sign-on (SSO) link with a session token; and

[0014] sending, by the authorization server, the SSO link with the session token to the third-party application developed by the third party, the SSO link causing the third-party application to redirect the user to the UX session corresponding to the SSO link.

[0015] According to yet another aspect of the application, there is provided a machine-readable storage medium storing instructions that, when executed by one or more processors of a machine, cause the one or more processors to perform operations comprising:

[0016] receiving, at an authorization server from a third-party application developed by a third party, a request to access a user experience (UX) session on behalf of a user, the request including an access token previously granted to the third-party application by the authorization server in response to the user agreeing to allow the third-party application to perform actions on behalf of the user;

[0017] in response to receiving the request, and based on the access token, converting, by the authorization server, the access token to a single sign-on (SSO) link with a session token; and

[0018] sending, by the authorization server, the SSO link with the session token to the third-party application developed by the third party, the SSO link causing the third-party application to redirect the user to the UX session corresponding to the SSO link. BRIEF DESCRIPTION OF DRAWINGS

[0019] The various accompanying drawings are included to provide a further understanding of example embodiments of the application, and are incorporated in and constitute a part of this specification. The drawings illustrate examples of the application and, together with the description, serve to explain the principles of the application.

[0020] Figure 1FIG. 1 is a diagram illustrating a network environment suitable for providing a system for converting API authorization to access a function or service of a network system without requiring a second login, according to some example embodiments.

[0021] Figure 2 FIG. 2 is a block diagram illustrating components of an authorization system, according to some example embodiments.

[0022] Figure 3 FIG. 3 is a diagram illustrating a communication flow for obtaining API authorization and using the API authorization to access a UX session, according to some example embodiments.

[0023] Figure 4 FIG. 4 is a flow diagram illustrating operations of a method for converting API authorization to access a UX session without requiring a second login, according to some example embodiments.

[0024] Figure 5 FIG. 5 is a diagram illustrating a service layer in a network system, according to some example embodiments.

[0025] Figure 6 FIG. 6 is a diagram illustrating a communication flow for converting authorization scopes across authorization domains to obtain an internal service response, according to some example embodiments.

[0026] Figure 7 FIG. 7 is a flow diagram illustrating operations of a method for converting authorization scopes across authorization domains to obtain an internal service response, according to some example embodiments.

[0027] Figure 8 FIG. 8 is a block diagram illustrating components of a machine, according to some example embodiments, able to read instructions from a machine-storage medium and perform any one or more of the methodologies discussed herein. DETAILED DESCRIPTION

[0028] The description that follows includes systems, methods, techniques, instruction sequences, and computing machine program products embodying illustrative embodiments of the inventive subject matter. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art, that embodiments of the inventive subject matter can be practiced without some or all of these specific details. In general, publically known instruction instances, protocols, structures, and techniques have not been been described in detail herein. The examples are merely representative. Unless otherwise expressly specified, structures (e.g., an structural components such as modules) are optional and can be combined or subdivided, and operations (e.g., in a procedure, algorithm, or other function) can vary in sequence or be combined or subdivided.

[0029] Network systems provide public APIs to third party developers who often leverage the public APIs to build user interfaces on their side. However, in some cases, the capabilities that exist on the network system are needed. For example, a catalog API can enable a third party application developed by a third party developer to search the catalog of the network system for product data. If there is a suggestion to update the catalog, the user can be redirected from the third party application (e.g., third party experience) to the experience of the network system. The user logs in with the network system and goes through an authorization flow to authorize the third party application to access the user’s data. This enables the third party application to call APIs on behalf of the user. For capabilities that are part of the network system experience available to the user after being redirected from the third party application, ideally, a frictionless single sign-on (SSO) and a session that is already established on the network system side is in place, whereby the permissions granted during the authorization flow are mapped to the permissions that control access during the session.

[0030] In some embodiments, access to internal services is needed to elicit a response. The public APIs are orchestrators that build responses by leveraging fine-grained internal capabilities. Such microservices have their own authorization scheme, so the public APIs should be properly authorized when calling internal services. Thus, once these APIs are authorized, the permissions granted in the authorization flow are mapped to the internal service permissions encapsulated in the internal access tokens presented to the internal services. Subsequent responses from the internal services are provided that conform to those internal service permissions.

[0031] As a result, the present disclosure provides two technical solutions to the technical problem of how to translate authorization granted in one namespace “domain” to another domain. In example embodiments, an authorization domain is a set of permissions that control authorization to a set of resources and capabilities in a network system. Example embodiments use the standard Open Authorization (OAuth) 2.0 protocol to authorize access to resources in two separate domains: 1) public APIs (e.g., called by authorized second and third party developers) and 2) internal web services (e.g., called by applications owned by the network system). In some embodiments, API authorization is translated to authorization to access a user experience (UX) session, while in other embodiments, API authorization is translated to authorization to access internal services to elicit a response.

[0032] Accordingly, some example embodiments are directed to a network system that manages access to user experience (UX) sessions at the network system without requiring the user to have to perform a second login with the network system. To provide a frictionless experience, example embodiments leverage an initial login performed by the user and facilitated by a third-party application to bypass a second login by the user when the user wishes to access a UX session (e.g., a function of the network system) that is not available through the third-party application. In example embodiments, the initial login is an Open Authorization (OAuth) process whereby the user logs in and provides consent to the third-party application to invoke network system APIs on behalf of the user.

[0033] In these embodiments, the SSO link used to authenticate and redirect the user to the UX session. Accordingly, once the user has authorized the third-party application to invoke network system APIs on behalf of the user with the OAuth process, the third-party application is granted an access token (also referred to as an "OAuth token") that includes the user's permissions. If the user needs to access a service of the network system that is not supported by the third-party application, the third-party application exchanges the access token with an authorization server associated with the network system to obtain an SSO link. The authorization server generates and sends back to the third-party application an SSO link that includes a session token. The third-party application then uses the SSO link that includes the session token to redirect the user to the UX session.

[0034] The UX session that the user accesses is determined based on the user's permissions originally found in the access token. The authorization server maps the permissions in the access token to permission settings of the UX session, so the UX session presented to the user only provides services that the user and the third-party application have permissions to access. Accordingly, the conversion in these embodiments is a conversion of API authorization for the UX session without requiring a second login by the user.

[0035] In alternative embodiments, the conversion is a conversion of authorization granted in one domain to another domain in order to obtain an internal service response. In these embodiments, the API receives an OAuth token from the third-party application along with an API request. The API determines that access to an internal service is needed in order to respond to the API request. Accordingly, the API exchanges the OAuth token with an authorization system to obtain an internal access token that has mapped the permissions obtained from the OAuth token. The internal access token is then sent to the internal service along with the internal service request, which the internal service responds to within the permissions of the internal access token. The response is then formatted and returned to the third-party application as an API response.

[0036] For example, Alice is a seller on a network system, and Bob is a developer providing a multi-channel selling tool. Alice is a customer of Bob. Bob's software tool (e.g., a third-party application) integrates with the catalog API of the network system and allows Alice to search for products and view product details. When Alice logs into her network system account through Bob's software tool, she is granted an OAuth token in the public API "domain" that authorizes Bob's software tool to call the catalog API on her behalf. Bob's experience does not support product changes. Thus, when Alice wants to suggest an update to the product catalog, Bob's software tool redirects the flow to the network system. To avoid asking Alice to log in again and to achieve as frictionless an experience as possible, Bob's software tool integrates with the authorization service of the network system to exchange Alice's OAuth token for an SSO link. The SSO link includes the information needed to establish a session and let Alice navigate through the network system UX to submit her catalog change request. Once done, Alice is redirected back to Bob's software tool and continues to manage her inventory.

[0037] Thus, the present disclosure provides technical solutions to the technical problem of how to convert an authorization granted in one namespace "domain" to another domain. In some embodiments, the conversion is a conversion of an API authorization for a UX session without requiring a second login by the user. In some embodiments, the conversion is a conversion of an API authorization for an internal access token to obtain a response from an internal service. As a result, one or more methods described herein facilitate solving the technical problem associated with having to perform multiple authorization processes to access a service or function of a network system. As a result, resources used by one or more machines, databases, or devices (e.g., in an environment) can be reduced. Examples of such computing resources include processor cycles, network traffic, memory usage, data storage capacity, power consumption, network bandwidth, and cooling capacity.

[0038] Reference is made to Figure 1 FIG. 1 shows an example embodiment of a network environment 100 that provides a system for converting API authorizations to access a network system (e.g., a UX session or an internal service) without requiring a second login. A network system 102 provides server-side functionality to a plurality of user devices including a third-party device 106 and a user device 108 via a communication network 104 (e.g., the Internet, a wireless network, a cellular network, or a wide area network (WAN)).

[0039] The third-party devices 106 and the user devices 108 interface with the networked system 102 via connections with the network 104. Depending on the form of each of the third-party devices 106 and the user devices 108, any of a variety of types of connections and networks 104 can be used. For example, the connection can be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile Communications (GSM) connection, or another type of cellular connection. Such a connection can implement any of a variety of types of data transfer technology (e.g., single-carrier radio transmission technology (lxRTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data Rates for GSM Evolution (EDGE) technology, or other data transfer technology (e.g., fourth generation wireless, 4G networks)). When such technology is employed, the network 104 can comprise a cellular network having a plurality of cell sites with overlapping geographic coverage that are interconnected by cellular telephone switches. These cellular telephone switches can be coupled to a network backbone (e.g., a public switched telephone network (PSTN), a packet-switched data network, or other type of network).

[0040] In another example, the connection with the network 104 can be a Wireless Fidelity (Wi-Fi, IEEE 802.1 lx type) connection, a Worldwide Interoperability for Microwave Access (WiMAX) connection, or another type of wireless data connection. In such embodiments, the network 104 can comprise one or more wireless access points coupled to a local area network (LAN), a wide area network (WAN), the Internet, or another packet-switched data network. In yet another example, the connection with the network 104 can be a wired connection (e.g., an Ethernet link), and the network 104 can be a LAN, a WAN, the Internet, or another packet-switched data network. Thus, a variety of different configurations are expressly contemplated.

[0041] In various embodiments, data exchanged within the network environment 100 can depend on functionality selected by a user available through one or more client or user interfaces (UIs). The UIs are associated with the user devices 108 that execute web clients (e.g., Internet browsers) that can communicate with the network system 102. The UIs can also be associated with one or more third-party applications provided by the third-party devices 106 (e.g., third-party applications or operating systems designed by developers for interacting with the network system 102).

[0042] User devices 108 can include, but are not limited to, smartphones, tablet computers, notebook computers, multi-processor systems, microprocessor-based or programmable consumer electronics, game consoles, set-top boxes, servers, or any other communication devices that a user can use to access network system 102. In some embodiments, user devices 108 include a display module (not shown) to display information (e.g., in the form of a user interface). In other embodiments, user devices 108 can include one or more of a touchscreen, an accelerometer, a camera, a microphone, and a global positioning system (GPS) device.

[0043] User devices 108 can include one or more applications (also referred to as "apps"), such as, but not limited to, a web browser, a messaging application, an electronic mail (email) application, an e-commerce website application (also referred to as a marketplace application), a third-party application, and the like. In some embodiments, if a website application (e.g., an e-commerce website application) is included in user devices 108, the application is configured to provide a user interface and at least some functionality locally, where the application is configured to communicate with network system 102 as needed to obtain data or processing power not available locally (e.g., to access a database of published items, to authenticate a user, to verify a payment method, to negotiate a price with multiple sellers). Conversely, if a website application is not included in user devices 108, user devices 108 can use its web browser to access a website (or a variant thereof) hosted on network system 102. Still further, user devices 108 can provide a third-party application with authorization to make API calls on behalf of a user of user devices 108.

[0044] Turning specifically to network system 102, application program interface (API) server 110 and web server 112 are coupled to, and provide programmatic and web interfaces respectively, to one or more application servers 114. Application servers 114 host published system 116 and authorization system 118, each of which can include one or more modules, applications, or engines, and can be embodied as hardware, software, firmware, or any combination thereof. Accordingly, application servers 114 are coupled to one or more database servers 120 that facilitate access to one or more information stores or databases 122. In one embodiment, databases 122 are storage devices storing content (e.g., publication or item listings, store information, buyer profiles including past browsing and purchase histories, seller profiles) used by network system 102.

[0045] In example embodiments, the publication system 116 publishes content on a network (e.g., the Internet). Thus, the publication system 116 provides a plurality of publication functions and services to users that access the network system 102. For example, the publication system 116 can host a marketplace application that provides a plurality of marketplace functions and services to users, such as publication, listing, and price setting mechanisms whereby sellers can list (or publish information relating to) goods or services (also referred to collectively as "items") for sale, and potential users or buyers can express interest in or indicate a willingness to purchase such goods or services, and handle transactions related to such goods or services. However, it should be noted that in alternative embodiments, the publication system 116 can be associated with a non-marketplace environment, such as an information environment (e.g., a search engine) or a social-networking environment.

[0046] The authorization system 118 includes one or more authorization servers that participate in an Open Authorization (OAuth) process to initially authorize third-party applications to make API calls on behalf of a user. According to some embodiments, the authorization system 118 subsequently converts an access token generated during the OAuth process into a single sign-on (SSO) link to access a UX session of the network system 102. In other embodiments, the authorization system 118 converts an access token generated during the OAuth process into an internal access token to obtain internal service responses from the network system 102. In conjunction with the publication system 116, the authorization system 118 can also provide a plurality of authorization functions and services to users that access the network system 102. Figure 2 The authorization system 118 will be discussed in greater detail.

[0047] While the publication system 116 and the authorization system 118 are both shown as forming part of the network system 102 in Figure 1 it should be understood that, in alternative embodiments, the publication system 116 or the authorization system 118 can form part of a separate service from the network system 102. Moreover, while the publication system 116 and the authorization system 118 are shown as being implemented as server-based systems in Figure 1 the client-server based network environment 100 shown employs a client-server architecture. Of course, the inventive subject matter is equally well

[0048] In example embodiments, any system, server, or device (collectively "component") shown in or associated with Figure 1 may be, can include, or otherwise be implemented in a special purpose computer (e.g., a professional or other non-generic computer) that has been modified (e.g., through software (such as one or more software modules of an application), an operating system, firmware, middleware, or other program configuration or programming) to perform one or more functions described herein for that system or machine. For example, the following with respect to Figure 8A special purpose computer system capable of implementing any one or more of the methodologies described herein is discussed, and such a special purpose computer can therefore be an apparatus for performing any one or more of the methodologies discussed herein. In the art of such special purpose computers, a special purpose computer that has been modified by the structures discussed herein to perform the functions discussed herein is technically improved over a special purpose computer that lacks the structures discussed herein or other special purpose computers that are otherwise unable to perform the functions discussed herein. Thus, a special purpose machine configured according to the systems and methods discussed herein provides a technical improvement over similar special purpose machines.

[0049] Further, Figure 1 Any two or more of the systems, servers, or devices shown in FIG. 1 can be combined into a single system, server, or device, and the functions described herein for any single system, server, or device can be subdivided among multiple systems or devices. In addition, any number of network systems 102, third party devices 106, and user devices 108 can be embodied in the network environment 100. Furthermore, some components or functions of the network environment 100 can be combined in or located elsewhere in the network environment 100.

[0050] Figure 2 FIG. 2 is a block diagram illustrating components of an authorization system 118, in accordance with some example embodiments. In example embodiments, the authorization system 118 includes one or more authorization servers that include components that manage authentication of users, API authorization of third party applications to make API calls on behalf of users, and translation of API authorization across authorization domains by mapping permissions from API domains to internal domains (e.g., internal services, UX) without requiring a second login by the user. To implement these operations, the authorization system 118 includes a communication module 202, an OAuth engine 204, a link generator 206, and a token module 208, all of which are configured to communicate with one another (e.g., via a bus, shared memory, or a switch). The authorization system 118 can also include other components (not shown) that are not relevant to the example embodiments. Moreover, any one or more of the components (e.g., engines, modules, generators) described herein can be implemented using hardware (e.g., a processor of a machine) or a combination of hardware and software. Moreover, any two or more of these components can be combined into a single component, and the functions described herein for a single component can be subdivided among multiple components.

[0051] The communication module 202 manages the exchange of communications with third-party applications (e.g., provided by third-party devices 106 and operating on user devices 108). Specifically, the communication module 202 exchanges information with third-party applications during an authorization code flow to generate an API authorization (e.g., an access token associated with a user) that allows the third-party application to make API calls on behalf of the user. In example embodiments, the third-party application sends the user through a standard authorization code flow in which the user is granted an access token. In example embodiments, the standard authorization code flow is a standard three-legged Open Authorization (OAuth) flow, and the access token is an OAuth token.

[0052] The communication module 202 also receives requests to convert API authorizations (e.g., access tokens) to authorize access to services or functions of the network system 102 (e.g., a UX session of the network system 102 or an internal service). In some embodiments, the communication module 202 works with other components of the authorization system 118 to return a single sign-on (SSO) link that allows the user (e.g., at the user device 108) to access a UX session of the network system 102 without requiring the user to log in a second time. In other embodiments, the communication module 202 works with other components of the authorization system 118 to convert authorization scopes across authorization domains in order to return a response from an internal service of the network system 102.

[0053] The OAuth engine 204 is configured to perform an OAuth flow. In example embodiments, the OAuth engine 204 receives an authorization code request (e.g., via the communication module 202). The OAuth engine 204 also receives a login (e.g., user credentials and a password or PIN) and consent to authorization from a user at a user device 108 via a third-party application. During the OAuth flow, the OAuth engine 204 generates an access token after the user logs in using their credentials. Ideally, this login (also referred to herein as “sign-in”) is the only time the user will be required to sign in to the network system 102. The token generated by the OAuth engine 204 includes embedded permissions that define, at the network system 102, the resources that the user (by the third-party application) is to access and the operations that can be performed on that resource. In conjunction Figure 3 The OAuth flow will be discussed in more detail.

[0054] Link generator 206 is configured to generate SSO links. In an example embodiment, authorization system 118 receives a request via communication module 302 to exchange an access token obtained during an OAuth process for an SSO link. Link generator 206 generates the SSO link, mapping the embedded permissions associated with the access token to UX permissions encapsulated within a session token in the process. The subsequent UX session provides access to user interfaces or services authorized by these UX permissions. The session token is then included in the SSO link and sent by communication module 202 to the third-party application. In one embodiment, the SSO link is an SSO Uniform Resource Locator (URL). Using the SSO link, the third-party application redirects the user to the UX session of network system 102.

[0055] Token module 208 is configured to manage token exchange with the API to convert authorization scopes across authorization domains into internal access tokens. In an example embodiment, token module 208 receives an access token from the API and a request to exchange that access token for an internal access token. In response, token module 208 grants the internal access token to the API. In an example embodiment, token module 208 generates the internal access token by encapsulating the permissions from the access token into the internal access token. The API can then use the internal access token to access internal services by sending an internal service request with the internal access token to the internal service.

[0056] Figure 3 This is a diagram illustrating a communication flow 300, according to some example embodiments, for obtaining API authorization and using that authorization to access UX session 306 without requiring a second login from the user using network system 102. First, API authorization (and an API access token) is granted to a third-party application 302. Subsequently, the third-party application exchanges the API authorization to access UX session 306 of network system 102 without user input (e.g., a second user login or a request for UX permissions).

[0057] In the example implementation, API authorization includes a standard three-legged OAuth process. For example... Figure 3 As shown, the OAuth process begins with a request for an authorization code from a third-party application to the authorization system 118. The resource owner 304 (e.g., a user of user device 108) provides login and consents to the third-party application 302 making API calls on their behalf. For example, a credential user interface with fields for the resource owner 304 to provide credentials such as username, password, or PIN is displayed to the resource owner 304 on user device 108. By providing credentials, the resource owner 304 inherently or explicitly provides consent for the third-party application 302 to make API calls on their behalf.

[0058] Once the authorization system 118 receives the login and consent, the authorization system 118 can verify (e.g., authenticate) the resource owner 304. The authorization system 118 then generates an authorization code and returns the authorization code to the third-party application 302.

[0059] Subsequently, the third-party application 302 exchanges the authorization code for an access token. Thus, the third-party application 302 sends the authorization code with a request for an access token. The authorization system 118 receives the request and authorization code and generates an access token. In example embodiments, the access token includes embedded permissions that define the resources the user is to access and the operations that are performable on that resource. In example embodiments, the access token is also referred to herein as an OAuth token.

[0060] In cases where the resource owner 304 wants to perform an operation or access information that is not supported by the third-party application 302, the resource owner 304 needs to be redirected to the network system 102 (e.g., the UX session 306 at the network system 102). In example embodiments, the third-party application integrates with the authorization system 118 to exchange an OAuth token for an SSO link. Thus, in these cases, the third-party application 302 exchanges an OAuth token for an SSO link. In example embodiments, the authorization system 118 receives the request to exchange an OAuth token for an SSO link via the communication module 302.

[0061] In response to receiving the exchange request, the authorization system 118 (e.g., the link generator 206) generates an SSO link and, in the process, maps the embedded permissions associated with the access token to UX permissions encapsulated within a session token. The mapping also takes into account the permissions granted to the third-party application (e.g., a particular third-party application can not have access to all areas of the network system 102 even if the user has that permission in the access token). The session token is then included in the SSO link and returned to the third-party application 302. In one embodiment, the SSO link is an SSO uniform resource locator (URL).

[0062] The third-party application 302 uses the SSO link to redirect the resource owner 304 to the UX session 306 at the network system 102. The SSO link has all the information needed to establish the UX session 306. Thus, the UX session 306 provides access to user interfaces or services authorized by these UX permissions.

[0063] Figure 4 is a flowchart illustrating operations of a method 400 for converting API authorization to access a UX session without requiring a second login by a user, in accordance with some example embodiments. The operations in the method 400 can be performed by the authorization system 118 using the above-described components of the authorization system 118 and the network system 102. Figure 2The described components to perform. Thus, the method 400 is described by way of example with reference to the example of the authorization system 118. However, it should be appreciated that at least some of the operations of the method 400 can also be deployed on various other hardware configurations or performed by similar components residing elsewhere in the network environment 100. Thus, the method 400 is not intended to be limited to the authorization system 118.

[0064] In operation 402, the OAuth engine 204 performs an Open Authorization (OAuth) process to grant API authorization to the third-party application 302 to make API calls on behalf of a user. In an example embodiment, the OAuth engine 204 receives an authorization code request (e.g., via the communication module 202) and receives a login (e.g., user credentials and a password or PIN) and consent to authorization from a user at the user device 108 via the third-party application. In some embodiments, the OAuth engine 204 generates and returns an authorization code to the third-party application 302, which is later exchanged by the third-party application 302 for an access token or OAuth token. In some embodiments, the OAuth engine 204 generates an access token that embeds permissions that define the resources to be accessed by the user and the operations that are executable on the resources.

[0065] When a user (e.g., resource owner 304) wants to perform an operation or access information that is not supported by the third-party application 302, the user needs to be redirected to the network system 102 (e.g., a UX session at the network system 102). In an example embodiment, the third-party application 302 integrates with the authorization system 118 to exchange an access token for a single sign-on (SSO) link. In operation 404, the authorization system 118 receives a request for an access session at the network system 102. The request includes the OAuth token.

[0066] In operation 406, the link generator 206 generates a session token. In an example embodiment, the link generator 206 maps the embedded permissions associated with the access token to UX permissions and encapsulates the UX permissions in the session token.

[0067] In operation 408, the link generator 206 generates an SSO link. In an example embodiment, the SSO link includes the session token with the embedded UX permissions. In one embodiment, the SSO link is an SSO uniform resource locator (URL).

[0068] In operation 410, the authorization system 118 sends the SSO link to the third-party application 302. In operation 412, the third-party application 302 uses the SSO link to redirect the user to the network system 102 (e.g., a UX session at the network system 102). When the resource owner 304 ends the UX session 306, the network system 102 redirects the user (e.g., the user device 108) back to the third-party application 302.

[0069] While example embodiments have been discussed whereby the user does not need to perform a second factor authentication to access the UX session, alternative embodiments can include a second factor authentication. In these alternative embodiments, the second factor authentication can be performed in addition to or instead of the API authorization conversion for the UX session.

[0070] Figure 5 FIG. 1 is a diagram illustrating a service layer in the network system 102. The public API is a complex orchestrator that is backed by an internal microservice group (e.g., an internal microservice layer). The public API is a thin layer with little or no business logic incorporated and tailored to the needs of external clients. The API utilizes internal services to build a response.

[0071] Figure 6 FIG. 2 is a diagram illustrating a communication flow for converting authorization scopes to obtain an internal service response across authorization domains, according to some example embodiments. As with the communication flow of FIG. 1, the API authorization includes a standard three-legged OAuth flow. As shown in FIG. 2, the OAuth flow begins with a request for an authorization code from a third-party application to the authorization system 118. The resource owner 304 (e.g., a user of the user device 108) provides a login and consents to the third-party application 302 making API calls on behalf of the resource owner. By providing the credentials, the resource owner 304 inherently or explicitly provides consent for the third-party application 302 to make API calls on behalf of the resource owner 304. Figure 3 Figure 6 As shown in FIG. 2, the OAuth flow begins with a request for an authorization code from a third-party application to the authorization system 118. The resource owner 304 (e.g., a user of the user device 108) provides a login and consents to the third-party application 302 making API calls on behalf of the resource owner. By providing the credentials, the resource owner 304 inherently or explicitly provides consent for the third-party application 302 to make API calls on behalf of the resource owner 304.

[0072] Once the authorization system 118 receives the login and consent, the authorization system 118 authenticates (e.g., verifies) the resource owner 304. The authorization system 118 then generates an authorization code and returns the authorization code to the third-party application 302.

[0073] Subsequently, the third-party application 302 exchanges the authorization code for an access token. Thus, the third-party application 302 sends the authorization code with a request for an access token. The authorization system 118 receives the request and authorization code and generates an access token. In example embodiments, the access token includes an embedded permission that defines a resource that the user is to access and an operation that is executable on the resource. In example embodiments, the access token is also referred to herein as an OAuth token. The access token is granted to the third-party application 302.​

[0074] The third-party application 302 sends the API request with the access token to the appropriate API 602. Once the API 602 receives the request, the API 602 can determine that a response from the internal service 604 is needed. In these cases, the API 602 exchanges the access token in the request for an internal access token. Thus, the API sends the access token to the authorization system 118 with an exchange request.

[0075] In response to receiving the exchange request, the authorization system 118 (e.g., the token module 208) generates an internal access token. In example embodiments, the token module 208 maps the embedded permissions associated with the access token to internal service permissions encapsulated within the internal access token. The mapping also takes into account the permissions granted to the third-party application (e.g., a particular third-party application can not have access to all areas of the network system 102 even if the user has that permission in the access token).

[0076] The internal access token is returned to the API 602, which then uses the internal access token to access the internal service 604. Specifically, the API 602 sends an internal service request with the internal access token to the internal service 604. Based on the permissions encapsulated in the internal access token, the internal service 604 provides an appropriate internal service response to the API 602. The API 602 then forwards the internal service response to the third-party application 302 as an API response.

[0077] Both the public API and the internal web services use the standard OAuth 2.0 protocol for authorization. For example, the catalog API in the example above is backed by two internal services: product search and product details. The third-party application 302 calls the catalog API and passes the access token through the authorization request header. The public API (e.g., catalog API) integrates with the authorization system 118 to exchange the access token for an internal access token with a scope from the internal web service authorization domain. The internal access token encapsulates the granted API authorization that has been converted to internal microservice authorization. The catalog API obtains a response from the internal service 604, applies formatting rules consistent across the public API, and sends the formatted response to the client (e.g., third-party application 302).

[0078] Figure 7 is a flow diagram illustrating operations of a method 700 for converting authorization scopes across authorization domains to obtain a response from an internal service, according to some example embodiments. The operations in the method 700 can be used by the network system 102 using the above-described Figure 1 and Figure 2The described components to perform. Thus, the method 700 is described by way of example with reference to the network system 102. However, it should be appreciated that at least some of the operations of the method 700 can be deployed on various other hardware configurations or performed by similar components residing elsewhere in the network environment 100. Accordingly, the method 700 is not intended to be limited to the network system 102.

[0079] In operation 702, the OAuth engine 204 performs an Open Authorization (OAuth) process to grant API authorization to the third-party application 302 to make API calls on behalf of the user. In example embodiments, the OAuth engine 204 receives an authorization code request (e.g., via the communication module 202) and receives a login (e.g., user credentials and a password or PIN) and consent to authorization from the user at the user device 108 via the third-party application. In some embodiments, the OAuth engine 204 generates and returns an authorization code to the third-party application 302, which is subsequently exchanged by the third-party application 302 for an access token or OAuth token. In some embodiments, the OAuth engine 204 generates an access token that embeds permissions that define the resources the user has access to and the operations that are executable on the resources.

[0080] When the third-party application 302 sends an API request with the access token to the API 602 on behalf of the user. The API 602 receives the API request in operation 704.

[0081] In some embodiments, the API 602 determines that the API 602 request requires information, operations, or functionality of the internal services 604. Accordingly, in operation 706, the API 602 exchanges the access token for an internal access token. The public API 602 integrates with the authorization system 118 to exchange the access token for an internal access token with scopes from the internal web service authorization domain. In example embodiments, the authorization system 118 (e.g., the token module 208) generates the internal access token. For example, the token module 208 maps the embedded permissions associated with the access token to internal service permissions encapsulated within the internal access token. The mapping also takes into account the permissions granted to the third-party application (e.g., even if the user has the permission in the access token, the particular third-party application can not have access to all areas of the network system 102). The internal access token is returned to the API 602, which then uses the internal access token to access the internal services 604.

[0082] In operation 708, the API 602 obtains an internal service response. In example embodiments, the API 602 uses the internal access token to access the internal service 604. Specifically, the API sends an internal service request with the internal access token to the internal service 604. Based on the permissions encapsulated in the internal access token, the internal service 604 provides an appropriate internal service response to the API 602.

[0083] In operation 710, the API 602 forwards the internal service response to the third party application 302 as an API response. In some embodiments, the API 602 formats the internal service response as an appropriate API response for transmission to the third party application 302.

[0084] While example embodiments have been discussed whereby a user does not need to perform a second factor authentication to access the internal service 604, alternative embodiments can include a second factor authentication.

[0085] Figure 8 A schematic diagram of a machine 800 is shown in the example form of a computer device (e.g., a computer), and in which instructions 824 (e.g., software, a program, an application, an applet, an app, or other executable code) can be read for execution by the machine 800, such that the machine 800 becomes a particular machine (e.g., a specially configured machine) specifically Figure 8 A schematic diagram of a machine 800 is shown in the example form of a computer device (e.g., a computer), and in which instructions 824 (e.g., software, a program, an application, an applet, an app, or other executable code) can be read for execution by the machine 800, such that the machine 800 becomes a particular machine (e.g., a specially configured machine) specifically

[0086] For example, the instructions 824 can cause the machine 800 to execute the communication flows and flowcharts described above. In one embodiment, the instructions 824 can transform the general, non-programmed machine 800 into a particular machine (e.g., a specially configured machine) programmed to carry out the described and illustrated functions in the manner described. Figure 3 to Figure 7

[0087] ​In alternative embodiments, the machine 800 operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine 800 can operate in the capacity of a server machine or a client machine in server-client network environments, or as a peer machine in peer-to-peer (or distributed) network environments. The machine 800 can be a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions 824, sequentially or otherwise, that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute the instructions 824 to perform all or part of any one or more of the methodologies discussed herein.

[0088] The machine 800 includes a processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), or any combination thereof), a main memory 804, and a static memory 806, which are configured to communicate with each other via a bus 808. The processor 802 can contain microcircuits that are temporarily or permanently configured to be a set of instructions 824 that are executable by the processor 802, such that the processor 802 can be configured to perform any one or more of the methodologies described herein, in whole or in part. For example, a set of one or more microcircuits of the processor 1002 can be configured to perform one or more of the modules described herein (e.g., software modules).

[0089] The machine 800 can further include a graphics display 810 (e.g., a plasma display panel (PDP), a light-emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT), or any other display capable of displaying graphics or video), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit 816, a signal generation device 818 (e.g., a sound card, an amplifier, a speaker, a headphone jack, or any combination thereof), and a network interface device 820.

[0090] Storage unit 816 includes machine-storage media 822 (e.g., tangible machine- readable storage media) on which are stored instructions 824 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 824 can also reside completely, though not exclusively, within the main memory 804, within the processor 802 (e.g., within the processor's cache memory), or both during execution thereof by the machine 800. Thus, the main memory 804 and the processor 802 can be considered machine-readable media (e.g., tangible and non-transitory machine-readable media). The instructions 824 can be transmitted or received over a network 826 via the network interface device 820.

[0091] In some example embodiments, the machine 800 can be a portable computing device and have one or more additional input components (e.g., sensors or gauges). Examples of such input components include image input components (e.g., one or more cameras), audio input components (e.g., microphones), directional input components (e.g., a compass), location input components (e.g., a Global Positioning System (GPS) receiver), directional components (e.g., a gyroscope), motion detection components (e.g., one or more accelerometers), altitude detection components (e.g., an altimeter), and gas detection components (e.g., a gas sensor). Input obtained by any one or more of these input components is accessible to and can be used by any of the modules described herein.

[0092] Executable instructions and machine-storage media

[0093] The various memories (i.e., 804, 806, and / or the memory of the processor 802) and / or the storage unit 816 can store one or more sets of instructions and data structures (e.g., software) 824 embodying or utilized by any one or more of the methodologies or functions described herein. These instructions, when executed by the processor 802, cause various operations to be performed to implement the disclosed embodiments.

[0094] As used herein, the terms "machine-storage medium," "device-storage medium," "computer-storage medium" (referred to collectively as "machine-storage medium 822") mean the same thing and can be used interchangeably in this disclosure. The terms mean a single or multiple storage devices and / or media (e.g., a centralized or distributed database, and / or associated caches and servers) that store executable instructions and / or data structures. The terms shall therefore include, but not be limited to, solid-state memories, and optical and magnetic media, including a non-transitory storage medium. Specific examples of machine-storage media, computer-storage media, and / or device-storage media 822 include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGA, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine-storage media," "computer-storage media," and "device-storage media 822" specifically exclude carrier waves, modulated data signals, and other such media, at least some of which are covered under the term "signal medium" as discussed below. In this context, machine-storage media are non-transitory.

[0095] Signal Medium

[0096] The terms "signal medium" or "transmission medium" shall be taken to include any form of modulated data signal, carrier wave, and so forth. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

[0097] Computer-Readable Medium

[0098] The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" mean the same thing and can be used interchangeably in this disclosure. The terms are defined to include both machine-storage media and transmission media. Thus, the terms include both storage devices / media and carrier waves / modulated data signals.

[0099] The instructions 824 can further be transmitted or received using a transmission medium via the network interface device 820 utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone service (POTS) networks, and wireless data networks (e.g., WiFi, LTE, and WiMAX networks). The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the instructions 824 for execution by the machine 800, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

[0100] Throughout this specification, plural instances can implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations can be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations can be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component can be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter of this document.

[0101] Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules can constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A "hardware module" is a tangible unit capable of performing certain operations and can be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware modules of a computer system (e.g., a processor or a processor core) can be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

[0102] In some embodiments, a hardware module can be implemented mechanically, electronically, or any suitable combination thereof. For example, a hardware module can include dedicated circuitry or logic that is permanently configured to perform certain operations. For example, a hardware module can be implemented as a special-purpose processor, such as a field-programmable gate array (FPGA) or an ASIC. A hardware module can also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware module can include software encompassed within a general-purpose processor or other programmable processor. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) can be driven by cost and time considerations.

[0103] Accordingly, the term "hardware module" should be understood to encompass a tangible entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner and / or to perform certain operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where a hardware module comprises a general-purpose processor configured by software to become a special-purpose processor, the general-purpose processor can be configured as the special-purpose processor at one instance of time and then configured back to the general-purpose processor at a different instance of time.

[0104] Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules can be regarded as being communicatively coupled. Where multiple hardware modules exist contemporaneously, communications can be achieved through signal transmission (e.g., over appropriate circuits and buses) between or among two or more of the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules can be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module can perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module can then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules can also initiate communications with input or output devices, and can operate on resources (e.g., information) stored within memory structures.

[0105] Various operations of example methods described herein can be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented modules that operate to perform one or more operations or functions described herein. As used herein, "processor-implemented module" refers to a hardware module implemented using one or more processors.

[0106] Similarly, the methods described herein can be at least partially processor- implemented, a processor being an example of hardware. For example, at least some of the operations of a method can be performed by one or more processors or processor- implemented modules. Moreover, the one or more processors can also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). For example, at least some of the operations can be performed by a group of computers (as examples of machines including processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an application program interface (API)).

[0107] The performance of certain of the operations can be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor- implemented modules can be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules can be distributed across multiple geographic locations.

[0108] Example

[0109] Example 1 is a method for converting API authorization for a UX session without requiring a second user login. The method includes receiving, at an authorization server from a third-party application developed by a third party, a request to access a user experience (UX) session on behalf of a user, the request including an access token previously granted to the third-party application by the authorization server in response to the user agreeing to allow the third-party application to perform actions on its own behalf; in response to receiving the request, and based on the access token, converting, by the authorization server, the access token to a single sign-on (SSO) link with a session token; and sending, by the authorization server, the SSO link with the session token to the third-party application developed by the third party, the SSO link causing the third-party application to redirect the user to the UX session corresponding to the SSO link.

[0110] In Example 2, the subject matter of Example 1 can optionally include wherein the access token includes embedded permissions defining resources to be accessed by the user and the third-party application and operations performable on the resources, the method further comprising mapping the embedded permissions to UX permissions.

[0111] In Example 3, the subject matter of any one of Examples 1-2 can optionally include wherein converting the access token to the SSO link with the session token includes encapsulating the UX permissions within the session token.

[0112] In Example 4, the subject matter of any one of Examples 1-3 can optionally include wherein the UX session is based on the UX permissions, the UX session providing access to user interfaces or services authorized by the UX permissions.

[0113] In Example 5, the subject matter of any one of Examples 1-4 can optionally include wherein the conversion eliminates a second factor authentication to access the UX session.

[0114] In Example 6, the subject matter of any one of Examples 1-5 can optionally include wherein converting the access token to the SSO link includes converting the access token to an SSO uniform resource locator (URL).

[0115] In Example 7, the subject matter of any one of Examples 1-6 can optionally include receiving an indication from the user to end the UX session; and in response to receiving the indication, redirecting the user back to the third-party application.

[0116] In Example 8, the subject matter of any one of Examples 1-7 can optionally include wherein the access token previously granted by the authorization server is an API authorization granted in response to an Open Authorization (OAuth) process.

[0117] Example 9 is a system for converting API authorization for a UX session without requiring a second user login. The system includes one or more hardware processors and a storage device storing instructions that, when executed by the one or more hardware processors, cause the one or more hardware processors to perform operations comprising: receiving, from a third-party application developed and hosted by a third party, a request to access a user experience (UX) session on behalf of a user, the request including an access token previously granted to the third-party application in response to the user agreeing to allow the third-party application to perform actions on behalf of the user; in response to receiving the request, and based on the access token, converting the access token to a single sign-on (SSO) link with a session token; and sending the SSO link with the session token to the third-party application developed by the third party, the SSO link causing the third-party application to redirect the user to the UX session corresponding to the SSO link.

[0118] In Example 10, the subject matter of Example 9 can optionally include: wherein the access token includes embedded permissions defining resources to be accessed by the user and the third-party application and operations performable on the resources, the method further comprising: mapping the embedded permissions to UX permissions.

[0119] In Example 11, the subject matter of any one of Examples 9-10 can optionally include: wherein converting the access token to the SSO link with the session token includes: encapsulating the UX permissions within the session token.

[0120] In Example 12, the subject matter of any one of Examples 9-11 can optionally include:

[0121] wherein the UX session is based on the UX permissions, the UX session providing access to user interfaces or services authorized by the UX permissions.

[0122] In Example 13, the subject matter of any one of Examples 10-12 can optionally include: wherein converting the access token to the SSO link includes: converting the access token to an SSO uniform resource locator (URL).

[0123] In Example 14, the subject matter of any one of Examples 9-13 can optionally include: receiving an indication from the user to end the UX session; and in response to receiving the indication, redirecting the user back to the third-party application.

[0124] Example 15 is a machine storage medium for converting API authorization for a UX session without requiring a second user login. The machine storage medium configures one or more processors to perform operations comprising: receiving, at an authorization server from a third-party application developed and hosted by a third party, a request to access a user experience (UX) session on behalf of a user, the request including an access token previously granted to the third-party application by the authorization server in response to the user agreeing to allow the third-party application to perform actions on behalf of the user; in response to receiving the request, and based on the access token, converting, by the authorization server, the access token to a single sign-on (SSO) link with a session token; and sending, by the authorization server, the SSO link with the session token to the third-party application developed by the third party, the SSO link causing the third-party application to redirect the user to the UX session corresponding to the SSO link.

[0125] In Example 16, the subject matter of Example 15 can optionally include wherein the access token includes embedded permissions defining resources to be accessed by the user and the third-party application and operations performable on the resources, the method further comprising mapping the embedded permissions to UX permissions.

[0126] In Example 17, the subject matter of any one of Examples 15-16 can optionally include wherein converting the access token to the SSO link with the session token includes encapsulating the UX permissions within the session token.

[0127] In Example 18, the subject matter of any one of Examples 15-17 can optionally include wherein the UX session is based on the UX permissions, the UX session providing access to user interfaces or services authorized by the UX permissions.

[0128] In Example 19, the subject matter of any one of Examples 15-18 can optionally include wherein converting the access token to the SSO link includes converting the access token to an SSO uniform resource locator (URL).

[0129] In Example 20, the subject matter of any one of Examples 15-19 can optionally include receiving an indication from the user to end the UX session; and in response to receiving the indication, redirecting the user back to the third-party application.

[0130] Some portions of this specification can be presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory such as a computer memory. These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others. As used herein, an "algorithm" is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities can take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is sometimes convenient to refer to these signals using words such as "data," "content," "bits," "values," "elements," "symbols," "characters," "terms," "numbers," "numerals," or the like. However, these words are merely convenient labels and are to be associated with appropriate physical quantities.

[0131] Unless specifically stated otherwise, discussions herein using words such as "processing," "computing," "calculating," "determining," "presenting," "displaying," or the like can refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or any suitable combination thereof), registers or other machine component(s), regardless of the specific type of computation or processing. Furthermore, unless specifically stated otherwise, the terms "a" or "an" are herein used to include one or more instances of whatever the noun is collecting (by default and / or the alternative). Finally, as used herein, the conjunction "or" refers to a non-exclusive "or," unless specifically stated otherwise.

[0132] While the overview of the subject matter has been described with reference to particular examples embodiments, various modifications and changes can be made to the embodiments described without departing from the broader scope of the inventive subject matter. For example, various embodiments or features can be mixed and matched by one of ordinary skill in the art to make other embodiments or features not specifically described herein. These embodiments of the inventive subject matter can be referred to herein, individually or collectively, by the term "application" merely for convenience and without intending to voluntarily limit the ambit of this application to a single application or inventive concept if there is more than one. The various embodiments can be combined in different ways to make other embodiments not specifically described herein.

[0133] The embodiments shown herein are believed to be sufficiently detailed to enable one skilled in the art to practice the teachings disclosed herein. Other embodiments can be derived from the embodiments shown by one skilled in the art without departing from the scope of the disclosure. Therefore, the "Detailed Description" should not be viewed as limiting the scope of the various embodiments and the scope of the claims should not be limited to the embodiments described herein.

[0134] Further, multiple instances of a resource, operation or structure described herein as a single instance can be provided. Boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and the same can be true of any particular illustrative configuration, together with its functionality across various illustrative configurations. Other, additional or fewer resources, operations, modules, engines and data stores can be provided. In general, structures and functionality presented as separate resources in the example configurations can be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource can be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within the scope of embodiments of the present application as expressed by the appended claims. Thus, the specification and drawings should be considered in an illustrative rather than a restrictive sense.

Claims

1. A method of converting API authorization to access a function or service of a network system, comprising: receiving, at an API of the network system, a request from a third-party application developed by a third party to access an internal service of the network system that is not supported by the third-party application on behalf of a user, and the request includes an access token previously granted to the third-party application by an authorization server of the network system in response to the user agreeing to allow the third-party application to perform an action on behalf of the user, wherein the access token belongs to a first authorization domain and is applicable to access to a public API of the network system; in response to receiving the request, and based on the access token, converting, by the authorization server of the network system, the access token to an internal access token for accessing the internal service by resolving the access token to obtain permission information for the public API in the first authorization domain, mapping the permission information for the public API to internal service permissions for the internal service in a second authorization domain, and generating the internal access token encapsulating the internal service permissions; and receiving, at the API of the network system, an internal service response, and forwarding the internal service response as an API response to the third-party application developed by the third party.

2. The method of claim 1, wherein, The permission information of the first authorization domain defines resources to be accessed and operations that can be performed on the resources for the user and the third-party application.

3. The method of claim 1, further comprising: sending, by the API of the network system, a request containing an access token to the authorization server of the network system; and generating, by the authorization server of the network system, the internal access token. The conversion eliminates a second factor authentication to access the internal service.

4. The method of claim 1, wherein, The access token previously granted by the authorization server is an API authorization granted in response to an Open Authorization (OAuth) process.

5. The method of claim 1, wherein, 6. A system of converting API authorization to access a function or service of a network system, comprising: one or more hardware processors; and a storage device storing instructions that, when executed by the one or more hardware processors, cause the one or more hardware processors to perform the method of any one of claims 1-5.

7. A machine-readable storage medium storing instructions that, when executed by one or more processors of a machine, cause the one or more processors to perform the method of any one of claims 1-5. ​ ​

Images