Preventing cookie theft using co-located secondary devices

Abstract

A method includes receiving, by a service provider platform, a service request from a first client device and a first instance of an authentication token associated with the service request and generated by the first client device. The service provider platform can further receive, from a second client device, a second instance of the authentication token associated with the service request and generated by the first client device. In response to determining that the first instance of the authentication token matches the second instance of the authentication token, the service request is processed by the service provider platform.

Description

Technical Field

[0001] This disclosure generally relates to a technique for protecting user devices from cookie theft. More specifically, this disclosure relates to using a shared secondary device to prevent cookie theft. Background Technology

[0002] A Hypertext Transfer Protocol (HTTP) cookie (hereinafter referred to as a "cookie") can refer to a file stored on a client device that contains a certain amount of data specific to a particular client device or application (e.g., a browser). Existing service provider platforms (e.g., content sharing platforms, financial platforms, e-commerce platforms, etc.) are able to use cookies during a session to authorize user accounts or client device applications. For example, a user can log in to a service provider platform using user account information (e.g., username and password). The service provider platform can authorize user accounts and can send cookies to client devices. Any subsequent requests to the service provider platform during a session can include cookies in the request, where cookies can be used to authorize the services requested by the user account.

[0003] Cookie theft occurs when a third party copies and uses cookies to impersonate a user on a client device. For example, cookie theft can occur when a user accesses a service provider's platform via an unprotected or public Wi-Fi network. Using cookies, third parties may perform malicious actions, such as posting fake content in the user's name or transferring funds from the user's account. Summary of the Invention

[0004] The following is a simplified overview of various aspects of this disclosure in order to provide a basic understanding of such aspects. This overview is not a comprehensive overview of all anticipated aspects, and is neither intended to identify major or key elements nor to depict the scope of such aspects. Its purpose is to present some concepts of this disclosure in a simplified form as a prelude to the more detailed description that follows.

[0005] In one aspect of this disclosure, a method includes a server receiving a service request from a first client device and receiving a first instance of an authentication token associated with the service request and generated by the first client device. The server may further receive a second instance of the authentication token associated with the service request and generated by the first client device from a second client device. In response to determining that the first instance of the authentication token matches the second instance of the authentication token, the server may process the service request.

[0006] A further aspect of this disclosure provides a system including: a memory; and a processing device coupled to the memory, the processing device performing a method according to any aspect or embodiment described herein.

[0007] A further aspect of this disclosure provides a method comprising generating a first instance of an authentication token and a second instance of an authentication token by a first client device. The first client device may send a service request and the first instance of the authentication token to a server. The first client device may further send the second instance of the authentication token to a second client device. The first client device may further receive from a content sharing platform a response indicating that the server accepts the service request, the response indicating that the first instance of the authentication token sent by the first client device to the server matches the second instance of the authentication token sent by the second client device to the service provider platform.

[0008] An optional feature of one aspect can be combined with other aspects where appropriate. Attached Figure Description

[0009] The various aspects and embodiments of this disclosure will be more fully understood from the detailed description given below and the accompanying drawings, which are provided in accordance with the various aspects and embodiments of this disclosure. However, this disclosure should not be construed as limiting the disclosure to any particular aspect or embodiment, but is intended for explanation and understanding only.

[0010] Figure 1 The illustration shows an example of a system architecture according to one embodiment of the present disclosure, which enables media features provided on a first client device to be presented on a second client device.

[0011] Figure 2 An interactive diagram is depicted according to an embodiment of a method for authenticating a service request initiated by a primary client device using a secondary client device.

[0012] Figure 3 An interaction diagram is depicted according to an embodiment of another method for authenticating a service request initiated by a primary client device using a secondary client device.

[0013] Figure 4 A flowchart is depicted for a method for authenticating a service request initiated by a primary client device according to one embodiment of the present disclosure.

[0014] Figure 5 A flowchart is depicted for a method for initiating a service request that requires authentication by an authentication device, according to one embodiment of the present disclosure.

[0015] Figure 6 A block diagram depicts an example computing device operating according to one or more aspects of this disclosure. Detailed Implementation

[0016] This disclosure provides a mechanism for preventing cookie theft. A content-sharing platform (or any other platform providing services to users) can use cookies to authorize service requests from a user's account or an application on a client device. The client device can be a personal computer (PC), laptop, smartphone, tablet, etc. Service requests can include login requests, content upload requests, content search requests, content consumption requests, purchase requests, and so on. To prevent third parties from copying cookies and using them to impersonate users on client devices, existing systems may use secondary service verification methods, such as two-factor authentication, to authenticate certain service requests (e.g., login and purchase requests). Two-factor authentication may involve the content-sharing platform sending a verification code to another application associated with the user—such as an email address or phone number. The user can then send the received verification code to the content-sharing platform to authenticate pending service requests. However, using two-factor authentication is both time-consuming and cumbersome, as users may need to log out (or switch) the content-sharing platform's application or website to retrieve the verification code. This results in undesirable delays, potentially consuming additional time and computing resources if used for every service request, and causing inconvenience to the user.

[0017] Various aspects of this disclosure address the aforementioned and other deficiencies by providing a mechanism that enables physically co-located secondary client devices (e.g., within a relatively short or predetermined distance, within a shared line of sight, etc.) to function as authentication devices capable of authenticating all or some types of service requests initiated by the primary client device to the service provider platform. According to some aspects of this disclosure, the primary and secondary client devices can register with the service provider platform. Both client devices can be associated with the same user account. For example, using the primary client device, a user can access their user account by providing user account information such as a username and password. Once accessed, the user can register the primary client device with the user account using, for example, client device identification data (e.g., device serial number, identifier, Internet Protocol (IP) address, location data, or other identification data associated with the primary client device). Similarly, a user can register a secondary client device with the user account by providing user account information to the service provider platform via the secondary client device. In some embodiments, in response to registration, the service provider platform can send one or more cryptographic keys, such as one or more public keys and / or one or more private keys, to the primary and / or secondary client devices. The cryptographic keys can be used to verify the identity of the respective client devices. The primary client device and the secondary client device can each receive different sets of cryptographic keys.

[0018] The primary client device can then request the service provider platform to use the secondary client device as the authentication device. The authentication device can be a physically co-located secondary client device used to authenticate service requests originating from the primary client device. Using a co-located secondary device to authenticate service requests originating from the primary client device prevents remote third parties from impersonating users of the primary client device, as the third party must be physically located near the primary client device. In some embodiments, the types of service requests requiring authentication by the authentication device (e.g., the secondary client device) can be predefined. For example, in response to user input, the service provider platform can enable secondary device verification only for upload content requests and purchase requests.

[0019] In some implementations, the primary client device can issue a service request that requires authentication from the secondary device to generate an authentication token. The authentication token may include a random number, a random string, a cryptographic signature, a key-value pair, a hash value, a certificate, etc. The primary client device can then send the service request and authentication token to the service provider platform. In some embodiments, the primary client device may attach the authentication token to the service request. In other embodiments, the primary client device may send the service request and authentication token in two separate transmissions. The primary client device may further send the authentication token to the secondary client device (e.g., the authentication device). In some embodiments, the primary client device may use short-range communication (SMR) technology to send the authentication token to the secondary client device. SMR technology can be used to establish physical co-location between the primary and secondary client devices. In some embodiments, SMR technology may include, for example, wireless technologies such as peer-to-peer (P2P). Wi-Fi Direct (Wi-Fi P2P), infrared, or ultrasonic technologies can be used. In some embodiments, short-range communication technologies may include wired technologies such as cable connections (e.g., Universal Serial Bus (USB) connectors, Ethernet connectors, lighting connectors, etc.). Once received, the secondary client device can send the authentication token to the service provider platform. In some embodiments, the secondary client device may first encrypt the authentication token, or sign the authentication token using a private key and / or public key received from the service provider platform, to verify the identity of the secondary client device.

