Techniques for authentication and authorization of a user, an application, or a user device for access to web resources are described. For example, a machine identifies an access request to access a remote resource associated with a web service. The access request may be received from an application executing at a user device. The machine retrieves at least one user artifact from a security manager identifier received from the web service. The machine performs fingerprinting of the user device based on the at least one user artifact. The machine transmits the access request to the web service based on the performing of the fingerprinting of the user device. The machine, in response to the transmitting of the access request to the web service, receives a resource access authorization from the web service for the application executing at the user device.
|
9. A method comprising:
identifying an access request for an application to access a remote resource associated with a web service;
automatically retrieving at least one user artifact from a security manager identifier (SMID), the SMID including a quick response (QR) code that represents one or more artifacts previously provided by a user;
automatically performing fingerprinting of the user device based on matching the at east one user artifact and a stored artifact;
transmitting the access request based on the performing of the fingerprinting of the user device; and
in response to the transmitting of the access request, receiving a resource access authorization for the application.
17. A non-transitory machine-readable storage medium storing instructions that, when executed by one or more hardware processors, cause the one or more hardware processors to perform operations comprising:
identifying an access request for an application to access a remote resource associated with a web service;
automatically retrieving at least one user artifact from a security manager identifier (SMID), the SMID including a quick response (QR) code that represents one or more artifacts previously provided by a user;
automatically performing fingerprinting of the user device based on matching the at least one user artifact and a stored artifact;
transmitting the access request based on the performing of the fingerprinting of the user device; and
in response to the transmitting of the access request, receiving a resource access authorization for the application.
1. A system comprising:
one or more hardware processors; and
a non-transitory machine-readable medium for storing instructions that, when executed by the one or more hardware processors, cause the one or more hardware processors to perform operations comprising:
identifying an access request for an application to access a remote resource associated with a web service;
automatically retrieving at least one user artifact from a security manager identifier (SMID), the SMID including a quick response (QR) code that represents one or more artifacts previously provided by a user;
automatically performing fingerprinting of the user device based on matching the at least one user artifact and a stored artifact;
transmitting the access request based on the performing of the fingerprinting of the user device; and
in response to the transmitting of the access request, receiving a resource access authorization for the application.
2. The system of
3. The system of
4. The system of
receiving the SMID using at least one of QR code submission, redirection, push notification, manual entry, or an email communication.
5. The system of
transmitting the SMID to verify the user device in response to the identifying of the access request.
6. The system of
signaling a display associated with the user device to present at least one portion of the at least one user artifact based on receiving an indication that the user device is verified by the web service.
7. The system of
8. The system of
preventing the user device from prompting the user with one or more user authentication pages based on identifying a valid user token associated with the user from the SMID.
10. The method of
11. The method of
12. The method of
receiving the SMID using at least one of QR code submission, redirection, push notification, manual entry or an email communication.
13. The method of
transmitting the SMID to verify the user device in response to the identifying of the access request.
14. The method of
signaling a display associated with the user device to present at least one portion of the at least one user artifact based on receiving an indication that the user device is verified by the web service.
15. The method of
16. The method of
preventing the user device from prompting the user with one or more user authentication pages based on identifying a valid user token associated with the user from the SMID.
18. The non-transitory machine-readable storage medium of
receiving the SMID using at least one of QR code submission, redirection, push notification, manual entry or an email communication.
19. The non-transitory machine-readable storage medium of
transmitting the SMID to verify the user device in response to the identifying of the access request.
20. The non-transitory machine-readable storage medium of
signaling a display associated with the user device to present at least one portion of the at least one user artifact based on receiving an indication that the user device is verified by the web service.
|
The present application claims the benefit of priority under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application Ser. No. 61/671,985 filed on Jul. 16, 2012 and entitled “USER DEVICE SECURITY MANAGER,” which is hereby incorporated by reference herein in its entirety. The present application may be related to U.S. patent application Ser. No. 13/436,684 filed on Mar. 30, 2012 and entitled “USER AUTHENTICATION AND AUTHORIZATION USING PERSONAS,” which is hereby incorporated by reference herein in its entirety.
The present application is a continuation of and claims the benefit of priority under 35 U.S.C. § 120 to U.S. patent application Ser. No. 13/709,705 filed on Dec. 10, 2012 and entitled “USER DEVICE SECURITY MANAGER,” which is hereby incorporated by reference herein in its entirety.
The present application relates generally to the technical field of user and/or application security information management and, in various embodiments, to systems and methods for authenticating and/or authorizing a user, an application or a user device for access to web resources.
Web services, such as online advertisers, online marketplaces, online payment providers, social network services or other aggregator websites, may deploy technologies to authenticate users, such as receiving user-typed or browser-provided user information (e.g., identifications and passwords) via login web forms provided by the web services. Once the users are properly authenticated, for example, based on determining that the user-typed or browser-provided user information matches stored user information, then the web services may authorize the users for different services based on their identifications. For example, the web services may provide one user with certain services (e.g., functions) while refraining from providing another user with the same services.
Example embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.
Example methods and systems to authenticate and authorize a user and/or an application for web resources using user devices, such as mobile devices, are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to a person of ordinary skill in the art that various embodiments may be practiced without these specific details. Also, it is to be understood that other embodiments may be utilized and that structural, logical and electrical changes may be made without departing from the scope of the embodiments disclosed herein. The following description of example embodiments is, therefore, not to be taken in a limited sense, and the scope of the disclosure is defined by the appended claims.
The functions or algorithms described herein may be implemented in software or a combination of software and human implemented procedures in one embodiment. The software may consist of computer executable instructions stored on computer readable media such as memory or other type of storage devices. Further, such functions correspond to modules, which are software, hardware, firmware or any combination thereof. Multiple functions may be performed in one or more modules as desired, and the embodiments described are merely examples. The software may be executed on a digital signal processor, ASIC, microprocessor, or other type of processor operating on a computer system, such as a personal computer, server or other computer system.
Currently, authentication of a user and/or an application to a web service, such as e-commerce properties (e.g., eBay) or social networking properties (e.g., Facebook), is embedded within the application itself. In many cases, the application accessing the web service is developed and distributed by a third party developer different from the web service provider 190. Accordingly, the current approach reveals a huge risk of user credentials of the user being illegitimately exposed outside the application, and thereby allows a malicious user or program to use the illegitimately exposed user credentials, causing damage to the user.
In addition, under the existing technologies, once the user and/or the applications are authenticated, the application is provided an access to either all resources of the (backend) web service or a hard-coded application identification-based selection of the resources. This in turn provides the user or the web service provider 190 with less control of how much resources of the web service the user and/or the web service provider 190 are going to allow for the application.
Furthermore, under the existing technologies, as noted above, since the authentication mechanism to access the web service is embedded in the application itself, repairing a detected flaw or adding a new functionality in the authentication mechanism incurs redistributing the application to a number of users again. This problem can be aggravated, for example, when the change in the authentication mechanism is due to the change in the web service, and not in the (third party's) application.
Apparatus and methods according to various embodiments disclosed herein propose addressing at least the above described problems, as well as other problems. In various embodiments, for example, a user device security manager, such as a “mobile Security Manager (mSM),” is proposed, for example, to explicitly separate user authentication and/or authorization from the application accessing the web service providing the backend web (e.g., e-commerce or social networking) services. For example, the user device security manager (e.g., mSM), according to various embodiments, may authenticate the application and/or its user, implementing a mobile single-sign-on (SSO), and establish a trust relationship with the backend web services on behalf of the application and/or the user so that once authenticated, the application may access only what it is allowed to.
In various embodiments, for example, the user device security manager executing at a user device corresponding to a user of a web service may identify (or detect) a first request issued from an application to access remote resources associated with the web service. The application may execute at the user device, and be separate from the user device security manager. The user device security manager may acquire security information associated with the application in response to the identification of the first request. The security information may include at least one of identification, an access scope or a nonce for the application. A second request may be transmitted from the user device security manager to the web service to authenticate the application by the web service based at least in part, on the application identification.
In various embodiments, the methods may be optimized to be performed on smartphones executing smartphone operating systems, such as iOS, Android, and Windows, etc. In various embodiments, the methods may be optimized to be performed on a tablet computing device, such as the Apple iPad™, tablet computing devices operating the Android™ operating system, and tablet computing devices operating the Blackberry™ operating system and the WebOS™ operating system. In some embodiments, the methods may be performed on other computing devices such as smart phones, mobile devices, laptops, desktop computers, and so forth. Various embodiments that incorporate these mechanisms are described below with respect to
It is noted that particular web services, such as eBay and Facebook, are used as an example for the description, and that the embodiments described herein may be applicable to any other web services or applications utilizing web services. In various embodiments, “the company” to represent any company that wishes to use various embodiments, for example, to protect its mobile users and itself while facilitating access to the company hosted resources from the mobile device. These “resources” may comprise at least one of company data, user data, web services (SOAP/REST/and so on), any service, or transactions and so on.
The server machines 110 may comprise a security management server 120 and one or more web service platforms, such as a network-based trading platform (e.g., eBay). In various embodiments, the network-based trading platform may provide one or more marketplace applications, payment applications, and other resources. The marketplace applications may provide a number of marketplace functions and services to users that access the marketplace. The payment applications, likewise, may provide a number of payment services and functions to users. The network-based trading platform may display various items listed on the trading platform.
The embodiments discussed in this specification are not limited to network-based trading platforms. In other embodiments, other web service platforms, such as a social networking websites, news aggregating websites, web portals, network-based advertising platforms, or any other system that provide web services to users, may be employed. Furthermore, more than one platform may be supported by each security management server 120 and each platform may reside on a separate server machine 110 from the security management server 120. It is also noted that web services, according to various embodiments, may include any heterogeneous/disparate web services across the internet, and may not be just confined to within the enterprise that hosts the security management server 120.
The client machine 150 may host a security management client 160. In various embodiments, the security management client 160 may be a web browser or a native application, such as a gadget program, that operates in a background of the computing environment of the client machine 150 or a combination thereof. The client machine 150 may be configured to permit a user to access the various applications, resources, and capabilities of the web services via the security management client 160.
The client machine 150 may also comprise a display unit 170 that receives a selection of a persona from a plurality of persona symbols 172 and 176 to access the web services represented in the form of service symbols 174. In various embodiments, the display unit 170 may comprise a touch screen device capable of capturing a user's finger or electronic movements thereon. More detailed explanations regarding the security management client 160, security management server 120 and the display unit 170 are provided below in detail with respect to
It is noted that while
In some embodiments, for example, the user device security manager 151 (e.g., mSM) may be in the form of an html (e.g., html5) application. In such a case, no explicit download, installation, or activation of the user device security manager 151 may be needed. Instead, the user can simply access the user device security manager 151 using his mobile web browser via a uniform resource locator associated with the user device security manager 151. In other embodiments, for example, the user device security manager 151 (e.g., mSM) may be in the form of a native application that is embedded in an existing (e.g., trusted) application. The user device security manager 151 (e.g., mSM), in the form of the html application or the native embedded form, may provide various features, such as device identification, authentication mechanisms and so on. The user device security manager 151 (e.g., mSM) may be initially inactive (e.g., in “UnActivated state”) until it is activated on the client machine 150, for example, by its user. More information regarding registering or activating the user device security manager 151 (e.g., mSM) is provided below with respect to
Referring to
Once logged-on, certain user related “artifacts” may be transmitted to the associated web site and thus to the user device security manager 151 (e.g., mSM) to register the user. Each of the artifacts may comprise information that is unique to the user, known only to the user, or easily recognizable by the user. Examples of the artifacts may be the user's personal photo, favorite color, or a phrase chosen by the user. Other or additional information may be used. Arrows (1), (2) and (3) in
The user may select the form of activation of the user device security manager 151 from a plurality of options, as illustrated by an arrow (4) in
In various embodiments, referring to
When the registration is successfully completed, a security manager identifier (SMID) comprising a string blob that is an encapsulated representation of the artifacts selected by the user, may be generated and issued, for example, by the associated web site (e.g., eBay) based at least in part on the artifacts received from the user, as illustrated by an arrow (5). In one embodiment, for example, the SMID may be generated in the form of QR Code (Quick Response Code) 153. In some embodiments, in addition to the SMID, a token (e.g., AuthN Token) may be optionally assigned to the user device security manager 151 (e.g., mSM). The token may comprise information that is unique to the specific instance of the user device security manager 151 (e.g., mSM) associated with (e.g., installed on) the user's mobile device (e.g., the client machine 150).
In some embodiments, the manual entry may be used such that the user can directly type in the SMID to the user device security manager 151, for example, via a relevant user interface page (as shown in
The user device security manager 151 (e.g., mSM) may retrieve the artifacts and, optionally, a token from the SMID, execute device fingerprinting operations using the artifacts or token, and send the SMID (or some artifacts retrieved therefrom) to an endpoint of the service provider 190 (e.g., eBay) for verification. In some embodiments, to verify authenticity of its identification, the user device security manager 151 running in the background of the client machine 150 in an inactive state (to the user), may send user-related artifacts retrieved from the activation information (e.g., SMID) or the activation information itself back to the service provider 190 (e.g., eBay) from which the user device security manager 151 was previously downloaded, as illustrated by an arrow 154. In one embodiment, the user device security manager 151 may be activated based on receiving an indication from the service provider 190 that the user-related artifacts transmitted to the service provider 190 are determined to match the artifacts stored in the service provider 190 in relation with the instance of the user device security manager 151 previously downloaded to the client machine 150. In some embodiments, the user device security manager 151 may transmit additional information (e.g., device fingerprinting) to the service provider 190, as illustrated by an arrow 156.
In some embodiments, when activated, the user device security manager 151 may present (e.g., display or sound) via the client machine 150 an indication that the user device security manager 151 is in an active state 150-2. In one embodiment, for example, the user device security manager 151 in the active state 150-2 may present (e.g., display or sound) one or more of artifacts, such as a unique identification (e.g., “Lin Sanity” or a picture), of the user which the user device security manager 151 is tied to (e.g., registered for). The artifacts of the user may be preregistered and associated with the user during the registration process described above with respect to
When activated, the user device security manager 151 may present a log-in or authentication page to receive log-in or authentication information from a user of the client machine 150. For example, as shown in
As described above, during or after the activation, the user device security manager 151 may check whether the activation information received from a corresponding resource includes a (optional) token (e.g., AuthN Token) associated with (e.g., registered for) the user. The (optional) token may represent that the user is authenticated on the client machine 150, and hence the user may not need to be prompted for authentication as long as the token remains valid (e.g., until the token expires or is revoked). For example, in one embodiment, if it is determined that the token is present in the activation information (e.g., mSM) and that the token is valid, the user device security manager 151 may not prompt the user with a log-in page, and may automatically login the user to the user device security manager 151 without having the user go through the login process. In such a case, the authentication screen (e.g., web page), as illustrated in
In various embodiments, in addition to or as an alternative to the greeting, the user device security manager 151 may present one or more preregistered user artifacts, such as a message comprising a personalized text, that only the user can recognize. For example, the user identified as Jonh Smith may have previously chosen (e.g., registered) “Lin Sanity” as his personalized text, for example, as described with respect to
When successfully activated based on the user-related artifacts obtained from the activation information (e.g., SMID), the service provider 190 (e.g., eBay or a third-party application provider) may eliminate all traces of the artifacts such that they reside only on the mSM mobile device. This allows preventing unauthorized access to the artifacts of the user, for example, by a hostile program via the service provider 190. The user device security manager 151 may perform additional functions, for example, as the following: facilitate token issuance for other apps on the same device; facilitate user consent on the “scope” which the other applications may have access to; manage token(s). In one embodiment, for example, to facilitate the token issuance for other applications on the same client machine 150, the user device security manager 151 may allow the user to revoke the token(s).
The registration of the (mobile or non-mobile) application may be performed, for example, to integrate the application with the user device security manager 151 (e.g., mSM). In one embodiment, the registration may be executed in response to a user input by an application developer/owner of the application via an application registration site, such as developer network site 114 run by a service provider 190 (e.g., eBay), as illustrated in
Application authentication or authorization may be facilitated at run time such that the user device security manager 151 (or its user) can be sure which specific application the user is interacting with. This prevents fraud, or other attacks like phishing, and facilitates access to only those resources the specific application is authorized to access. The registration of the application may be specific to a platform (e.g., OS) of a (e.g., mobile) user device, such as the client machine 150. Accordingly, the registration of the application may be driven by the runtime facilities provided by the (mobile) user device (e.g., the client machine 150) to perform the verification task securely.
For example, in one embodiment, when the platform of the mobile user device is iOS, an identifier issued by an associated vendor (e.g., AppleStore Bundleid) may be used to register the (mobile) application, as illustrated in
In various embodiments, as illustrated in
In various embodiments, as illustrated in
In various embodiments, as illustrated in
In various embodiments, the user device security manager 151 (e.g., mSM) may forward the request by the application to access the resources (e.g., a list of listings on eBay) to the service provider 190 (arrow 6). In one embodiment, for example, the user device security manager 151 may transmit at least one of the application id (e.g., AppID) or the scope of the request to the service provider 190 (e.g., the web service thereof) to communicate the request by the application. The service provider 190 may perform access control checks to see if the received application id is potentially allowed access, and if so whether it needs user consent. If access is denied, the flow may end. The application may be informed of an error.
In various embodiments, for example, the service provider 190 may determine whether the (access) scope requested by the application needs user consent, and inform the user device security manager 151 of an outcome of the determination (arrow 7). If it is determined that the user consent is needed, the user device security manager 151 may start a flow to receive consent from the user. In one embodiment, for example, the user device security manager 151 may present (e.g., display or sound) a user interface (e.g., a pop-up window), asking the user whether he agrees to “Allow/Disallow” the application to access the requested resource(s) to the extent of the requested scope (e.g., read, write, a range of database to be searched, and so on), as illustrated in
In various embodiments, upon receiving the application token (e.g., AppScoped Token), the user device security manager 151 may invoke the application by transmitting the application token to the application (arrow 9). In one embodiment, the user device security manager 151 may encrypt the application token with the nonce received from the application (e.g., as described with respect to arrow 3), for example, using symmetric encryption methods, and forwarding the encrypted application token to the application. In one embodiment, in addition to or as an alternative to forwarding the encrypted application token to the application from the user device security manager 151, the service provider 190 may trigger a push notification to the application to send the application token (as encrypted or non-encrypted) to the application directly, as illustrated by dotted arrow 9-1.
In various embodiments, as illustrated in
In various embodiments, the persona generating module 205 may be configured to generate one or more personas of a user. Each persona of the one or more personas may comprise one or more attributes populated with at least one portion of user attribute information of the user, and indicate a unique identity of the user for a respective one or more of a plurality of web services provided by an associated server (e.g., the server machines 110). In various embodiments, the one or more attributes (e.g., user artifacts) of the persona may comprise at least one of a name, an account name, a password, a secret question, a secret answer, a geo location, a product preference, a lifestyle attribute, a favorite color, an age or contact information of the user. In various embodiments, the one or more attributes of the persona may comprise geo location information of a user device (e.g., the client machine 150) corresponding to the user. For example, in one embodiment, the geo location information of the user device may be provided by a satellite-based geographic information system (GIS) external to the user device. In various embodiments, the one or more attributes of the persona may comprise a picture or an image selected by the user.
The persona may be associated with a persona symbol 172 that may comprise at least one symbol assigned to the user, for example, during registration of the user and/or the client machine 150 to the security management server 120. The persona symbol 172 may comprise at least one symbol and correspond to a respective persona of a plurality of personas. Each persona may be configured to be indicative of a unique identity of the user for one or more web services and comprise one or more attributes. Each attribute of the persona may be populated with at least one portion of user attribute information of the user.
In various embodiments, the persona symbol 172 may comprise a security manager identifier (SMID) including at least one of a QR (Quick Response) code, a bar code or an RFID (Radio-frequency Identification), for example, generated by the security management server 120 in response to the user-provided (or selected) artifacts during the registration of the user or his user device, such as the client machine 150, to the security management server 120.
In various embodiments, referring back to
In various embodiments, the persona symbol may comprise a finger gesture 176 or a voice (not shown). The finger gesture 176 may comprise finger or electronic pen movements that are indicative of at least one of the letter, the number or a geometric shape, such as a circle, a rectangle, a triangle, a star, etc. In one embodiment, the finger and/or pen movements may be captured by a touch screen device (e.g., the display unit 170).
In various embodiments, the persona generating module 205 may be configured to generate more than one persona for the same user for the same web service. For example, still referring to
In various embodiments, each persona of the plurality of persona symbols 172 of the user may comprise a different subset of the user attribute information as its persona attribute(s). This allows assigning different identities to the same user not only for different web services but also for a given web service.
In various embodiments, the persona generating module 205 may be configured to generate the one or more personas responsive to receiving a user request. In such a scenario, at least one of the above-described processes to generate the one or more personas, such as populating the one or more attributes of the persona with the at least one portion of user attributes, or associating the persona with the corresponding persona symbol 172, may be performed in response to one or more user inputs. Also, when generating the persona, the persona generating module 205 may receive a user selection of an existing symbol from a group of existing symbols displayed via a display (e.g., the display unit 170) to use the selected existing symbol as the persona symbol 172 of the persona being generated. In various embodiments, the group of existing symbols may be stored in a local data storage (e.g., internal or external memory) associated with the client machine 150, the server machine 110, or a third party server.
In other embodiments, the persona generating module 205 may be configured to automatically generate the one or more personas responsive to receiving, from a respective web service of the one or more web services (e.g., provided by the server machines 110), an indication that the user's activities related to the respective web service has reached a specified threshold. For example, in one embodiment, the persona generating module 205 may automatically generate the one or more personas when the number of specified user activities, such as bidding, purchasing, and/or adding comments to other users' listings, etc., with respect to the respective web service has reached the specified threshold (e.g., 5, 10 or 100 transactions) for a specified period of time (e.g., 1 week, 1 month or 1 year, etc.). In such a scenario, the persona generation module 205 may be configured, as a default, to assign already existing user attribute information and an existing symbol as the persona attributes and the persona symbol 172, respectively, and then to allow the user to change them to his or her interests.
Referring to
For example, in various embodiments, referring to
In various embodiments, the persona symbols 172 may be previously linked to a respective web service of the one or more web services when they are mapped to corresponding personas. In such a case, the selection of a persona may be indicated by the user's finger gesture 176 (e.g., finger or electronic pen movements), drawing a certain geometric shape (e.g., circle finger gesture 176), a letter, a number or a combination thereof. The persona selecting module 210 may be configured to capture such finger gestures 176 via a touch screen device (e.g., the display unit 170). In various embodiments, the persona symbol 172 may be selected via the user's voice describing the persona symbol 172. It is noted that the above-explained methods and other methods of selecting a persona symbol 172 may be employed separately or combined together.
Referring to
The persona attribute transmitting module 220 may then transmit at least one attribute of the one or more attributes of the persona being activated to the respective web service over a network (e.g., the network 140). In various embodiments, the persona attribute transmitting module 220 may be configured to automatically populate a web form provided by the respective web service with the at least one attribute. For example, in one embodiment, the web form may comprise at least one of a registration form, a login form or a message form. In yet another embodiment, the persona attribute transmitting module 220 may be configured to automatically send information indicative of a geographic location of the user device (e.g., the client machine 150) to the respective web service.
In various embodiments, for example, the security management client 160 may have application programming interfaces (APIs) for the one or more web services. By using these APIs, the persona attribute transmitting module 220 may be capable of determining contexts of each field (e.g., user id, password or preferred services field, etc.) to be filled in the web form, and populating the field with a corresponding attribute of the persona.
In various embodiments, the security manager client module 225 (e.g., the identification module 230) may identify a first request issued from an application to access remote resources associated with a web service, the application configured to execute at the user device and separate from the user device security manager 151. The security manager client module 225 (e.g., the acquisition module 235) may acquire security information of the application in response to the identifying of the request, the security information including at least one of an application identification, an access scope or a nonce of the application. The security manager client module 225 (e.g., the communication module 240) may transmit a second request to the web service to authenticate the application by the web service at least based on the application identification.
In various embodiments, the security manager client module 225 (e.g., the artifact module 245) may retrieve at least one user artifact from a SMID that is received from the web service. The security manager client module 225 (e.g., the verification module 250) may verify (e.g., perform fingerprinting of) the apparatus based on the at least one user artifact.
In various embodiments, the at least one user artifact may comprise at least one of an image, color or phrase selected by a user of the apparatus, and wherein the at least one user artifact may be previously registered at the web service in relation with the user.
In various embodiments, the SMID may comprise a string of symbols, or a quick response (QR) code.
In various embodiments, the security manager client module 225 (e.g., the artifact module 245) may receive the SMID using at least one of QR code 153 submission, redirection, push notification, manual entry or an email communication.
In various embodiments, the security manager client module 225 (e.g., the artifact module 245) may transmit the SMID to the web service to verify the apparatus in response to the identifying of the first request.
In various embodiments, the security manager client module 225 (e.g., the verification module 250) may signal a display associated with the apparatus to present at least one portion of the at least one user artifact based on receiving an indication that the apparatus is verified by the web service.
In various embodiments, the at least one user artifact may be eliminated, for example, by the security management server 120 (e.g., the security manager server module 325 as describe with respect to
In various embodiments, the security manager client module 225 (e.g., the verification module 250) may prevent the apparatus from prompting the user with one or more user authentication pages based on identifying a valid user token associated with the user from the SMID.
More explanations regarding the functions of the security management client 160 are provided below with respect to
Referring to
Referring to
Once the indication of activation of the persona on the user device is detected, in various embodiments, the security manager server module 325 may verify the identification of the application. For example, in one embodiment, the security manager server module 325 may use information sent from the user device (e.g., via the security management client 160), such as a bundled identification or an application identification of the application, in order to verify the application.
The persona analyzing module 315 may be configured to determine whether the persona indicated as being activated on the user device matches a stored persona in memory (not shown) associated with a server (e.g., the server machines 110) on which the persona analyzing module 315 may execute. In various embodiments, the indication may comprise the persona symbol 172 that corresponds to the persona being activated, and the persona analyzing module 315 may be configured to compare the persona symbol 172 included in the indication to a stored persona symbol 172 in the memory associated with the server to authenticate the persona being activated.
The persona-based authenticating module 305 may be configured to automatically authenticate (e.g., log in) the user to a corresponding web service (e.g., services provided by eBay, Facebook or Twitter represented by the symbols “E”, “F” and “T”, respectively) to which the persona being activated on the user device is linked. In various embodiments, the authentication of the user may be based on determining that the persona being activated on the user device matches the stored persona without separately receiving the user's authentication information, such as login information (e.g., user id and password), from the user device.
In various embodiments, the indication of the activation of the persona may comprise at least a portion of the information regarding the user device itself, such as an IP (internet protocol) address and/or a phone number associated with the user device. Thus, in various embodiments, the indication of activation of the persona may not include a password or a user identification which may comprise textual information. In such a scenario, the persona-based authenticating module 305 may be configured to compare the user device information included in the indication with stored user device information corresponding to the stored persona to determine whether the persona being activated on the user device matches the stored persona. This allows one or more of same persona symbols 172 to be used for one or more users as long as the one or more users use different user devices.
Once the user is authenticated (e.g., logged in), for example, by the persona-based authenticating module 305 to the respective web service, the persona-based authorizing module 320 may authorize the user with a different level to provide a different set of personalized services to the user device based on the persona being activated on the user device. For example, in various embodiments, the persona-based authorizing module 320 may be configured to authorize the user for a first personalized service (e.g., a set of buyer functions) of the corresponding web service (e.g., eBay) based on determining that the persona being activated on the user device matches a first stored persona (e.g., buyer persona represented by the symbol “B”).
Similarly, the persona-based authorizing module 320 may be also configured to authorize the user for a second personalized service (e.g., a set of seller functions) of the same web service (e.g., eBay) based on determining that the persona being activated on the user device matches a second stored persona (e.g., seller persona represented by the symbol “S”). This allows the web service to provide the user with a plurality of different identities each associated with a different personalized service (e.g., a set of functions) for the same web service.
In various embodiments, the web service may be provided by the same server (e.g., the server machines 110) in which the security management server 120 runs. In yet other embodiments, the web service may be provided by a third party service provider 190. In such a scenario, the security management server 120 may be configured to operate as an authentication and authorization (AAA) server for the third party service provider 190, and the persona-based authorizing module 320 may be configured to receive at least one of the first and second personalized services of the web service from a different server (not shown) associated with the third party service provider 190. For example, APIs for the web service may be used by the persona-based authorizing module 320 to obtain the corresponding personalized service from the web service.
In various embodiments, the security manager server module 325 may be configured to issue an application token to the security management client 160 in response to an application token request transmitted from the security management client 160. In one embodiment, for example, the security manager server module 325 may request user consent from the security management client 160 before issuing the application token. More explanations regarding the functions of the security management server 120 are provided below with respect to
Each of the modules described above with respect to
The method 400 may commence at operation 401 and proceeds to operation 405, where a first request issued from an application to access remote resources associated with a web service may be identified, for example, by a user device security manager 151 (e.g., the identification module 230) of a user device (e.g., the client machine 150) corresponding to a user of the web service. In one embodiment, for example, the application may execute at the user device, and exist separate from the user device security manager (e.g., the security management client 160).
At operation 410, security information of the application may be acquired, for example, by the user device security manager 151 (e.g., the acquisition module 235) in response to the identifying of the first request. In one embodiment, the security information may include at least one of an application identification, an access scope or a nonce of the application.
At operation 415, a second request may be transmitted from the user device security manager 151 (e.g., the communication module 240) to the web service to authenticate the application by the web service based at least in part on the application identification.
At operation 420, the first request to the web service may be forwarded to the web service based on receiving an indication from the web service that the application is authenticated at the web service, for example, by the security management server 120 (e.g., the security manager server module 325). In various embodiments, the first request may be forwarded to the web service along with an access scope for the remote resources.
At operation 425, a user consent may be transmitted to the web service from the user device, for example, via the user device security manager 151 (e.g., the verification module 250) based on an outcome of checking of the access scope of the application by the web service with respect to the requested resources.
At operation 430, a third request may be transmitted, for example, by the user device security manager 151 (e.g., the verification module 250), to the web service to issue an application token for the application.
In various embodiments, the method 400 may further comprise encrypting, for example, by the user device security manager 151 (e.g., the verification module 250), the application token issued from the web service with the nonce of the application. The encrypted token may be forwarded to the application for example, from the user device security manager 151 (e.g., via the verification module 250).
In various embodiments, the nonce may be transmitted to the application along with the encrypted token, for example, from the user device security manager 151 (e.g., via the verification module 250).
In various embodiments, the encrypted token may be decrypted by the application. For example, in one embodiment, the application may decrypt the encrypted token using the nonce transmitted along with the encrypted token.
In various embodiments, the application may be prevented, for example, by the user device security manager (e.g., the verification module 250) from accessing the requested resources until the application transmits the token retrieved from the encrypted token to the web service and the token is verified as matching by the web service or by the security management server 120.
In various embodiments, the application may comprise a mobile application configured to execute on a mobile device, such as the client machine 150. In such a case, the application identification may comprise mobile application identification separate from an identification of a non-mobile version of the application.
In various embodiments, the security information associated with the application may be provided in the form of a system development kit (SDK) included in the application.
In various embodiments, an authentication and/or authorization of the application, the user or the user device may be performed by the one or more web services being accessed by the application, and/or by a third party authentication and authorization service provider 190 to automatically log in the user to the one or more web services, and to provide the user with personalized services based on his persona(s). More explanations regarding the automatic log in of the user, and provision of the personalized services based on personas are provided below with respect to
The method 500 may commence at operation 501 and proceed to operation 505, where a SMID may be assigned, for example, by the persona-based authenticating module 305, in response to a persona including one or more user artifacts received from a user device (e.g., the client machine 150) corresponding to the user, for example, during registration of the user, the user device or an application to the security management server 120. In various embodiments, the SMID may comprise at least one of a QR code 153, a bar code or an RFID including information indicating the persona (and its associate user artifacts). In various embodiments, a user token (e.g., OAuth Token) may be additionally assigned to the user.
At operation 510, the SMID may be transmitted, for example, by the security manager server module 325, to the user device as a result of registration of the user or the user device to the web service or the security management server 120. In various embodiments, if previously assigned to the user, then the user token (e.g., OAuth Token) may also be transmitted to the user device.
At operation 515, in response to a request transmitted from the user device upon detecting (e.g., by the security management client 160) an access request from an application to web resources, the identification of the application may be verified, for example, by the security manager server module 325. For example, in various embodiments, one or more identifications, such as Bundleid or AppID, of the application may be transmitted from the user device (e.g., by the security management client 160), and the transmitted identifications may be compared with existing identification stored, for example, at a storage device associated with the server machine 110. An outcome of the comparing may be transmitted to the user device as at least part of the verification result.
At operation 520, the user may be authenticated. For example, in various embodiments, the user may be automatically authenticated, for example, by the persona-based authentication module 305, to the web service or the security management server 120 based on the user token (e.g., OAuth Token) previously transmitted to the user device.
In various embodiments, the user may be authenticated, for example, by the persona-based authenticating module, based at least in part on a persona activated on the user device, for example, if the persona is previously registered with the security management server, as described above with respect to FIGS.
In either case, in various embodiments, the user may be authenticated without requiring secret user attributes, such as a password, from the user.
At operation 525, the user, the user device corresponding to the user, or the application may be authorized, for example, by the persona-based authorizing module, for one or more personalized services (or functions) of the corresponding web service and/or their associated web resources, for example, based on one or more persona attributes of the persona being activated and/or the user authentication. For example, in various embodiments, the user (or the device corresponding to the user) may be authorized for a first personalized service of the corresponding web service based on determining that the persona being activated matches a first stored persona. Similarly, the user (or the device corresponding to the user) may be authorized for a second personalized service of the corresponding web service based on determining that the persona matches a second stored persona.
In various embodiments, an application token may be generated and transmitted, for example, by the security management server module 325, to the user device (e.g., via the communication module 240). In one embodiment, before the generating and transmitting the application token, the security management server module 325 may receive a request to issue the application token from the user device (e.g., via the security management client 160). Also, in one embodiment, the security management server module 325 may further request and receive a user consent from the user, for example, from the user device (e.g., via the security management client 160).
In various embodiments, the one or more personalized services and their associated web resources may be provided based on one or more user authentication/authorization policies stored, for example, in a (local or remote) storage device accessible to the security management server 120.
The methods 400 and/or 500 may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), such as at least one processor, software (such as run on a general purpose computing system or a dedicated machine), firmware, or any combination of these. It is noted that although the methods 400 and 500 are explained above with respect to the server machine 110 and/or client machine 150 in
Although only some activities are described with respect to
The methods 400 and 500 described herein do not have to be executed in the order described, or in any particular order. Moreover, various activities described with respect to the methods 400 and 500 identified herein may be executed in repetitive, serial, heuristic, parallel fashion or any combinations thereof. The individual activities of the methods 400 and 500 shown in
In various embodiments, the methods 400 and 500 shown in
The example computer system 600 includes a processor 602 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 604 and a static memory 606, which communicate with each other via a bus 608. The computer system 600 may further include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 600 also includes an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse), a disk drive unit 616, a signal generation device 618 (e.g., a speaker) and a network interface device 620.
The disk drive unit 616 includes a machine-readable medium 622 on which is stored one or more sets of instructions 624 (e.g., software) embodying any one or more of the methodologies or functions described herein. The software 624 may also reside, completely or at least partially, within the main memory 604 and/or within the processor 602 during execution thereof by the computer system 600, the main memory 604, static memory 606 and the processor 602 also constituting machine-readable media. The software 624 may further be transmitted or received over a network 626 via the network interface device 620.
While the machine-readable medium 622 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the various embodiments. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.
Thus, a method and system for authenticating and/or authorizing an application, a user or a user device for web services using the user device security manager (e.g., mSM) were described. Although the disclosure has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the disclosure. The various modules discussed may be implemented in hardware, software, or a combination of these. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
In various embodiments, enhanced authentication and/or authorization of the application, user or user device, and user feedback mechanism, may result because the need to consider lifecycles of the application, such as redistribution of the application to users, is reduced. In various embodiments, the user device security manager 151 may serve as a secure interface to manage tokens (e.g., OAuth) and/or communicate alerts on behalf of the application. In various embodiments, the user device security manager 151 may provide anti-phishing mechanisms (e.g., pre-registered image) to help users identify the application before they provide their credentials to the application.
In various embodiments, the user device security manager 151 may employ OAuth protocols, for example, by implementing a “password anti-pattern” to facilitate access to remote (e.g., web) resources and services by a client, such as a mobile application, based at least in part on a ‘scoped’ token. In one embodiment, for example, the scoped token may be configured to constraint the access by the (mobile) application, and to allow at least one of the resource and service providers 190 or the end users of the (mobile) application to revoke the scoped tokens if needed. In various embodiments, the user device security manager 151 may employ native functionalities of the application running on the user device, such as mobile platforms. This allows adding enhanced security intelligence and/or capability on the user device compared to existing application-based or web-service based user or application authentication and/or authorization.
In various embodiments, the user device security manager 151 may communicate closely with backend web service platforms, such as e-commerce (e.g., eBay) or social networking (e.g., Facebook). This allows dynamically adapting the application, user and/or user device to constantly changing, increasing or decreasing security level associated with the web service. For example, in one embodiment, a stronger authentication/authorization may be enforced if a suspicious location change of the mobile device is detected, indicating a potential loss of the mobile device. In various embodiments, the user device security manager 151 may provide the user with tools to manage security information associated with the user or the application, such as password or profile reset or token cache and so on.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments need more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
Patent | Priority | Assignee | Title |
11831641, | Apr 19 2021 | Capital One Services, LLC | Using tokens from push notification providers to enhance device fingerprinting |
Patent | Priority | Assignee | Title |
6421453, | May 15 1998 | International Business Machines Corporation | Apparatus and methods for user recognition employing behavioral passwords |
6957199, | Aug 30 2000 | Method, system and service for conducting authenticated business transactions | |
7086008, | Aug 07 1995 | Apple Inc | Multiple personas for mobile devices |
7272259, | Mar 15 2002 | Computer Sciences Corporation | Systems and methods for capturing handwritten information using handwriting analysis |
7392536, | Jun 18 2003 | Microsoft Technology Licensing, LLC | System and method for unified sign-on |
7437677, | Aug 07 1995 | Apple Inc | Multiple personas for electronic devices |
7468729, | Dec 21 2004 | Meta Platforms, Inc | Using an avatar to generate user profile information |
7484176, | Mar 03 2003 | Microsoft Technology Licensing, LLC | Reactive avatars |
7636755, | Nov 21 2002 | Microsoft Technology Licensing, LLC | Multiple avatar personalities |
7685237, | May 31 2002 | Microsoft Technology Licensing, LLC | Multiple personalities in chat communications |
7702023, | Dec 29 2003 | MARVELL INTERNATIONAL LTD; CAVIUM INTERNATIONAL; MARVELL ASIA PTE, LTD | Transmitter operations for interference mitigation |
7703023, | Sep 15 2005 | Microsoft Technology Licensing, LLC | Multipersona creation and management |
7823208, | Jun 27 2000 | Microsoft Technology Licensing, LLC | Method and system for binding enhanced software features to a persona |
7865449, | Jun 18 2001 | Daon Holdings Limited | Electronic data vault providing biometrically protected electronic signatures |
7908554, | Mar 03 2003 | Microsoft Technology Licensing, LLC | Modifying avatar behavior based on user action or mood |
8375331, | Aug 23 2011 | GOOGLE LLC | Social computing personas for protecting identity in online social interactions |
9230089, | Jul 16 2012 | Ebay Inc.; eBay Inc | User device security manager |
20030012435, | |||
20030014631, | |||
20030023880, | |||
20030131260, | |||
20050120201, | |||
20050210270, | |||
20060036951, | |||
20070239522, | |||
20080019353, | |||
20080189793, | |||
20100005291, | |||
20100053187, | |||
20100138904, | |||
20100205448, | |||
20100251127, | |||
20100281427, | |||
20110025807, | |||
20110246950, | |||
20110311095, | |||
20120016850, | |||
20120023573, | |||
20130139233, | |||
20130152155, | |||
20130159413, | |||
20130263237, | |||
20140020070, | |||
CN101621518, | |||
CN101853132, | |||
CN101951385, | |||
CN1773413, | |||
JP2009116454, | |||
KR101830038, | |||
KR1020100026380, | |||
WO2008074133, | |||
WO2011025807, | |||
WO2013149048, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Dec 08 2012 | ANGAL, RAJEEV | eBay Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 037135 | /0934 | |
Nov 24 2015 | Ebay Inc. | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Feb 07 2024 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Date | Maintenance Schedule |
Aug 25 2023 | 4 years fee payment window open |
Feb 25 2024 | 6 months grace period start (w surcharge) |
Aug 25 2024 | patent expiry (for year 4) |
Aug 25 2026 | 2 years to revive unintentionally abandoned end. (for year 4) |
Aug 25 2027 | 8 years fee payment window open |
Feb 25 2028 | 6 months grace period start (w surcharge) |
Aug 25 2028 | patent expiry (for year 8) |
Aug 25 2030 | 2 years to revive unintentionally abandoned end. (for year 8) |
Aug 25 2031 | 12 years fee payment window open |
Feb 25 2032 | 6 months grace period start (w surcharge) |
Aug 25 2032 | patent expiry (for year 12) |
Aug 25 2034 | 2 years to revive unintentionally abandoned end. (for year 12) |