Method and system for ubiquitous resource identification

Abstract

A method (600) for ubiquitous resource identification includes receiving an authentication request (132) from a first application service (130). The authentication request is for requesting authentication of a user (12) of a user device (10). The method includes obtaining device information (14) associated with the user device of the user and generating a unique opaque identifier (162) for the user device based on the device information. The method includes obtaining an authentication credential (20) from the user device. The authentication credential verifies an identity of the user. In response to receiving the authentication credential from the user device, the method includes generating an authentication token (172) and encoding the unique opaque identifier into the authentication token. The method includes transmitting the authentication token to the first application service. The authentication token allows the first application service to adjust interactions with the user device based on the unique opaque identifier.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to ubiquitous resource identification. BACKGROUND

[0002] Representational State Transfer (REST) Application Programming Interfaces (APIs) are computing interfaces often used to enable independent systems to communicate about a common resource of interest. For example, two independent systems often communicate about a user session or a device that a user is using (e.g., a mobile user device). These resources are often identified by an API that needs to exist in the resource. When an API caller wishes to address a shared resource without such an existence, the API caller must use alternative means, such as identifying a user account that is stored on the API server and associated with the user. SUMMARY

[0003] One aspect of the present disclosure provides a method for ubiquitous resource identification. The method includes receiving, at data processing hardware, an authentication request from a first application service. The authentication request is to request authentication of a user of a user device. The method further includes obtaining, at the data processing hardware, device information associated with the user device of the user, and generating, by the data processing hardware, a unique opaque identifier for the user device based on the device information. The method includes obtaining, at the data processing hardware, an authentication credential from the user device. The authentication credential verifies an identity of the user. In response to receiving the authentication credential from the user device, the method includes generating, by the data processing hardware, an authentication token, and encoding, by the data processing hardware, the unique opaque identifier of the user device into the authentication token. The method further includes transmitting, by the data processing hardware, the authentication token to the first application service. The authentication token, when received by the first application service, allows the first application service to adjust interactions with the user device based on the unique opaque identifier.

[0004] Implementations of the present disclosure can include one or more of the following optional features. In some implementations, the method further includes receiving, at the data processing hardware, a second authentication request from a second application service. The second authentication request is to request authentication of the user of the user device. The method in this implementation further includes obtaining, at the data processing hardware, device information associated with the user device of the user, the data processing hardware determining that the device information is associated with the unique opaque identifier of the user device. The method in this implementation further includes generating, by the data processing hardware, a second authentication token, encoding, by the data processing hardware, the unique opaque identifier into the second authentication token, and transmitting, by the data processing hardware, the second authentication token to the second application service. In some examples, the first application service determines that the second application service received the same unique opaque identifier as the first application service, and the first application service determines that the first application service and the second application service are interacting with the same user device based on the unique opaque identifier.

[0005] Optionally, the method further includes receiving, by the data processing hardware and from the first application service, an information request for requesting device information. The information request includes the unique opaque identifier. The method can also include transmitting, by the data processing hardware and to the first application service, at least a portion of the device information associated with the user device of the user based on the unique opaque identifier. In some examples, the method further includes transmitting, by the data processing hardware and to the user device, a credential request after receiving the authentication request from the first application service, the credential request for requesting an authentication credential and a user consent to share the device information associated with the user device with the first application service, and receiving, by the data processing hardware, a response to the credential request including the authentication credential and the user consent.

[0006] In some implementations, the device information includes at least one of: a network cookie of the user device; an internet protocol address of the user device; or an operating system version of the user device. The authentication token can include a federated identity token. For example, the federated identity token includes one of an OAuth token or a Security Assertion Markup Language (SAML) token. Optionally, the federated identity token includes a proprietary or standards-based federated identity system token. In some examples, encoding the unique opaque identifier into the authentication token includes adding the unique opaque identifier as an attribute of the authentication token. Optionally, the user is associated with a plurality of user devices and each user device of the plurality of user devices is associated with a different unique opaque identifier.