[0020] The service provider platform can receive authentication tokens from two client devices, optionally using private and / or public keys to decrypt or verify the authenticity of the client devices, and compare the authentication token received from the primary client device with the authentication token received from the secondary client device. In response to determining that the two authentication tokens match (e.g., a transmitted number or string received from the primary client device is the same as a transmitted number or string received from the secondary client device), the service provider platform can authorize or process the service request received from the primary client device. In some embodiments, the secondary client device can act as a background process (e.g., a process executed without user intervention) to relay (e.g., receive and send) the authentication tokens. Therefore, each service request initiated by the user can be processed with the additional security provided by authentication via the secondary device, and with little or no additional latency.

[0021] In some embodiments, the physical co-location of two client devices can be established using location data—such as, for example, Internet Protocol (IP) addresses, Media Access Control (MAC) addresses, Global Positioning System (GPS) data, etc. Specifically, the primary and secondary client devices can send authentication tokens with corresponding location data attached to them to the service provider platform. Upon receiving the authentication tokens, the service provider platform can compare the location data of each token and determine whether the location data matches (e.g., determining whether the IP address attached to one authentication token corresponds to the IP address attached to the other authentication token). In response to determining that the two authentication tokens match and that the location data attached to each authentication token also matches, the service provider platform can authorize or process the service request received from the primary client device.

[0022] Therefore, aspects and implementations of this disclosure provide user protection against third parties who attempt to impersonate users by using stolen cookies to verify service requests via a shared secondary client device. The techniques disclosed herein are advantageous because they overcome the limited capabilities and functionality currently available to users to prevent unauthorized service requests from their accounts. Instead, users are now able to securely make service requests to service provider platforms with little or no additional delay and without generating prompts requiring user input (e.g., no need for users to manually enter any verification codes on any user device). Thus, the techniques disclosed herein enable users to have more secure sessions with service provider platforms and reduce the time and computing resources otherwise consumed in supporting users switching between different applications or websites to retrieve verification codes, generating prompts to request user input of verification codes, and monitoring and processing user input.

[0023] For simplicity and brevity, the embodiments of this disclosure refer to the authentication of service requests on content-sharing platforms. However, the teachings of this disclosure can be applied to any service provider platform that utilizes cookies (or other authorized data), such as, for example, financial platforms, banking platforms, social media platforms, e-commerce platforms, etc.

[0024] Figure 1 An example of a system architecture 100 according to one embodiment of the present disclosure is illustrated. System architecture 100 (also referred to herein as the “system”) includes a first client device 110, a second client device 120, a server 130, a network 150, and a data warehouse 135.

[0025] Network 150 may include public networks (e.g., the Internet), private networks (e.g., local area networks (LANs) or wide area networks (WANs)), wired networks (e.g., Ethernet), wireless networks (e.g., 802.11 networks or Wi-Fi networks), cellular networks (e.g., long-term evolution (LTE) networks), routers, hubs, switches, server computers, and / or combinations thereof.

[0026] Data repository 135 may be a persistent storage device capable of storing content items (such as media items) and data structures for tagging, organizing, and indexing content items. Data repository 135 may be hosted by one or more storage devices—such as main memory, magnetic or optical storage-based disks, tape or hard disk drives, NAS, SAN, etc. In some embodiments, data repository 135 may be a network-attached file server, while in other embodiments, data repository 135 may be some other type of persistent storage, such as an object-oriented database, relational database, etc., which may be hosted by service provider platform 130 or one or more different machines coupled to service provider platform 130. In some embodiments, data repository 135 may be coupled to service provider platform 130 via network 150.

[0027] Client devices 110 and 120 may each include a computing device, such as a personal computer (PC), laptop computer, mobile phone, smartphone, tablet computer, netbook computer, network-connected television, etc. In some embodiments, client devices 110 and 120 may also be referred to as "user devices". In some embodiments, each client device 110 and 120 may include a media player 112 (or media viewer), a link module 112, and a token module 116.

[0028] In some embodiments, media player 112 may be an application that allows users to play back, view, or upload content—such as images, video items, web pages, documents, audio items, etc. For example, media player 112 may be a web browser that can access, retrieve, render, or navigate content provided by a web server (e.g., web pages such as Hypertext Markup Language (HTML) pages, digital media items, etc.). Media player 112 may render, display, or present content (e.g., web pages, media viewers) to a user. Media player 112 may also include an embedded media player (e.g., a web page that provides information about products sold by an online merchant) embedded in a web page (e.g., a web page that provides information about products sold by an online merchant). Media player 112 may be a standalone application (e.g., a mobile application or a native application) that allows users to play back digital media items (e.g., digital video items, digital images, e-books, etc.). According to various aspects of this disclosure, media player 112 may be a content sharing platform application that allows users to record, edit, and / or upload content for sharing on a content sharing platform. Thus, media player 112 may be provided to client devices 110, 120 by service provider platform 130. For example, media player 112 may be an embedded media player embedded in a webpage provided by service provider platform 130. In another example, media player 112 may be an application downloaded from service provider platform 130. For simplicity and brevity, embodiments of this disclosure refer to media player 112 as an application for communicating with a content sharing platform (e.g., sending service requests, receiving content, etc.). However, in other embodiments, media player 112 may be one or more applications that enable communication with other types of service provider platforms—such as, for example, financial platforms, banking platforms, social media platforms, e-commerce platforms, etc.

[0029] In some embodiments, the first client device 110 may use the link module 114 to couple (e.g., pair) and / or communicate with one or more second client devices 120. In some embodiments, the coupling may be based on short-range communication technology, and the client devices 110 and 120 may be physically co-located (e.g., within a relatively short or predetermined distance, within a shared line of sight, etc.). In some embodiments, the first client device 110 and the second client device 120 may include wireless technologies for establishing short-range coupling between the first client device 110 and the second client device 120. Wireless communication technologies may include peer-to-peer (P2P). Wi-Fi Direct (Wi-Fi P2P), infrared, ultrasonic, or other technologies. In some embodiments, the first client device 110 and the second client device 120 may include wired technologies for establishing short-range coupling between the first client device 110 and the second client device 120. Wired communication technologies may include cable connections, such as, for example, Universal Serial Bus (USB) connectors, Ethernet connectors, lighting connectors, or any other capable connectors.

