An application installed on a user's computing or mobile device inherently operates in a hostile environment. A hacker may gain complete control over the device; have access to the application execution code and any data the application stores on the computing or mobile device. Thus, if the application performs any privileged actions on a remote service then the application cannot use any kind of client-side “secrets” deployed with the application in order to authenticate itself to the remote service since any such “secret” will be available to the hacker as well and thus pointless. Currently, the only solution employed is to have dedicated hardware with “secrets” embedded into the hardware of the computer or computing device. This hardware solution has numerous limitations and even then a dedicated hacker with unlimited resources can “break” into the hardware and get access to the “secret.”
Recent years have seen the increasing popularity of mobile devices, such as Apple's iOS-based devices and Google's Android-based devices, and the exponential growth of the number of applications or apps available to be downloaded and run on such mobile devices. For the apps running on the mobile devices, the hardware solution described above is no longer a feasible option for authentication and authorization of the apps since the hardware of the mobile devices are typically non-configurable. And even when the dedicated secure hardware is available, the device manufactures place restrictions on the usage of the hardware. A new approach is needed to ensure the authenticity of the apps and the security of the remote service and it associated data accessed by the apps running from the mobile devices.
The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent upon a reading of the specification and a study of the drawings.
The approach is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” or “some” embodiment(s) in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
A new approach is proposed that contemplates systems and methods to support authentication and authorization of an application running on a computing device or a mobile device to a web-based service provided by a remote server using a third-party push notification service available to the computing and/or mobile device. The application is only allowed to access and interact with the remote service after the application has been authenticated and authorized by the service provider. Unlike previous approaches, the proposed approach does not rely on any application-specific secrets associated with the application and stored on the computing or mobile device. Instead it utilizes the generic third-party push notification service security mechanisms that are available to the computing and/or mobile device. Any third-party push notification service with the appropriate security mechanisms can be utilized for the authentication and authorization of the application. For a non-limiting example, Apple's Push Notification (APN) system can be utilized for authentication and authorization of apps running on Apple's iOS-based devices.
The goal of the proposed application authentication and authorization approach is to ensure that a malicious application cannot impersonate the “good” application and perform privileged operations on a remote server providing the web service. The security of the proposed approach is based on the security of the communication channel between the remote server/service provider and the computing/mobile device running the application via the third-party push notification service available to the device. Here, the third-party push notification service must meet certain key security requirements in order to guarantee the safely delivery of a message/notification to its intended recipient (e.g., the application) so that the proposed approach can be successfully employed on top of any existing or future push notification service.
In the example of
In the example of
In the example of
In the example of
In the example of
In some embodiments, app engine 102 enables the user to register an app intended to access a web service provided by web service engine 106 running on a remote server for push notifications provided by a third-party push notification service. Such push notification service can be provided by any qualified third-party provider, such as Apple, Google, Sprint, AT & T, etc., which provides the underlying platform (such as iOS and Android) for the computing and/or mobile device and/or the mobile or wireless infrastructure for the communication channel. The key security requirements that are core for any third-party push notification service in order to guarantee the safely delivery of a message/notification to its intended recipient (application) include but are not limited to:
As depicted by the non-limiting example of the application authentication and authorization process of
Once the device token is received, app engine 102 running on the computing/mobile device forwards the token to application authentication and authorization engine 104 running on a remote server (Step 3), wherein application authentication and authorization engine 104 receives and stores the device token. Also running on the remote server is web service engine 106, which provides the remote service (e.g., WePay) and optionally associated data to be accessed by the app. The app running on the computing/mobile device goes into a waiting state after sending the device token until a push notification arrives later. During the waiting state, app engine 102 updates the user interface on the computing/mobile device to display “loading” state to the user.
In the example of
In some embodiments, app engine 102 receives the verification token from the third-party push notification service. After the token is received, the app engine 102 may use the received verification token (referred to hereinafter as the first verification token) to construct a second verification token using specific steps, wherein such steps may include but are not limited to, simply copying the received first verification token (in which case the second verification token is the same as the first verification token), or employing advanced cryptography methods like digital signatures; or using any other established method to generate the second verification token (in which case the second verification token is different from the first verification token). Note that both the first and the second verification tokens are temporary in nature for one-time use only.
In some embodiments, app engine 102 prompts user for credentials (UC) to access the remote service provided by web service engine 106 (Step 6). Once the credentials are collected from the user, app engine 102 provides the user's credentials to application authentication and authorization engine 104 together with the second verification token derived from the original first verification token (Step 7). Note that sending the second verification token to application authentication and authorization engine 104 is a specific and additional step required before the app is allowed to access the intended web service provided by the remote server.
In some embodiments, application authentication and authorization engine 104 utilizes the second verification token in addition to the user provided credentials to authenticate and authorize the application/app for accessing the web service hosted by web service engine 106 (Step 8). Specifically, in addition to verifying the user's credentials, application authentication and authorization engine 104 validates the second verification token received from app engine 102 using specific steps corresponding to the steps taken by the app engine 102 to construct the second verification token. For non-limiting examples, application authentication and authorization engine 104 may simply compare the second verification token to the first (original) verification token it generated and provided to the third party push notification service (if the second verification token is generated by simply copying the first verification token to the second), or use more advanced cryptographic techniques (like digital signatures); or any other pre-defined method to verify the second verification token if it is generated from the first verification token via other means.
If the validation of the second verification token is successful, application authentication and authorization engine 104 authenticates the application/app running on the computing/mobile device as valid and authorizes the app to access the web service provided by the web service engine 106 and associated data.
In some embodiments, application authentication and authorization engine 104 returns an API as the access token to app engine 102 for the app to access the web service hosted by web service engine 106 once the user's credentials and the second verification token are both validated to be authentic. In some embodiments, application authentication and authorization engine 104 may convert the one-time-use only second verification token with limited lifespan into the multi-use and persistent API access token that can be used in subsequent calls from the application/app to access the web service.
In some embodiments, app engine 102 enables the app running on the computing/mobile device to access the web service hosted by the web service engine 106 using the API access token received. App engine 102 may enforce security policies for the application on subsequent calls to the web service to ensure the necessary level of security protection by requesting application re-authentication and re-authorization at any time. For the purpose of re-authentication and re-authorization of the application, the process described above can be repeated at any time.
In the example of
One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
One embodiment includes a computer program product which is a machine readable medium (media) having instructions stored thereon/in which can be used to program one or more hosts to perform any of the features presented herein. The machine readable medium can include, but is not limited to, one or more types of disks including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human viewer or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and applications.
The foregoing description of various embodiments of the claimed subject matter has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the claimed subject matter to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Particularly, while the concept “interface” is used in the embodiments of the systems and methods described above, it will be evident that such concept can be interchangeably used with equivalent software concepts such as, class, method, type, module, component, bean, module, object model, process, thread, and other suitable concepts. While the concept “component” is used in the embodiments of the systems and methods described above, it will be evident that such concept can be interchangeably used with equivalent concepts such as, class, method, type, interface, module, object model, and other suitable concepts. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the relevant art to understand the claimed subject matter, the various embodiments and with various modifications that are suited to the particular use contemplated.
This application claims the benefit of U.S. Provisional Patent Application No. 61/666,155, filed Jun. 29, 2012, and entitled “Push notification based application authentication and authorization,” and is hereby incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61666155 | Jun 2012 | US |