[0007] Another aspect of the present disclosure provides a system for ubiquitous resource identification. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that when executed on the data processing hardware cause the data processing hardware to perform operations. The operations include receiving an authentication request from a first application service. The authentication request is for requesting authentication of a user of a user device. The operations further include obtaining device information associated with the user device of the user and generating a unique opaque identifier for the user device based on the device information. The operations include obtaining an authentication credential from the user device. The authentication credential verifies an identity of the user. In response to receiving the authentication credential from the user device, the operations include generating an authentication token and encoding the unique opaque identifier into the authentication token. The operations further include transmitting the authentication token to the first application service. The authentication token, when received by the first application service, allows the first application service to adjust interactions with the user device based on the unique opaque identifier.

[0008] The aspect can include one or more of the following optional features. In some implementations, the operations further include receiving a second authentication request from the second application service. The second authentication request is to request authentication of a user of the user device. The operations in this implementation further include obtaining device information associated with the user device of the user and determining that the device information is associated with the unique opaque identifier of the user device. The operations in this implementation further include generating a second authentication token, encoding the unique opaque identifier into the second authentication token, and transmitting the second authentication token to the second application service. In some examples, the first application service determines that the second application service received the same unique opaque identifier as the first application service, and the first application service determines that the first application service and the second application service are interacting with the same user device based on the unique opaque identifier.

[0009] Optionally, the operations further include receiving an information request from the first application service requesting the device information. The information request includes the unique opaque identifier. The operations can also include transmitting at least a portion of the device information associated with the user device of the user to the first application service based on the unique opaque identifier. In some examples, the operations further include, after receiving the authentication request from the first application service, transmitting a credential request to the user device, the credential request to request an authentication credential and a user consent to share the device information associated with the user device with the first application service, and receiving a response to the credential request including the authentication credential and the user consent.

[0010] In some implementations, the device information includes at least one of: a network cookie of the user device; an internet protocol address of the user device; or an operating system version of the user device. The authentication token can include a federated identity token. For example, the federated identity token includes one of an OAuth token or a Security Assertion Markup Language (SAML) token. Optionally, the federated identity token includes a proprietary or standards-based federated identity system token. In some examples, encoding the unique opaque identifier into the authentication token includes adding the unique opaque identifier as an attribute of the authentication token. Optionally, the user is associated with multiple user devices, and each of the multiple user devices is associated with a different unique opaque identifier.

[0011] The details of one or more implementations of the present disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 is a schematic diagram of an example system for ubiquitous resource identification.

[0013] Figure 2is a schematic diagram of ubiquitous identification of a user device shared by multiple application services.

[0014] Figure 3 is a schematic diagram of an application service requesting information from a remote system based on ubiquitous identification of a user device.

[0015] Figure 4 is a schematic diagram of an authenticator for obtaining authentication credentials from a user of a user device.

[0016] Figure 5 is a schematic diagram of multiple ubiquitous identifications for multiple different user devices each of which is associated with the same user.

[0017] Figure 6 is a flowchart of an example arrangement of operations of a ubiquitous resource identification method.

[0018] Figure 7 is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0019] The same reference numbers in the various drawings indicate the same elements. DETAILED DESCRIPTION

[0020] In modern systems, multiple services need to be able to communicate with each other about shared resources. For example, multiple services, possibly owned and / or operated by different organizations, often want to read or update information about a device that is being used by a shared user. The multiple services that need to identify such shared resources need to provide some auxiliary identification to each other in order to agree on the same resource.

[0021] In some cases, two application services (i.e., applications) executing on the same user device want to communicate with each other, or two application services executing on different remote computing devices (e.g., servers) want to communicate about a user device of a shared user. For example, a first application service can want to obtain a security risk posture of a user device from a second application service before performing a service for the user. However, because of privacy or security concerns, an application service executing on or communicating with a user device cannot obtain a unique device identifier of the user device. Thus, two independent applications can have difficulty determining that each application is executing in the same execution environment (i.e., on the same user device) or communicating with the same user device.

[0022] In some technologies, these resources are typically identified by an API call application presence in that resource. When an API caller wishes to address a shared resource without such presence, the API caller must use alternative means, such as identifying a user account stored on the API server and associated with the user. However, privacy concerns can prevent the API caller from discovering such information. Other technologies require installation of another application on the user device that coordinates resource identification for the current user accessing the user device.