[0030] In some embodiments, linking module 114 can generate location data that service provider platform 130 can use to establish physical co-location of first client device 110 and second client device 120. For example, linking module 114 (for each client device 110, 120) can send location data associated with the respective client device 110, 120 to service provider platform 120. Location data may include Internet Protocol (IP) addresses associated with client devices 110, 120, Media Access Control (MAC) addresses associated with client devices 110, 120, geographic location data (e.g., Global Positioning System (GPS) data, mobile phone tower data, Wi-Fi access point data, etc.), any other location data, or any combination thereof. In some embodiments, location data may be appended to other data, such as authentication tokens or service requests. In other embodiments, location data may be sent to service provider platform 130 independently of other data. To establish physical co-location, service provider platform 130 can compare the location data received from client devices 110 and 120 and determine whether the location data matches (e.g., the location data indicates that client devices 110 and 120 are very close). For example, the service provider platform 130 can determine whether the IP address associated with the first client device 110 is the same as the IP address associated with the second client device 120 (e.g., if both client devices are connected to the same network at the same time).

[0031] Token module 116 can be used to generate one or more authentication tokens. Authentication tokens can be generated in response to service requests made to service provider platform 130 and can be used to authenticate service requests by using a client device (e.g., a client device physically co-located with the client device requesting the service). Service requests can be any type of request made by client devices 110, 120 to service provider platform 130, such as login requests, content upload requests, content search requests, content consumption requests, content upvote requests, content dislike requests, content comment requests, settings change requests, personal details change requests, purchase requests, etc. In some embodiments, authentication tokens can be randomly generated numbers (e.g., 64-bit numbers, 128-bit numbers, etc.) or strings. In other embodiments, authentication tokens can be cryptographic signatures, key-value pairs, hash values, certificates, etc.

[0032] The authentication token can be sent from client devices 110 and 120 to service provider platform 130, respectively. In some embodiments, client devices 110 and 120 and / or service provider platform 130 can perform an authentication process on the received authentication token by decrypting the authentication token, determining the cryptographic signature of the authentication token, and / or performing any other process associated with the authentication token, as will be discussed in more detail below. In response to authenticating the authentication token, service provider platform 130 can accept or execute the requested service request. For example, service provider platform 130 can initiate or continue playback of the requested digital media item, allow the upload of the requested digital media item, etc.

[0033] In some embodiments, the types of service requests requiring authentication (by the authentication client device) can be predefined. For example, a user can use media player 112 to select the types of service requests that require authentication by a physically co-located authentication device, where all other requests may not require authentication by the authentication device. For example, in response to user input, authorization data service 124 can enable authentication device authentication only for login requests, content upload requests, and purchase requests.

[0034] In some embodiments, the service provider platform 130 may include one or more computing devices (such as rack servers, router computers, server computers, personal computers, mainframe computers, laptop computers, tablet computers, desktop computers, etc.), data warehousing (e.g., hard drives, storage, databases) that can be used to provide users with access to media items or to provide users with data warehousing for media items, networks, software components, or hardware components. For example, the service provider platform 130 may allow users to consume, upload, search, approve (“like”), disapprove (“dislike”), or comment on media items. The service provider platform 130 may also include websites (e.g., web pages) or application backend software that can be used to provide users with access to media items.

[0035] In some embodiments of this disclosure, "user" may refer to a single individual. However, other embodiments of this disclosure encompass "user" as an entity controlled by a group of users and / or automated sources. For example, a single set of users united as a community in a social network can be considered a "user." In another example, an automated consumer can be an automated ingestion pipeline of a service provider platform 130, such as a topic channel.

[0036] Service provider platform 130 may include multiple channels. Channels may be data content available from public sources or data content with public topics, themes, or substance. Data content may be digital content selected by users, digital content available to users, digital content uploaded by users, digital content selected by content providers, digital content selected by broadcasters, etc. For example, channel X may include videos Y and Z. Channels may be associated with an owner, who is a user who can perform actions on the channel. Different activities may be associated with channels based on the owner's actions—such as the owner making digital content available on the channel, the owner selecting (e.g., liking) digital content associated with another channel, the owner commenting on digital content associated with another channel, etc. Activities associated with a channel may be collected in the channel's activity feed. Users other than channel owners can subscribe to one or more channels they are interested in. The concept of "subscription" may also be referred to as "like," "follow," "add friend," etc.

[0037] Once a user subscribes to a channel, information about active feeds from that channel can be presented to the user. If a user subscribes to multiple channels, the active feeds from each channel can be combined into a joint active feed. Information from the joint active feed can then be presented to the user. Channels may have their own feeds. For example, when navigating to a channel's homepage on a service provider platform, feed items generated by that channel can be displayed on the channel's homepage. Users can have joint feeds, which are feeds that include at least a subset of content items from all the channels the user subscribes to. Joint feeds can also include content items from channels the user does not subscribe to. For example, a service provider platform 130 or other social networks can insert recommended content items into a user's joint feed, or they can insert content items associated with the user's relevant links into the joint feed.

[0038] Each channel may include one or more media items. Examples of media items may include, but are not limited to, digital videos, digital movies, digital photos, digital music, audio content, melodies, website content, social media updates, ebooks, e-magazines, digital newspapers, digital audiobooks, e-journals, web blogs, Real Simple Aggregator (RSS) feeds, e-comic books, software applications, etc. In some embodiments, media items are also referred to as content or content items.

[0039] For the sake of brevity and simplicity, and not as a limitation, video items, audio items, or game items are used throughout this document as examples of media items. As used herein, “media,” “media item,” “online media item,” “digital media,” “digital media item,” “content,” and “content item” can include electronic files that can be executed or loaded using software, firmware, or hardware configured to present digital media items to an entity. In one embodiment, service provider platform 130 may use data repository 106 to store media item 132. In another embodiment, service provider platform 130 may use data repository 135 to store video items or fingerprints as electronic files in one or more formats.

[0040] In some embodiments, a media item is a video item. A video item is a set of consecutive video frames (e.g., image frames) representing a moving scene. For example, a series of consecutive video frames can be captured sequentially or reconstructed later to produce an animation. Video items can be presented in various formats, including but not limited to analog, digital, two-dimensional, and three-dimensional video. Furthermore, a video item can include a movie, video clip, or any set of animated images to be displayed sequentially. Additionally, a video item can be stored as a video file comprising video and audio components. Video components can refer to video data in a video encoding format or an image encoding format (e.g., H.264 (MPEG-4 AVC), H.264 MPEG-4 Part 2, Graphics Interchange Format (GIF), WebP, etc.). Audio components can refer to audio data in an audio encoding format (e.g., Advanced Audio Coding (AAC), MP3, etc.). It can be noted that a GIF can be saved as an image file (e.g., a .gif file) or as a series of images in an animated GIF (e.g., GIF89a format). It can be noted that H.264 can be a video encoding format, which is a block-oriented, motion-compensated video compression standard used for, for example, the recording, compression, or distribution of video content.

[0041] In some embodiments, a media item may be streamed—such as as a live stream—to one or more of client devices 110, 120. It should be noted that “streamed” or “broadcast” refers to the transmission or broadcast of content, such as a media item, wherein a received portion of the media item may be played back by the receiving device immediately upon receipt or while other portions of the media content are being transmitted (within technical limitations), and the entire media item has not yet been received by the receiving device. “Stream” can refer to content that is streamed or broadcast, such as a media item. A live streaming media item can refer to the live playback or transmission of a live event, wherein, when the event occurs at the receiving device, the media item is transmitted at least partially concurrently, and wherein the media item is not fully available.

