Applications With No Moving Parts! (a.k.a.Pure Static Front End Applications)
The Solution To Securing Single-Page Apps
Single-Page Apps (SPAs), such as Angular or React sites, are part of a larger domain of web-based applications, which we call Pure-Static Apps. The defining factor for a pure-static app is that the app lacks any dynamic requirements, such as a server-side injection of sensitive credentials. These apps are desirable because they can be deployed safely in a mobile environment or a Content-Delivery Network (CDN).
Have you ever considered it is possible to build secure Mobile or Web Apps on A CDN? DTRelay has a process allowing you to build complex apps where none of the sensitive data is exposed.
DTRelay also provides compatibility with Social Platforms, and does much more.
Why Build Pure-Static Apps?
- HTML/JS (or other client-side frameworks)
- Zero Server-Side Interaction
- Performance and User Experience
- Deployment with little to no Infrastructure Identical Distributions: Content Delivery Network
Click here to see examples of DTRelay in action.
Benefits of Using DTRelay to Build Pure-Static Apps
- Single-Page State Retention:
Normally, OAuth requires the user to be redirected a number of times during the authentication process. However, because DTRelay performs the necessary redirects, it is possible for a user to authenticate during a single, asynchronous request. This means a user can login without leaving the page, or even within a quick popup modal. With single sign-on, this can be as simple as a single button click.
- Allow Applications to be Deployed as Server-Independent Architectures:
Applications that leverage DTRelay require no server-side code, so they can be deployed pretty much anywhere, with no system requirements. Anything that can execute client-side code and maintain minimal state information is a candidate for secure OAuth interaction via DTRelay, including mobile devices, web- based applications built with PhoneGap/Electron, or even microcontrollers. Applications can be developed successfully with no knowledge of server resources, run-time environment or understanding of security practices and protocols.
With specialized delegates, it is possible to send notifications, transparently, during key events. By monitoring certain endpoints and parameters, we can trigger any necessary actions in the delegate. For example, we can send an email when a user registers a new account, or send a warning when a user reaches their quota. This takes the burden of notification off of the API, which can focus on hosting resources or may be third-party and unable to add notifications.
- Authorization Gateway
While we normally consider the API provider to be responsible for authorizing users, in some cases it makes sense to put this functionality on the relay. For example, if we are using exclusively third-party APIs, but we want to allow users to log in to access personalized content from multiple devices or enforce paid access or quotas, we can use a specialized delegate on the relay to handle user authentication.
- Mobile Compatibility
- Plugins and Extensions
- Dynamic Content and SEO in Static Applications
It is currently popular to develop “serverless” stacks, where functions are executed by general-purpose servers, such as AWS Lamba. This removes the need to manage servers or worry about scaling. However, practical applications need to worry about whether a client application is authorized to execute a particular function. DTRelay as an authorization gateway and resource manager offers this control with minimal server requirements and simple setup.
- Scalable Hosting (CDN)
DTRelay eliminates the need for a server-side process to generate and embed client tokens during an HTTP Request. This feature makes it possible to host applications at a fraction of the cost by leveraging web server caches or CDN technologies (such as Amazon CloudFront), or even running a self-contained web application as a local file or mobile application. This also eliminates the need for a developer to create an app-specific credentialing mechanism reducing development cost and the chance for security flaws to be introduced.
- Geographical/Demographical Distribution and Targeted Content
Since DTRelay represents a singular destination for requests from the client application, it can be used to distribute content or load among users based on load, demographic information, or even geographically. For example, we can configure multiple APIs to provide news content for specific geographic areas, and DTRelay acts as a traffic controller sending requests to the correct host API.
- Multi-API Integration
Creating API “mash-ups” where we combine the resources from multiple providers is simple to accomplish with DTRelay. Since all API access is handled through DTRelay, every request for resources looks the same within the client application. For example, by adding the consumer credentials for Facebook and Twitter to the configuration, an application can easily make requests to both without worrying about any of the steps to authorize these resources.
- Paid Access and Quotas on APIs
As an intermediary, DTRelay delegates are able to enforce permissions and access on client applications. For example, a DTRelay delegate could charge a user for access to a particular API endpoint, or enforce a quota limiting the number of requests a single user could make in a 24-hour period. This can be accomplished, even if the provider is a third-party resource, providing an opportunity for paid relay access points (without building an app or API).
- No Exposed Tokens
To identify registered applications, API providers often require a consumer key/secret value to authorize requests. These values are used for every request on behalf of the application and compromise can let an attacker masquerade as the application. With DTRelay, these credentials can be stored securely on the server, out of the reach of users. Moreover, OAuth tokens are stored in DTRelay and never sent to the client application, so DTRelay can be used as a security layer on top of OAuth2 to prevent the exposure of the access token during requests.
- Service Discovery
OAuth2 consumers cannot participate in Service Discovery as they must use known, fixed endpoints. If a user were to dynamically determine service endpoints, an attacker could fool the client into sending them the access token. However, DTRelay (like OAuth 1) uses client-side encryption based on a secret value. This means that holding the public token is not sufficient for access to services, so there is no danger in inadvertently sending access tokens to an attacker.
As a centralized intermediary, DTRelay is an optimal location to log and monitor requests (even across APIs) for the purpose of auditing and security review as well as analytics and behavioral analysis. A simple delegate can be used to track any element of any request or attach tracking identifiers per relay token.
- File Uploads
There are a few useful features of DTRelay that assist with file uploads. First, we can use a DTRelay to encrypt and decrypt content as it moves through. This can be used as a security mechanism, or as a means to restrict access to paid content. We can also use DTRelay’s ability to interact with other APIs to push content to third-party destinations, such as cloud storage. Both of these features prevent potentially sensitive content from ever reaching the provider/API, where it might be compromised inadvertently (APIs are much more complex machinery where mistakes are far more likely) or deliberately (the API may be third-party or accessible to a curious and/or malicious developer).
- Privacy and HIPAA Compliance
DTRelay can be useful for protecting privacy of identifying information (II). It could be easily argued that OAuth 2 is not sufficient to protect highly-sensitive information, such as healthcare data. However, DTRelay’s request authentication mechanism minimizes this problem. In the case of HIPAA-compliance, servers for the handling and storage of data can be extraordinarily expensive. It is prudent that the premium server resources for HIPAA-compliance are not used for mundane processing. Since DTRelay can facilitate communication with multiple APIs, we can put sensitive information on an independent API. We can also limit the personnel who have access to protected information, while allowing the majority of developers to work freely on other API services. Specialized delegates even provide the opportunity to deidentify data coming from either the client or resource provider and/or swapping in randomized identifiers.
- API Translator
DTRelay provides an opportunity to translate between application and API. This can be useful for mock APIs and adapters. For example, we recently needed to communicate with an enterprise architecture in production, but wanted to use our traditional Deep Thought-based test environment for development. We created a delegate that translated Deep Thought’s responses to the enterprise solution, so that the application can be used seamlessly between both environments.
- New Protocols Without App Changes
Since the method of access to the API is controlled in DTRelay, we can change protocols with a simple update to a configuration file. One practical instance of this: when we have a client that decides to host independently, we do not always have access to the necessary libraries for OAuth 1, so we transition everything to OAuth 2 by swapping out the protocols. Even if they released a new “OAuth 3” tomorrow, we could transition our apps seamlessly by implementing the appropriate delegate and updating the configuration on the relay.
- Non-OAuth APIs
It is worth stating explicitly, DTRelay works equally well with non-OAuth APIs. We often use it to access public APIs that require no authorization, but specialized delegates can communicate with any type of resource while allowing your application to treat every API uniformly.
- DTRelay as a Proxy Server
As an added benefit of using DTRelay to relay messages to APIs, the relay can also be used as a proxy server, allowing protected resources to remain behind internal firewalls with DTRelay as a single, exposed destination.
- Transient Servers and Services
Because the client application only needs to know about a single destination (the relay), we are free to reconfigure our server architecture as desired for load balancing, resource consolidation, or changes in implementation without the need to release a new version of the client application or maintain legacy endpoints.
- Support for “DELETE” and “PATCH” HTTP methods in OAuth
Some implementations of OAuth do not support the HTTP PATCH header, nor do they allow for parameters to be passed with a DELETE header. This makes it difficult to use traditional REST applications with OAuth- based APIs. However, DTRelay delegates provide an opportunity to receive standard REST requests from the client application and convert these requests to the appropriate endpoint in-transit.