[0023] Embodiments herein are directed to a ubiquitous resource identification system that allows an application service (i.e., an application executing on data processing hardware of one or more computing devices) to obtain a unique opaque identifier (ID) to correlate to an execution environment of a user device. An ID generator obtains device information from a user device associated with a user and generates a unique opaque ID for the user device based on the device information. An authenticator obtains authentication credentials from the user device and the authenticator generates an authentication token encoding the unique opaque identifier. The authenticator transmits the authentication token to the application service, allowing the application service to adjust interactions with the user device according to the unique opaque ID.

[0024] Reference is now made to Figure 1 In some embodiments, the example system 100 includes user devices 10 associated with respective users 12 in communication with a remote system 140 via a network 112. The user devices 10 can correspond to any computing device, such as a desktop workstation, a notebook workstation, or a mobile device (i.e., a smartphone). The user devices 10 include computing resources 18 (e.g., data processing hardware) and / or storage resources 16 (e.g., memory hardware).

[0025] The remote system 140 can be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) with scalable / elastic computing resources 142 including computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware). The remote system 140 executes an ID generator 160.

[0026] The ID generator 160 obtains device information 14 associated with the user device 10 of the user 12. The device information 14 represents information about the user device 10 that, when aggregated together, helps uniquely identify the user device 10. That is, the device information 14 ideally includes multiple pieces of information that, individually, are not sufficient to uniquely identify the user device 10, but when put together, the multiple pieces of information of the device information 14 represent a unique (or near-unique) identifier of the user device 10. For example, the device information 14 includes multiple pieces of information such as an operating system (OS) type, an OS version, an OS patch level, a network cookie, an internet protocol (IP) address, installed application information, etc. The device information 14 can include only information that installed applications are generally allowed to have and does not contain personally identifiable information (PII). For example, many operating systems limit installed applications from accessing or sharing sensitive information. Instead, the ID generator 160 receives device information 14 that is unrestricted and does not include sensitive information about the user 12.

[0027] The ID generator 160 generates a unique opaque ID 162 for the user device 10 based on the device information 14 that does not directly provide information about the user device 10. That is, the opaque ID 162 does not include any identifying information about the user device 10 or the user 12, but rather serves as an identifier for the entity of the remote system 140 to identify the particular user device 10. For example, the opaque ID 162 includes a random string of numbers and / or letters that the entity of the remote system 140 uses to correlate the device information 14 obtained from the particular user device 10.

[0028] The remote system 140 also executes an authenticator 170. The authenticator 170 receives an authentication request 132 from the application service 130 that requests authentication of a user 12 of the user device 10. The application service 130 can be an application executing on any computing device (e.g., server) that hosts a service or application associated with the user 12 or the user device 10 that the user device 10 communicates with the remote system 140 over the same or a different network 112. In some implementations, the application service 130 communicates with an associated application installed and executing on the user device 10. In other implementations, the application service 130 executes on the user device 10 and communicates with another application installed on the user device 10 and / or a remote computing device. A software application (i.e., a software resource) can refer to computer software that causes a computing device to perform a task. In some examples, a software application can be referred to as an “application,” an “app,” or a “program.” Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications. For example, the application service 130 can host a network storage application (e.g., for pictures, documents, etc.) that the user 12 uses through the user device 10 (e.g., through a web browser or an application specific to the application service 130) to store files. In some examples, the application service 130 is associated with the remote system 140, while in other examples, the application service 130 is completely independent of the remote system 140.

[0029] Increasingly, many network-hosted services and applications rely on federated identity technology to manage and authenticate user access. For example, a user maintains authentication credentials (e.g., a username and password) with a single federated identity service. When the user wishes to access an account or resource associated with the user in a third-party service, the third-party service requests the federated identity service to authenticate the user. In this way, the user only needs to maintain a single set of authentication credentials, and the third-party service does not need to maintain a proper authentication service and security, but instead relies on the federated identity service.

[0030] Here, the remote system 140 can act as a federated identity service and the authentication token 172 can include a federated identity token. That is, the application service 130 requests the authenticator 170 to authenticate the user 12 so that the user 12 can access a resource associated with the application service 130. The application service 130 can send the authentication request 132 to the remote system 140 in response to a selection or indication from the user 12. For example, the user 12 selects an option to authenticate through a federated identity service (i.e., the authenticator 170) when attempting to access a resource associated with the application service 130. The remote system 140 can use any kind of federated identity technology, such as OAuth, OpenID Connect, and Security Assertion Markup Language (SAML). For example, the authentication token 172 includes an OAuth token or a SAML token.