[0042] In some embodiments, the service provider platform 130 may allow users to create, share, view, or use playlists containing media items. A playlist is a collection of media items configured to play one after another in a specific order without any user interaction. In some embodiments, the service provider platform 130 may maintain playlists on behalf of users. In some embodiments, playlist features of the service provider platform 130 allow users to group their favorite media items together in a single location for playback. In some embodiments, the service provider platform 130 may send media items on the playlist to client devices 110, 120 for playback or display. For example, a media viewer 112 may be used to play media items on the playlist in the order they are listed on the playlist. In another example, a user may switch between media items on the playlist. In yet another example, a user may wait for the next media item on the playlist to play or select a specific media item on the playlist for playback.

[0043] In some embodiments, users can access content on the sharing platform 130 through a user account. Users can access (e.g., log in) a user account by providing user account information (e.g., username and password) via an application on client devices 110, 120 (e.g., media viewer 112). In some embodiments, a user account may be associated with a single user. In other embodiments, a user account may be a shared account (e.g., a family account shared by multiple users) (also referred to herein as a "shared user account"). A shared account may have multiple user profiles, each associated with a different user. Multiple users can log in to the shared account using the same account information or different account information. In some embodiments, multiple users of a shared account can be distinguished based on different user profiles of the shared account.

[0044] In some embodiments, the authorization data service 134 may authorize a user account to obtain the requested content. In some embodiments, the authorization data service 134 may authorize a user account (e.g., a client device associated with the user account) to access the requested content, authorize the delivery of the requested content to the client device, or both. Authorization of user account access to the requested content may involve authorizing what content to access and who is authorized to access the content. Authorization of content delivery may involve authorizing how the content is delivered.

[0045] In some embodiments, the authorization data service 134 may use user account information to authorize user accounts. In some embodiments, authentication tokens associated with client devices 110, 120, or media player 112 (e.g., session-based authentication tokens, content-based authentication tokens, etc.) may be used to authorize user accounts and / or play back requested content. In some embodiments, the authorization data service 134 is part of the service provider platform 130. In some embodiments, the authorization data service 134 is not part of the service provider platform 130 and is an external service, such as an authorization service provided by a third party (e.g., a trusted authentication service).

[0046] Although embodiments of this disclosure are discussed in relation to social network sharing of content items on a content sharing platform and facilitating service provider platform 130, embodiments can also be generally applied to any type of network, content delivery platform, or service provider platform that provides connectivity between users. Implementations of this disclosure are not limited to content sharing platforms that offer channel subscriptions to users.

[0047] Further, as described above, users can be given control over whether and when the systems, programs, or features described herein can collect user information (e.g., information about the user's social networks, social actions or activities, occupation, user preferences, or the user's current location), and whether content or communications can be sent to the user from the server. Additionally, some data may be processed in one or more ways before being stored or used to remove personally identifiable information. For example, a user's identity may be processed to the point that it is impossible to determine the user's personally identifiable information, or, in the case of location information, the user's geographic location may be generalized (e.g., down to the city, zip code, or state level), making it impossible to determine the user's specific location. Therefore, users can have control over what information about themselves is collected, how that information is used, and what information is provided to them.

[0048] Figure 2 This is a diagram illustrating operations for authenticating a service request initiated by a primary client device using a secondary client device, according to embodiments of this disclosure. System 200 may include... Figure 1 The system architecture has 100 similar components. It can be noted that... Figure 1 The components can be used to help describe Figure 2For illustrative and non-limiting purposes, operation of system 200 is described as being performed via data service 124 of the authorized service provider platform 130, primary client device 205, and secondary client device 210. In some embodiments, primary client device 205 may be similar to or the same as client device 110, and secondary client device 210 may be similar to or the same as client device 120. Thus, unless otherwise described, operation of system 200 may be performed by any component of client devices 110, 120—such as, for example, media player 112, link module 114, and / or token module 116. For illustrative and non-limiting purposes, operation of system 200 is described as being performed via data service 124 of the authorized service provider platform 130, primary client device 205, and secondary client device 210. Figure 2 The described operations are shown as being executed sequentially. It can be noted that these operations can be executed in any order, and any operation can be executed concurrently with one or more other operations. In some implementations, the same, different, fewer, or more operations can be executed in any order.

[0049] In operation 212, the primary client device 205 may send a registration request to the Authorized Data Service 124 to register the primary client device 205 with a user account associated with a content sharing platform (e.g., service provider platform 130). For example, a user may access a user account by providing user account information such as a username and password through a media viewer application (e.g., media viewer 112) on the primary client device 205. Once accessed (e.g., by an authorized user account on the content sharing platform), media viewer 112 may present a device registration button. The user may select the device registration button to send a registration request to register the primary client device 205 with the content sharing platform. In some embodiments, the registration request may include client device identification data that the Authorized Data Service 124 can use to register the primary client device 205. The client device identification data may include a device serial number, identification number, IP address, location data, or other identification data associated with the primary client device 205. In some embodiments, in response to the registration request, the Authorized Data Service 124 may send a cookie to the primary client device 205. The primary client device 205 may then use the cookie to prove registration during subsequent requests to the content sharing platform. In some embodiments, in response to a registration request, the Authorization Data Service 124 may send one or more cryptographic keys, such as one or more public keys and / or one or more private keys, certificates, etc., to the primary client device 205, which can be used by the content sharing platform to verify the identity of the primary client device 205.

[0050] In operation 214, secondary client device 210 may send a registration request to authorized data service 124 to register secondary client device 210 with a user account associated with a content sharing platform (e.g., service provider platform 130). Registering secondary client device 210 can be similar to registering primary client device 205. Specifically, a user can access a user account by providing user account information such as username and password using a media viewer application (e.g., media viewer 112) on secondary client device 210. Once accessed (e.g., authorized user account by the content sharing platform), media viewer 112 may present a device registration button. The user can select the device registration button to send a registration request to register secondary client device 210 with the content sharing platform. In some embodiments, the registration request may include client device identification data that authorized data service 124 can use to register secondary client device 210. Client device identification data may include a device serial number, identifier, IP address, location data, or other identification data associated with secondary client device 210. In some embodiments, in response to the registration request, authorized data service 124 may send a cookie to secondary client device 210. Secondary client device 210 can then use cookies to prove registration during subsequent requests to the content sharing platform. In some embodiments, in response to a registration request, the authorization data service 124 may send one or more cryptographic keys, such as one or more public keys and / or one or more private keys, certificates, etc., to secondary client device 210, which can be used by secondary client device 210 to sign (or add to) messages sent to the content sharing platform to allow the content sharing platform to verify the identity of secondary client device 210.

[0051] In operation 216, the primary client device 205 sends a request to the authorization data service 124 to enable the secondary client device 210 as an authentication device. The authentication device can be a physically co-located secondary device used to authenticate service requests issued by the primary client device 205. Service requests can be any type of request for a specific service issued by the client device to the content sharing platform. In some embodiments, the types of service requests requiring authentication (via the authentication device) can be predefined. For example, in response to user input, the authorization data service 124 can enable secondary device authentication only for login requests, content upload requests, and purchase requests.

[0052] In operation 218, the primary client device 205 sends a service request to the authorized data service 124. For example, the primary client device 205 may send a request to the authorized data service 124 to upload content to a channel associated with a user account.

[0053] In operation 220, in response to determining that the service request in operation 216 requires secondary device authentication, the primary client device 205 generates an authentication token. The authentication token can be a randomly generated number (e.g., a 64-bit number, a 128-bit number, etc.), a string, a cryptographic signature, a key-value pair, a hash value, a certificate, etc. In some embodiments, the primary client device 205 can determine that a service request requires secondary device authentication by scanning a data structure that lists the types of service requests requiring secondary device authentication and determining that the service request type is included in the list. In some embodiments, the primary client device 205 can receive an indication (e.g., an alarm) that secondary device authentication is required from the authorization data service 124.

[0054] In operation 222, the primary client device 205 sends a first instance of the authentication token to the authorization data service 124. The first instance of the authentication token may be sent as unencrypted data or may be encrypted by the primary client device 205. In some embodiments, the primary client device 205 may attach a private and / or public key, certificate, cookie, or any other identifying data capable of identifying the primary client device 205 to the authorization data service 124. In some embodiments, the primary client device 205 may attach location data, such as IP address, MAC address, GPS data, etc., to the first instance of the authentication token. The authorization data service 124 may use the location data to verify that the primary client device 205 and the secondary client device 210 are physically co-located.

[0055] In some embodiments, a first instance of the authentication token may be attached to a service request. For example, in response to receiving user input requesting a service request for a content sharing platform, the primary client device 205 may generate a service request, generate an authentication token, attach a first instance of the authentication token to the service request, and send the attached service request to the authorization data service 124.

[0056] In operation 224, the primary client device 205 sends a second instance of the authentication token to the secondary client device 210. The second instance of the authentication token may be sent as unencrypted data or may be encrypted by the primary client device 205. Since authentication is based on the physical co-location of the secondary client device 210 and the primary client device 205, in some embodiments, the primary client device 205 may use short-range communication technologies to send the second instance of the authentication token to the secondary client device 210. For example, the primary client device 205 may use short-range wireless communication technologies, such as, for example, P2P. Wi-Fi Direct (Wi-Fi P2P), infrared, ultrasonic, or other short-range communication technologies can be used to send a second instance of the authentication token to the secondary client device 210. In some embodiments, wired communication technologies, such as cable connections (e.g., Universal Serial Bus (USB) connectors, Ethernet connectors, lighting connectors, or any other capable connectors), can be used to send the second instance of the authentication token from the primary client device 205 to the secondary client device 210. In some embodiments, the primary client device 205 can use more than one type of short-range communication technology to send the authentication token to the secondary client device 210. For example, the primary client device 205 may first attempt to use... The technology sends the authentication token to the secondary client device 210, and in response to a failed attempt, the primary client device 205 can then attempt to send a second instance of the authentication token to the secondary client device 210 using infrared technology. The type of short-range communication technology used, the priority of each short-range communication technology to be used, and the number of attempts for each type of short-range communication technology can be configured by the client device (e.g., via user settings of a user account) or by the content sharing platform.