[0031] Authenticator 170 obtains authentication credentials 20 from user device 10 to verify the identity of user 12. For example, authentication credentials 20 include a username, a password, a one-time code (e.g., for two-factor authentication), biometric information, or any other information that authenticator 170 and user 12 have agreed is sufficient to authenticate the identity of user 12. As discussed in more detail below, authenticator 170 may receive authentication credentials 20 in response to prompting user 12 to provide authentication credentials 20, for example, via a display of user device 10. Remote system 140 may issue a credential request 134 to user device 10 to prompt user 12 and / or user device 10 to provide authentication credentials 20. In some examples, credential request 134 includes a request to agree to share device information ( Figure 4 ).

[0032] The remote system 140 may receive the device information 14 along with the authentication credentials 20. That is, each time the user device 10 submits the authentication credentials 20 to the remote system 140, the user device 10 may also include the device information 14 at the same time. Additionally or alternatively, the remote system 140 may receive the device information 14 independently of the authentication credentials 20 (e.g., at regular intervals). The device information 14 may change or be updated as changes are made to the user device 10 (e.g., a patch is applied to the OS). The user device 10 may transmit updated device information 14 to the remote system 140 based on such changes.

[0033] In response to receiving the authentication credentials 20, the authenticator 170 generates an authentication token 172 (i.e., an access token), which is acceptable for token-based authentication. The authentication token 172 provides the user device 10 with access to resources managed by the application service 130. In some embodiments, the authenticator 170 includes a unique opaque ID 162 and the authentication token 172. For example, the authenticator 170 encodes or embeds the opaque ID 162 into the authentication token 172 as an additional attribute of the authentication token 172.

[0034] In some examples, remote system 140 transmits authentication token 172 to application service 130. Alternatively, remote system 140 transmits authentication token 172 to user device 10, which in turn transmits authentication token 172 to application service 130. Authentication token 172 allows user device 10 to access resources or services provided by application service 130. Furthermore, as discussed in more detail below, authentication token 172 allows application service 130 to coordinate application interactions 136 with user device 10 based on the included opaque ID 162.

[0035] Now refer to Figure 2In some implementations, the system 100 includes multiple application services 130. Here, the system 100 includes a first application service 130, 130a and a second application service 130, 130b. Here, the application services 130 are illustrated as being remote from the user device 10, but as described above, the application services 130 can also be executed on the user device 10. In this example, the remote system 140 receives a second authentication request 132, 132b from the second application service 130b after receiving the first authentication request 132, 132a from the first application service 130a and generating the corresponding authentication token 172, 172a. The remote system 140 again retrieves the authentication credential 20 and the device information 14 from the user device 10. In some examples, the remote system 140 determines that the device information 14 from the user device 10 along with the authentication credential 20 (in response to the second authentication request 132b) is associated with the unique opaque ID 162 that was previously generated for the user device 10 and provided to the first application service 130a. For example, the remote system 140 determines that the device information 14 matches (or nearly matches) the device information 14 associated with the previously generated opaque ID 162. The remote system 140 can determine whether the new device information 14 satisfies a comparison threshold when compared to the device information 14 associated with the opaque ID 162. When the new device information 14 satisfies the comparison threshold, the remote system 140 determines that the new device information 14 is associated with the previously generated opaque ID 162. In this example, the authenticator 170 generates a second authentication token 172, 172b and encodes the same unique opaque ID 162 that was previously transmitted to the first application service 130a based on the same or similar device information 14 received from the user device 10.

[0036] That is, because the user 12 used the same user device 10 to respond to the first authentication request 132a and the second authentication request 132b, the device information 14 included in both authentication requests 132a, 132b is the same or similar. Accordingly, the remote system 140 can associate the device information 14 received in response to both authentication requests 132a, 132b to the same unique opaque ID 162. Because the remote system 140 determined that the same user device 10 responded to both the first authentication request 132a and the second authentication request 132b, the remote system 140 encoded the same opaque ID 162 into the first authentication token 172a and the second authentication token 172b. The remote system 140 transmitted the second authentication token 172b to the second application service 130b.