[0057] In operation 226, the secondary client device 210 sends a second instance of the authentication token to the authorization data service 124. In some embodiments, before sending the second instance of the authentication token, the secondary client device 210 confirms its co-location with the primary client device 205. In some embodiments, it can use... (For example, using discovery features to determine if the primary client device 205 is within range, using pairing features, etc.), using an ultrasonic audio modem (e.g., using the client device's speaker and microphone to transmit data to establish co-location), using shared IP detection (e.g., determining if both the primary client device 205 and the secondary client device 210 are using the same IP address), using geolocation data (e.g., Global Positioning System (GPS) data, mobile phone tower data, Wi-Fi access point data, etc.), using a wired connection, etc., to confirm co-location. A second instance of the authentication token may be sent as unencrypted data or may be encrypted by the secondary client device 210. In some embodiments, the secondary client device 210 may attach a private key and / or public key, certificate, cookie, or any other identifying data capable of identifying the secondary client device 205 to the second instance of the authentication token to authorize data service 124. In some embodiments, the secondary client device 210 may attach location data, such as IP address, MAC address, GPS data, etc., to the second instance of the authentication token. Location data can be used by the authorized data service 124 to verify that the primary client device 205 and the secondary client device 210 are physically co-located.

[0058] In operation 228, the authorization data service 124 compares (e.g., after decrypting received messages) a first instance and a second instance of authentication tokens received from each client device and determines whether the instances of authentication tokens match. For example, the authorization data service 124 may determine whether a number or string received from the primary client device 205 is the same as a number or string received from the secondary client device 210, whether the certificates received from each client device match, etc. In some embodiments, the authorization data service 124 may first decrypt one or both authentication tokens to determine the cryptographic signature of the authentication token, and / or perform any other processes associated with the authentication token. In embodiments where the instances of authentication tokens do not match, the authorization data service 124 may reject pending service requests.

[0059] At operation 230, the authorization data service 124 may optionally determine that the primary client device 205 and the secondary client device 210 are physically co-located. In some embodiments, the authorization data service 124 may determine physical co-location by using location data attached to authentication tokens received from the primary client device 205 and the secondary client device 210. For example, the authorization data service 124 may compare the location data attached to each respective token and determine whether the IP address, MAC address, or GPS data attached to the authentication token received from the primary client device 205 matches, respectively, the IP address, MAC address, or GPS data attached to the authentication token received from the secondary client device 210. In embodiments where the location data does not match, the authorization data service 124 may reject pending service requests. Note that operation 230 is optional because in other embodiments, physical co-location of client devices 205, 210 can be established by receiving an authentication token from secondary client device 210, since in these other embodiments, secondary client device 210 is configured to send an authentication token only when it confirms co-location with primary client device 205 (this can be confirmed, for example, if secondary client device 210 is capable of communicating with primary client device 205 using short-range communication technology).

[0060] In operation 232, the authorized data service 124 authorizes service requests. For example, the authorized data service 124 processes pending service requests received from the primary client device 205.

[0061] Figure 3 This is another diagram illustrating operations for authenticating service requests initiated by a primary client device using a secondary client device, according to embodiments of this disclosure. System 300 may include... Figure 1 The system architecture has 100 similar components. It can be noted that... Figure 1 The components can be used to help describe Figure 3 For illustrative and non-limiting purposes, operation of system 300 is described as being performed via data service 124 of the authorized service provider platform 130, primary client device 305, and secondary client device 310. In some embodiments, primary client device 305 may be similar to or the same as client device 110, and secondary client device 310 may be similar to or the same as client device 120. Thus, unless otherwise described, operation of system 300 may be performed by any component of client devices 110, 120—such as, for example, media player 112, link module 114, and / or token module 116. For illustrative and non-limiting purposes, relative to... Figure 3 The described operations are shown as being executed sequentially. It can be noted that these operations can be executed in any order, and any of these operations can be executed concurrently with one or more other operations. In some implementations, the same, different, fewer, or more operations can be executed in any order.

[0062] In operation 312, the primary client device 305 may send a registration request to the authorized data service 124 to register the primary client device 305 with an associated content sharing platform (e.g., service provider platform 130). The registration request may include client device identification data that the authorized data service 124 can use to register the primary client device 305. In some embodiments, in response to the registration request, the authorized data service 124 may send cookies, one or more cryptographic keys—such as one or more public keys and / or one or more private keys, certificates, etc.—to the primary client device 305.

[0063] In operation 314, secondary client device 310 may send a registration request to authorized data service 124 to register secondary client device 310 with an associated content sharing platform (e.g., service provider platform 130). Registering secondary client device 310 can be similar to registering primary client device 305. In some embodiments, in response to the registration request, authorized data service 124 may send cookies, one or more cryptographic keys, such as one or more public keys and / or one or more private keys, certificates, etc., to secondary client device 310.

[0064] At operation 316, the primary client device 305 sends a request to the authorization data service 124 to enable the secondary client device 310 as an authentication device. In some embodiments, the type of service request requiring authentication (through an authentication device) can be predefined.

[0065] In operation 318, the primary client device 305 sends a service request to the authorized data service 124. For example, the primary client device 305 may send a request to the authorized data service 124 to upload content to a channel associated with a user account. In some embodiments, the primary client device 310 may request additional location data from the service, such as IP address, MAC address, GPS data, etc. The authorized data service 124 may use the location data to verify that the primary client device 305 and the secondary client device 310 are physically co-located.

[0066] In operation 320, in response to determining that the service request in operation 316 requires secondary device authentication, the authorization data service 124 generates an authentication token. The authentication token can be a randomly generated number (e.g., a 64-bit number, a 128-bit number, etc.), a string, a password signature, a key-value pair, a hash value, a certificate, etc. In some embodiments, the authorization data service 124 can determine that a service request requires secondary device authentication by scanning a data structure that lists service request types requiring secondary device authentication and determining that the service request type is included in the list. In some embodiments, the primary client device 305 can receive an alert from the authorization data service 124 indicating that secondary device authentication is required.

[0067] In operation 322, the authorization data service 124 sends the authentication token to the primary client device 305. The authentication token may be sent as unencrypted data, or it may be encrypted by the authorization data service 124.

[0068] In operation 324, the primary client device 305 sends an authentication token to the secondary client device 310. The authentication token may be sent as unencrypted data or may be encrypted by the primary client device 305. Since authentication is based on the physical co-location of the secondary client device 310 and the primary client device 305, in some embodiments, the primary client device 305 may use short-range communication technologies to send the authentication token to the secondary client device 310. For example, the primary client device 305 may use short-range wireless communication technologies or wired communication technologies to send the authentication token to the secondary client device 310. In some embodiments, the primary client device 305 may use more than one type of short-range communication technology to send the authentication token to the secondary client device 310.

[0069] In operation 326, the secondary client device 310 sends an authentication token to the authorization data service 124. Similarly, the authentication token may be sent as unencrypted data, or it may be encrypted by the secondary client device 310. In some embodiments, the secondary client device 310 may attach a private and / or public key, certificate, cookie, or any other identifying data capable of identifying the secondary client device 305 to the authentication token to authorize the data service 124. In some embodiments, the secondary client device 310 may attach location data, such as IP address, MAC address, GPS data, etc., to the authentication token. The authorization data service 124 may use the location data to verify that the primary client device 305 and the secondary client device 310 are physically co-located.

[0070] In operation 328, the authorization data service 124 compares the authentication token received from the secondary client device 310 with the authentication token issued to the primary client device 305 in operation 322 and determines whether the authentication tokens match. For example, the authorization data service 124 may determine whether a number or string received from the secondary client device 310 is the same as a number or string generated by the authorization data service 124. In some embodiments, the authorization data service 124 may first decrypt the received authentication token, determine the cryptographic signature of the authentication token, and / or perform any other processes associated with authenticating the token received from the secondary client device 310. In embodiments where the authentication tokens do not match, the authorization data service 124 may reject the pending service request.

[0071] In operation 330, the authorization data service 124 may optionally determine that the primary client device 305 and the secondary client device 310 are physically co-located. In some embodiments, the authorization data service 124 may determine physical co-location by using location data attached to a service request received from the primary client device 305 and location data attached to an authentication token received from the secondary client device 310. For example, the authorization data service 124 may compare the location data and determine whether the IP address, MAC address, or GPS data attached to the service request received from the primary client device 305 matches the IP address, MAC address, or GPS data attached to the authentication token received from the secondary client device 310, respectively. In embodiments where the location data does not match, the authorization data service 124 may reject the pending service request.

[0072] In operation 332, the authorized data service 124 authorizes service requests. For example, the authorized data service 124 processes pending service requests received from the primary client device 305.

[0073] Figure 4A flowchart of method 400 according to some aspects of this disclosure is depicted, illustrating a process for authenticating a service request initiated by a primary client device. Method 400 is executed by processing logic, which may include hardware (circuit, dedicated logic, etc.), software (such as running on a general-purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method is performed by a server of service provider platform 130 or in conjunction with... Figure 1 The authorized data service 124 associated with the server of the service provider platform 130 is used to perform this function, while in some other implementations, Figure 4 One or more frames can be executed by another machine. In one embodiment, the processing device of the authorized data service 134 executes method 400.

[0074] In operation 412, the processing device registers a primary client device with a user account. For example, the processing device may receive a registration request from a primary client device (e.g., first client device 110) to register the primary client device with a user account associated with a service provider platform. In some embodiments, the processing device may first receive user account information, such as a username and password, to enable the primary client device to access the user account. In some embodiments, the registration request may include client device identification data, such as a device serial number, identifier, IP address, location data, or other identification data associated with the primary client device. In some embodiments, once registered, the processing device may send a cookie to the primary client device. The primary client device can then use the cookie to prove registration during subsequent requests to the service provider platform. In some embodiments, once registered, the processing device may send one or more cryptographic keys to the primary client device, such as one or more public keys and / or one or more private keys, certificates, etc.

[0075] In operation 414, the processing device registers a secondary client device with a user account. For example, the processing device may receive a registration request from a secondary client device (e.g., second client device 120) to register the secondary client device with a user account associated with a service provider platform. In some embodiments, the processing device may first receive user account information, such as a username and password, to enable the secondary client device to access the user account. In some embodiments, the registration request may include client device identification data, such as a device serial number, identifier, IP address, location data, or other identification data associated with the secondary client device. In some embodiments, once registered, the processing device may send a cookie to the secondary client device. The secondary client device may then use the cookie to prove registration during subsequent requests to the service provider platform. In some embodiments, once registered, the processing device may send one or more cryptographic keys to the secondary client device, such as one or more public keys and / or one or more private keys, certificates, etc.

[0076] In operation 416, the processing device receives a request from either the primary or secondary client device to enable the secondary client device to act as an authentication device. In some embodiments, the types of service requests requiring authentication (via the authentication device) can be predefined. For example, the processing device may receive user input to enable secondary device authentication only for login requests, content upload requests, and purchase requests.

[0077] In operation 418, the processing device receives a service request from the primary client device. For example, the processing device may receive a request to upload content to a channel associated with a user account. In some embodiments, the service request may include cookies or any other type of identifying data used to verify the identity of the primary client device. Additionally, the processing device receives a first instance of an authentication token from the primary client device. The first instance of the authentication token may be associated with the service request. In some embodiments, the first instance of the authentication token is appended to the service request. The first instance of the authentication token may be a randomly generated number (e.g., a 64-bit number, a 128-bit number, etc.), a string, a cryptographic signature, a key-value pair, a hash value, a certificate, etc. In some embodiments, the first instance of the authentication token may include location data associated with the primary client device, such as an IP address, MAC address, GPS data, etc. In some embodiments, once the first instance of the authentication token is received, the processing device may decrypt the first instance of the authentication token, determine the cryptographic signature of the authentication token, and / or perform any other processes associated with the authentication token.

[0078] In operation 420, the processing device receives a second instance of the authentication token from the secondary client device. In some embodiments, the second instance of the authentication token may include location data associated with the secondary client device, such as an IP address, MAC address, GPS data, etc. In some embodiments, the second instance of the authentication token includes a private key and / or public key, a certificate, a cookie, or any other identifying data capable of identifying the secondary client device. In some embodiments, the secondary client device may first confirm its co-location with the primary client device before sending the second instance of the authentication token (e.g., after signing it with its private key). In some embodiments, the processing device may (e.g., using the corresponding public key) first decrypt the second instance of the authentication token, determine the cryptographic signature of the authentication token, and / or perform any other processes associated with the authentication token.

[0079] In operation 422, the processing device compares a first instance of the authentication token with a second instance of the authentication token to determine whether the two instances match. For example, the processing device may determine whether a number or string associated with the first instance is the same as a number or string associated with the second instance. In embodiments where the instances of the authentication tokens do not match, the processing device may reject the pending service request.

[0080] In operation 424, optionally, the processing device may determine that the primary client device and the secondary client device are physically co-located. In some embodiments, the processing device may determine physical co-location by using location data received from a first instance and a second instance of an authentication token. For example, the processing device may determine whether the IP address, MAC address, or GPS data associated with the first instance of the authentication token (or associated with a service request) corresponds, respectively, to the IP address, MAC address, or GPS data associated with the second instance of the authentication token (e.g., matches or otherwise indicates close proximity). In embodiments where the location data of the primary client device does not correspond to the location data of the secondary client device, the processing device may reject the pending service request.

[0081] In operation 426, the device authorizes service requests. For example, the device may handle pending service requests received from the primary client device.

[0082] Figure 5 A flowchart of method 500 according to some aspects of this disclosure is depicted, illustrating a process for initiating a service request requiring authentication by an authentication device. Method 500 is executed by processing logic, which may include hardware (circuit, dedicated logic, etc.), software (such as running on a general-purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method is performed by… Figure 1The first client device 110 executes this, while in some other implementations, Figure 5 One or more frames can be executed by another machine. In one embodiment, the processing device of the first client device 110 executes method 500.

[0083] In operation 512, the processing device sends a service request to a server (e.g., a server of a content sharing platform or any other service provider platform). For example, the processing device may send a request to upload content to a channel associated with a user account. In some embodiments, the service request may include cookies or any other type of identifying data used to verify the identity of a primary client device associated with the processing device. In some embodiments, the primary client device may be registered with a service provider platform.

[0084] In operation 514, the processing device generates an authentication token. The authentication token can be a randomly generated number (e.g., a 64-bit number, a 128-bit number, etc.), a string, a password signature, a key-value pair, a hash value, a certificate, etc.

[0085] In operation 516, the processing device sends a first instance of the authentication token to the server. In some embodiments where the first instance of the authentication token is attached to the service request, operations 512 and 516 are combined into a single operation performed after operation 514. In some embodiments, the first instance of the authentication token may include location data associated with the primary client device, such as IP address, MAC address, GPS data, etc. In some embodiments, the authentication token may be attached with a private key and / or public key, certificate, cookie, or any other identifying data.

[0086] In operation 518, the processing device sends a second instance of the authentication token to the secondary client device. The secondary client device may be a physically co-located authentication device used to authenticate service requests issued by the primary client device. The second instance of the authentication token may be sent as unencrypted data or may be encrypted by the processing device. Since authentication is based on a secondary client device physically co-located with the primary client device, in some embodiments, the processing device may use wired or wireless short-range communication technologies to send the authentication token to the secondary client device.

[0087] In operation 520, the processing device receives a response from the server indicating that the server has accepted the service request. This response indicates that a first instance of an authentication token sent to the server by a first client device matches a second instance of an authentication token sent to the server by a second client device. In some embodiments, the response includes an indication that the service request has been processed or completed. In response to the server comparing the first instance of the authentication token with the second instance of the authentication token and determining that the two instances match, the service request can be processed or completed. In embodiments where the authentication token instances do not match, the processing device may receive an indication that the service request has been rejected.

[0088] Figure 6 This is a block diagram illustrating an exemplary computer system 600 according to an embodiment of the present disclosure. The computer system 600 executes one or more sets of instructions that cause the machine to perform one or more of the methodologies discussed herein. Instruction sets, instructions, etc., can refer to instructions that, when executed by the computer system 600, cause the computer system 600 to perform one or more operations and / or authorize data services of client devices 110, 120 (not shown). The machine can operate as a server or client device in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web device, server, network router, switch, or bridge, or any machine capable of executing sets of instructions (sequentially or otherwise) specifying actions to be taken by the machine. Furthermore, although only a single machine is illustrated, the term "machine" should also be understood to include any set of machines that individually or jointly execute sets of instructions to perform one or more of the methodologies discussed herein.

[0089] Computer system 600 includes processing device 602, main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), static memory 606 (e.g., flash memory, static random access memory (SRAM), etc.) and data storage device 616, which communicate with each other via bus 608.

[0090] Processing device 602 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, processing device 602 may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processing device that implements other instruction sets or combinations of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 602 is configured to execute instructions of system architecture 100 and authorization module 151 for performing the operations discussed herein.

[0091] Computer system 600 may further include a network interface device 622 that provides communication with other machines via a network 618—such as a local area network (LAN), intranet, extranet, or the Internet. Computer system 600 may also include a display device 610 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)), an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse), and a signal generation device 620 (e.g., a speaker).

[0092] Data storage device 616 may include a non-transitory computer-readable storage medium 624 on which an instruction set embodying system architecture 100 or authorization module 138 described herein is stored. The instruction set of system architecture 100, client devices 110, 120 (not shown), and / or authorization data services may also reside wholly or at least partially in main memory 604 and / or processing device 602 during execution by computer system 600. Main memory 604 and processing device 602 also constitute computer-readable storage media. The instruction set may further be transmitted or received via network 618 via network interface device 622.

[0093] While an example of computer-readable storage medium 624 is shown as a single medium, the term "computer-readable storage medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store a set of instructions. The term "computer-readable storage medium" can also include any medium capable of storing, encoding, or carrying a set of instructions executable by a machine and causing the machine to perform any one or more of the methodologies of this disclosure. The term "computer-readable storage medium" can include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0094] Numerous details have been set forth in the foregoing description. However, it will be apparent to those skilled in the art who will benefit from this disclosure that such specific details may be practiced without them. In some instances, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring this disclosure.

[0095] Some parts of the detailed description have already been presented in terms of the algorithms and symbolic representations of operations on data bits within computer memory. Such algorithmic descriptions and representations are the means by which those skilled in the art of data processing most effectively communicate the substance of their work to others skilled in the art. Here, an algorithm is generally considered to be a self-consistent sequence of operations that leads to a desired result. Such operations are those that require physical manipulation of physical quantities. Usually, but not always, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has sometimes proven convenient, primarily for general reasons, to refer to such signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0096] However, it can be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise specified, it should be understood that throughout this specification, discussions using terms such as “generate,” “provide,” “adjust,” “receive,” and “cancel” refer to the actions and processes of a computer system or similar electronic computing device that manipulate and convert data represented as physical (e.g., electronic) quantities within the computer system’s memory or registers into other data similarly represented as physical quantities within the computer system’s memory or registers or other such information storage, transmission, or display devices.