[0037] In some implementations, the first application service 130a determines that the second application service 130b received the same unique opaque ID 162 as the first application service 130a. The first application service 130a determines, based on the unique opaque ID 162, that the first application service 130a and the second application service 130b are interacting with the same user device 10. For example, the first application service 130a and the second application service 130b communicate an ID comparison 210 that informs both application services 130a, 130b that each received the same opaque ID 162. Alternatively, the remote system 140 can inform both application services 130a, 130b of the matching opaque ID 162. Based on the common opaque ID 162, the application services 130a, 130b can infer that each is interacting with the same user device 10 without needing to receive any specific identifying information from the user 12 or the user device 10. One or both of the application services 130a, 130b can tailor their services for the user 12 and / or the user device 10 based on determining that each is interacting with the same user device 10.

[0038] Referring now to Figure 3 In some implementations, the schematic 300 shows the remote system 140 receiving an information request 310 from the application service 130 that requests a portion of the device information 14 of the user device 10. In some examples, the information request 310 includes the authentication token 172 along with the embedded opaque ID 162 received by the application service 130 from the remote system 140. The application service 130 includes the authentication token 172 and the opaque ID 162 to use as an identifier for the user device 10 that the application service 130 desires the device information 14 to be about.

[0039] The remote system 140 determines the device information 14 associated with the opaque ID 162 received from the application service 130. For example, the remote system 140 accesses a database that associates each generated opaque ID 162 with corresponding device information 14. In some examples, the remote system 140 transmits at least a portion of the device information 14 associated with the user device 10 of the user 12 to the application service 130 based on the unique opaque ID 162. For example, the application service 130 desires to determine a security posture of the user device 10 and requests device information 14 associated with a patch level and version of an operating system of the user device 10. The device information 14 transmitted by the remote system 140 to the application service 130 can be based on consent received from the user 12 of the user device 10.

[0040] Referring now to Figure 4In some implementations, the remote system 140 is configured to invoke an authentication / authorization user interface 400 on the user device 10 that prompts the user 12 to provide authentication credentials 20 to the remote system 140. Here, the authentication user interface 204 includes a message 422 that indicates to the user 12 "Please sign in below." The authentication user interface 400 also includes an authentication credential input area 412 that provides the user 12 with an interface for verifying their identity. For example, the authentication credential input area 412 includes input text boxes for a username and password, a biometric input (e.g., a fingerprint sensor), a two-factor authentication code input box, or any other technique for obtaining authentication and / or authentication credentials 20.

[0041] In some examples, the authentication / authorization user interface 400 includes a consent request area 430 that requests consent from the user 12 to allow the remote system 140 to potentially share some or all of the device information 14 with the application service 130. Here, the consent request area 430 includes a message "This service can request and / or share some device information to customize and improve your experience. If you do not want to share device information with this service, please check the box below." In this example, a check box 432 allows the user 12 to opt-out (i.e., not consent) to the sharing of the device information 14. In some examples, the user 12 customizes which portions of the device information 14 are eligible for sharing with the application service 130 and which are not. The user 12 can customize the preferences through the authentication / authorization user interface 400 or through account services or management via the remote system 140 account. The device information 14 provided to the application service 130 from the information request 310 Figure 3 ) can be based on the consent received from the user 12. The consent can apply only to the particular user device 10 that the user 12 used to provide the consent and the particular application service 130 that the user 12 is authenticating with. In some examples, the user 12 sets a global consent setting with the remote system 140 that sets a default level of sharing allowed between the remote system 140 and the application service 130 that the user 12 can customize individually for each application service 130.

[0042] In some examples, an administrator of the user device 10 controls the opaque ID 162 and the sharing of the device information 14 between the remote system 140 and the application service 130. For example, the administrator accesses a management policy user interface that communicates with the remote system 140. Additionally or alternatively, the user 12 can control the opaque ID 162 and the sharing of the device information between the remote system 140 and the application service 130 via a privacy preference user interface that communicates with the remote system 140. The user interfaces (e.g., the administrator user interface and the privacy preference user interface) can provide the ability to finely enable or disable the sharing of some or all of the device information 14 and / or the opaque ID 162 with some or all of the application services 130.