[0097] This disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specifically configured for a desired purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, optical disc read-only memory (CD-ROM), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions.

[0098] The terms “example” or “exemplary” are used herein to indicate that something serves as an example, instance, or illustration. Any aspect or design described herein as an “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present concepts in a specific manner. As used in this application, the term “or” is intended to mean inclusive “or” rather than exclusive “or.” That is, unless otherwise stated or clearly apparent from the context, “X comprises A or B” is intended to mean any natural inclusive arrangement. That is, “X comprises A or B” is satisfied in any of the foregoing instances if X comprises A; X comprises B; or X comprises both A and B. Additionally, the articles “a” and “an” used in this application and the appended claims are generally to be interpreted as meaning “one or more” unless otherwise stated or clearly apparent from the context for the singular form. Furthermore, the consistent use of the terms “embodiment” or “an embodiment” or “implementation” or “one implementation” is not intended to represent the same embodiment or implementation unless so described. The terms “first,” “second,” “third,” “fourth,” etc., used in this article are intended as labels to distinguish different elements and do not necessarily have a meaning based on the order specified by their numbers.

[0099] For simplicity of explanation, the methods herein are depicted and described as a series of actions or operations. However, actions according to this disclosure can occur in various orders and / or concurrently, and may occur alongside other actions not presented or described herein. Furthermore, not all illustrated actions are required to implement the methods according to the disclosed subject matter. Additionally, those skilled in the art will understand and recognize that these methods can also be represented as a series of interrelated states via state diagrams or events. Furthermore, it should be understood that the methods disclosed in this specification can be stored on an article of manufacture to facilitate the transfer and assignment of such methods to a computing device. As used herein, the term "article of manufacture" is intended to encompass any computer program accessible from any computer-readable device or storage medium.

[0100] In additional embodiments, one or more processing devices for performing the operations of the above embodiments are disclosed. Additionally, in embodiments of this disclosure, a non-transitory computer-readable storage medium stores instructions for performing the operations of the described embodiments. Furthermore, in other embodiments, systems for performing the operations of the described embodiments are also disclosed.

[0101] It should be understood that the above description is intended to be illustrative and not restrictive. Other embodiments will be apparent to those skilled in the art upon reading and understanding the above description. Therefore, the scope of this disclosure can be determined by referring to the appended claims and the full scope of equivalents to which such claims relate.

Claims

1. A method for protecting a user device from cookie theft, comprising: The server receives a service request from a first client device, a first instance of an authentication token associated with the service request and generated by the first client device, and first location data associated with the first instance of the authentication token and reflecting the physical location of the first client device. The server receives from the second client device a second instance of the authentication token associated with the service request and generated by the first client device, and second location data associated with the second instance of the authentication token and reflecting the physical location of the second client device, wherein the second client device receives the second instance of the authentication token from the first client device, and wherein the second instance of the authentication token is the same as the first instance of the authentication token; The server determines that the first instance of the authentication token matches the second instance of the authentication token and that the first location data matches the second location data; as well as In response to determining that the first instance of the authentication token matches the second instance of the authentication token and that the first location data matches the second location data, the server processes the service request.

2. The method according to claim 1, The first location data is associated with the first client device, and the second location data is associated with the second client device.

3. The method according to claim 2, wherein, The first location data includes at least one of the following: Internet Protocol (IP) address, Media Access Control (MAC) address, Global Positioning System (GPS) data, mobile phone tower data, or Wi-Fi access point data.

4. The method according to claim 1, wherein, The service request includes at least one of the following: login request, content upload request, content search request, content consumption request, content approval request, content disapproval request, content comment request, settings change request, personal details change request, or purchase request.

5. The method according to claim 1, wherein, The authentication token includes at least one of the following: a randomly generated number, a randomly generated string, a cryptographic signature, a key-value pair, a hash value, or a certificate.

6. The method according to claim 1, wherein, The second client device is registered as the authentication device of the first client device.

7. The method according to claim 1, wherein, The service request is identified as the type of service request that requires authentication by the second client device.

8. The method of claim 1, further comprising: In response to determining that the first instance of the authentication token does not match the second instance of the authentication token, the service request is rejected.

9. The method of claim 2, further comprising: In response to determining that the first location data does not correspond to the second location data, the service request is rejected.

10. A method for protecting a user device from cookie theft, comprising: A first instance of an authentication token and a second instance of an authentication token are generated by a first client device, wherein the second instance of the authentication token is the same as the first instance of the authentication token, wherein the first instance of the authentication token is associated with first location data and reflects the physical location of the first client device, and wherein the second instance of the authentication token is associated with second location data and reflects the physical location of a second client device; The first client device sends the service request and the first instance of the authentication token to the server; The first client device sends the second instance of the authentication token to the second client device; as well as The first client device receives a response from the server indicating that the server accepts the service request, the response indicating that the server has determined that the first instance of the authentication token sent by the first client device to the server matches the second instance of the authentication token sent by the second client device to the server and that the first location data matches the second location data.

11. The method according to claim 10, wherein, The second instance of the authentication token is sent to the second client device using short-range communication technology.

12. The method of claim 10, further comprising: The first location data associated with the first client device is sent to the server, wherein the response indicating that the server accepts the service request further indicates that the first location data sent by the first client device to the server corresponds to the second location data sent by the second client device to the server.

13. The method according to claim 12, wherein, The first location data includes at least one of the following: Internet Protocol (IP) address, Media Access Control (MAC) address, Global Positioning System (GPS) data, mobile phone tower data, or Wi-Fi access point data.

14. The method of claim 10, wherein, The service request includes at least one of the following: login request, content upload request, content search request, content consumption request, content approval request, content disapproval request, content comment request, settings change request, personal details change request, or purchase request.

15. The method according to claim 10, wherein, The authentication token includes at least one of the following: a randomly generated number, a randomly generated string, a cryptographic signature, a key-value pair, a hash value, or a certificate.

16. The method of claim 10, wherein, The second client device is registered as the authentication device of the first client device.

17. The method according to claim 10, wherein, The service request is identified as the type of service request that requires authentication by the second client device.

18. The method according to claim 12, wherein, After the second client device has determined that the second client device and the first client device are co-located, the second location data is sent by the second client device to the server.

19. A system for protecting a user device from cookie theft, comprising: Memory; as well as A processing device coupled to the memory, the processing device being configured to: Receive service requests from the first client device; Receive from the first client device a first instance of an authentication token associated with the service request and first location data associated with the first instance of the authentication token and reflecting the physical location of the first client device; The second client device receives a second instance of the authentication token associated with the service request and second location data associated with the second instance of the authentication token and reflecting the physical location of the second client device, wherein the second instance of the authentication token is generated by the first client device, wherein the second client device receives the second instance of the authentication token from the first client device, and wherein the second instance of the authentication token is the same as the first instance of the authentication token; Determine that the first instance of the authentication token matches the second instance of the authentication token and that the first location data matches the second location data; and In response to determining that the first instance of the authentication token matches the second instance of the authentication token and that the first location data matches the second location data, the service request is processed.

20. The system according to claim 19, wherein, The first location data is associated with the first client device and the second location data is associated with the second client device.

21. The system according to claim 19, wherein, The processing device is further configured to: In response to determining that the first instance of the authentication token does not match the second instance of the authentication token, the service request is rejected.

Images