[0043] Reference is now made to Figure 5 In some examples, the diagram 500 illustrates that the remote system 140 allows the application services 130 to personalize the services provided to the user 12 based on the particular user device 10 that the user 12 is currently using. For example, the application services 130 tailor the information they select to provide to the user device 10 and / or tailor the actions that the user 12 is allowed to perform. As a specific example, a user 12 on a company-owned user device 10 with a “good” health score (i.e., security posture) can use an application service to view a file containing personal identity information, while the same user 12 when using a personal user device 10 that does not have the same good health score can only access files that are accessible to outside parties.

[0044] In the illustrated example, the user 12 is associated with multiple user devices 10, 10a-c. Here, the user 12 uses a mobile user device 10a, a laptop 10b, and a desktop 10c. The remote system 140 receives device information 14, 14a-c from each of these user devices 10a-c (e.g., when authenticating the user devices 10a-c to one or more of the application services 130) and generates a separate unique opaque ID 162, 162a-c for each user device 10a-c. Thus, when the user 12 authenticates to an application service 130 via a particular one of the user devices 10a-c, the application service 130 receives the opaque ID 162 associated with the particular user device 10 and the application service 130 can tailor its services accordingly.

[0045] Figure 6 is a flow diagram of an example arrangement of operations for a method 600 for ubiquitous resource identification. At operation 602, the method 600 includes receiving, at the data processing hardware 144, an authentication request 132 from an application service 130. The authentication request 132 requests authentication of a user 12 of a user device 10. The method 600 includes obtaining, at the data processing hardware 144, device information 14 associated with the user device 10 of the user 12 at operation 604. At operation 606, the method 600 includes generating, by the data processing hardware 144, a unique opaque identifier 162 for the user device 10 based on the device information 14.

[0046] At operation 608, the method 600 includes obtaining, at the data processing hardware 144, the authentication credential 20 from the user device 10. The authentication credential 20 verifies the identity of the user 12. In response to receiving the authentication credential 20 from the user device 10, the method 600 includes generating, by the data processing hardware 144, the authentication token 172 and encoding, by the data processing hardware 144, the unique opaque identifier 162 into the authentication token 172 at operation 610. At operation 612, the method 600 includes transmitting, by the data processing hardware 144, the authentication token 172 to the application service 130. The authentication token 172 when received by the application service 130 allows the first application service 130 to adjust the interaction 136 with the user device 10 based on the unique opaque identifier 162.

[0047] Figure 7 is a schematic diagram of an example computing device 700 that can be used to implement the systems and methods described in this document. The computing device 700 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions, are meant to be examples for the purposes of this document only, and are not meant to limit implementations of the applications described and / or claimed in this document.

[0048] The computing device 700 includes a processor 710, memory 720, a storage device 730, a high-speed interface / controller 740 connecting the memory 720 and the high-speed expansion ports 750 to the processor 710, and a low speed interface / controller 760 connecting the low speed bus 740 and the storage device 730 to the processor 710. Each of the components 710, 720, 730, 740, 750, and 760 are interconnected using various busses, and can be mounted on a common motherboard or in other ways as appropriate. The processor 710 can process instructions for execution within the computing device 700, including instructions stored in the memory 720 or on the storage device 730 to display graphical information for a graphical user interface (GUI) on an external input / output device, such as display 780 coupled to the high-speed interface 740. In other implementations, multiple processors and / or multiple buses can be used as appropriate, as well as multiple memories and types of memory. Also, multiple computing devices 700 can be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

[0049] Memory 720 non-transitorily stores information within computing device 700. Memory 720 can be a computer-readable medium, a volatile memory unit(s), or non-volatile memory unit(s). The non-transitory memory 720 can be a physical device that is used to store program (e.g., sequences of instructions) or data (e.g., program state information) for use by computing device 700 on a temporary or permanent basis. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as, for example, in boot programs). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0050] Storage device 730 can provide mass storage for computing device 700. In some implementations, storage device 730 is a computer-readable medium. In various implementations, storage device 730 can be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine- readable medium, such as the memory 720, the storage device 730, or memory on processor 710.

[0051] High-speed controller 740 manages bandwidth-intensive operations for computing device 700, while low-speed controller 760 manages lower bandwidth-intensive operations. Such allocation of functions is exemplary only. In some implementations, high-speed controller 740 is coupled to memory 720, display 780 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports 750, which can accept various expansion cards (not shown). In some implementations, low-speed controller 760 is coupled to storage device 730 and low-speed expansion port 790. The low-speed expansion port 790, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), can be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a networking device (e.g., switch or router) through a network adapter.

[0052] The computing device 700 can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as a standard server 700a or multiple times in a group of such servers 700a, as a laptop computer 700b, or as part of a rack server system 700c.

[0053] Various implementations of the systems and techniques described here can be realized in digital electronic and / or optical circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0054] These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and / or object-oriented programming language, and / or in assembly / machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer readable medium, apparatus and / or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0055] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0056] To provide for interaction with a user, one or more aspects of the disclosure can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), LCD (liquid crystal display), or touch screen, for displaying information to the user and optionally a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a user using a device, e.g., a Web browser, by which a user can provide input to the computer and receive output from the computer. Other kinds of devices can be used to provide for interaction with a user as well.

[0057] Many implementations have been described. However, various modifications can be made without departing from their spirit and scope. Therefore, other implementations are within the scope of the following claims.

Claims

1. A method (600) for pervasive resource identification, comprising: receiving, at data processing hardware (144), an authentication request (132a) from a first application service (130, 130a), the authentication request (132a) requesting authentication of a user (12) of a user device (10); obtaining, at the data processing hardware (144), device information (14) associated with the user device (10) of the user (12); generating, by the data processing hardware (144), a unique opaque identifier (162) for the user device (10) based on the device information (14); obtaining, at the data processing hardware (144), an authentication credential (20) from the user device (10), the authentication credential (20) verifying the identity of the user (12); In response to receiving the authentication credential (20) from the user device (10): generating an authentication token (172, 172a) by the data processing hardware (144); and encoding, by the data processing hardware (144), the unique opaque identifier (162) for the user device (10) into the authentication token (172a); transmitting, by the data processing hardware (144), the authentication token (172, 172a) to the first application service (130a), the authentication token (172a) when received by the first application service (130a) allowing the first application service (130a) to coordinate interactions with the user device (10) based on the unique opaque identifier (162); receiving, at the data processing hardware (144), a second authentication request (132b) from a second application service (130b), the second authentication request (132b) being used to request authentication of the user (12) of the user device (10); obtaining, at the data processing hardware (144), the device information (14) associated with the user device (10) of the user (12); determining, by the data processing hardware (144), that the device information (14) is associated with the unique opaque identifier (162) of the user device (10); generating a second authentication token (172b) by the data processing hardware (144); encoding, by the data processing hardware (144), the unique opaque identifier (162) into the second authentication token (172b); as well as The second authentication token (172b) is transmitted by the data processing hardware (144) to the second application service (130b).

2. The method (600) of claim 1, wherein: The first application service (130a) determines that the second application service (130b) receives the same unique opaque identifier (162) as the first application service (130a); and The first application service (130a) determines, based on the unique opaque identifier (162), that the first application service (130a) and the second application service (130b) are interacting with the same user device (10).

3. The method (600) of claim 1, further comprising: Receiving, by the data processing hardware (144), an information request (310) from the first application service (130a) for requesting the device information (14), the information request (310) including the unique opaque identifier (162); as well as At least a portion of the device information (14) associated with the user device (10) of the user (12) is transmitted by the data processing hardware (144) to the first application service (130a) based on the unique opaque identifier (162).

4. The method (600) of claim 1, further comprising, after receiving the authentication request (132a) from the first application service (130a): transmitting, by the data processing hardware (144), to the user device (10), a credential request (134) requesting the authentication credential (20) and user consent to share the device information (14) associated with the user device (10) with the first application service (130a); and A response to the credential request (134) including the authentication credential (20) and the user consent is received by the data processing hardware (144).

5. The method (600) of claim 1, wherein: The device information (14) includes at least one of the following: a network cookie of the user device (10); an Internet Protocol address of the user device (10); and an operating system version of the user device (10).

6. The method (600) of claim 1, wherein: The authentication token (172a) comprises a federated identity token.

7. The method (600) of claim 6, wherein: The federated identity token includes one of the following: an OAuth token or a Security Assertion Markup Language (SAML) token.

8. The method (600) of claim 6, wherein: The federated identity token includes a proprietary or standards-based federated identity system token.

9. The method (600) of claim 1, wherein: Encoding the unique opaque identifier (162) into the authentication token (172a) includes adding the unique opaque identifier (162) as an attribute of the authentication token (172a).

10. The method (600) according to any one of claims 1 to 9, wherein: The user (12) is associated with a plurality of user devices, and Each user device (10) of the plurality of user devices (10) is associated with a different unique opaque identifier (162).

11. A system (100) for ubiquitous resource identification, comprising: Data processing hardware (144); as well as Memory hardware (146) in communication with the data processing hardware (144), the memory hardware (146) storing instructions that, when executed on the data processing hardware (144), cause the data processing hardware (144) to perform operations comprising: receiving an authentication request (132a) from a first application service (130a), the authentication request (132a) requesting authentication of a user (12) of a user device (10); Obtaining device information (14) associated with the user device (10) of the user (12); generating a unique opaque identifier (162) for the user device (10) based on the device information (14); obtaining an authentication credential (20) from the user device (10), the authentication credential (20) verifying the identity of the user; In response to receiving the authentication credential (20) from the user device (10): generating an authentication token (172a); and encoding the unique opaque identifier (162) for the user device (10) into the authentication token (172a); transmitting the authentication token (172a) to the first application service (130a), the authentication token (172a) when received by the first application service (130a) allowing the first application service (130a) to coordinate interactions with the user device (10) based on the unique opaque identifier (162); receiving a second authentication request (132b) from a second application service (130b), wherein the second authentication request (132b) is used to request authentication of the user (12) of the user device (10); Obtaining the device information (14) associated with the user device (10) of the user (12); determining that the device information (14) is associated with the unique opaque identifier (162) of the user device (10); generating a second authentication token (172b); encoding the unique opaque identifier (162) into the second authentication token (172b); and The second authentication token (172b) is transmitted to the second application service (130b).

12. The system (100) of claim 11, wherein: The first application service (130a) determines that the second application service (130b) receives the same unique opaque identifier (162) as the first application service (130a); and The first application service (130a) determines, based on the unique opaque identifier (162), that the first application service (130a) and the second application service (130b) are interacting with the same user device (12).

13. The system (100) of claim 11, wherein: The operations further include: receiving an information request (310) from the first application service (130a) for requesting the device information (14), the information request (310) including the unique opaque identifier (162); and At least a portion of the device information (14) associated with the user device (10) of the user (12) is transmitted to the first application service (130a) based on the unique opaque identifier (162).

14. The system (100) of claim 11, wherein: The operations further include, after receiving the authentication request (132a) from the first application service (130a): transmitting a credential request (134) to the user device (10), the credential request (134) requesting the authentication credential (20) and user consent to share the device information (14) associated with the user device (10) with the first application service (130a); and A response to the credential request (134) including the authentication credential (20) and the user consent is received.

15. The system (100) of claim 11, wherein: The device information (14) includes at least one of the following: a network cookie of the user device (10); an Internet Protocol address of the user device (10); and an operating system version of the user device (10).

16. The system (100) of claim 11, wherein: The authentication token (172a) comprises a federated identity token.

17. The system (100) of claim 16, wherein: The federated identity token includes one of the following: an OAuth token or a Security Assertion Markup Language (SAML) token.

18. The system (100) of claim 16, wherein: The federated identity token includes a proprietary or standards-based federated identity system token.

19. The system (100) of claim 11, wherein: Encoding the unique opaque identifier (162) into the authentication token (172a) includes adding the unique opaque identifier (162) as an attribute of the authentication token (172a).

20. The system (100) according to any one of claims 11 to 19, wherein: The user (12) is associated with a plurality of user devices, and Each user device (10) of the plurality of user devices (10) is associated with a different unique opaque identifier (162).

Images