DTRelay Allows Developers To Build Secure Mobile & Web Apps On A CDN

Applications With No Moving Parts! (a.k.a.Pure Static Front End Applications)

Pure Static Applications include applications that are JavaScript-Based and use only HTML & JavaScript that can communicate with secure APIs. If you want to build applications that are much faster, secure, and scale much easier, then you want to build them Pure Static!

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 Code Request

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

DTRelay-Sample-Architecture

Click here to see examples of DTRelay in action.

Benefits of Using DTRelay to Build Pure-Static Apps

Simplicity

  • 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.
  • Notifications
    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.

Ubiquity

  • Mobile Compatibility
    Traditional, native mobile applications that use OAuth cannot safely store the necessary key/secret values, and they require complex callback handlers to complete the OAuth flow. Since DTRelay can operate safely in a mobile or JavaScript environment, we can use the same codebase to build web and mobile applications. We do not need specialized OAuth consumer libraries, file system storage, or native code. This means we can target any platform and generate a fully-functional, oauth-enabled mobile application by running a single “cordova build” command.
  • Plugins and Extensions
    DTRelay also allows JavaScript-based plugins and extensions to access OAuth APIs securely, making extensions as easy to build and integrate as web and mobile platforms. We have demonstrated this technology by building a small Chrome extension that can pull both Twitter and Facebook feeds, handling authentication and redirection as necessary, using DTRelay.
  • Dynamic Content and SEO in Static Applications
    With a pure-static client application, there is no opportunity to provide SEO information about unique objects. Search crawlers and technologies like Open Graph or Twitter Cards cannot execute the JavaScript necessary to pull the photo details from the API and render the content. The irony is that Google created a wildly popular web technology, Angular, which is not SEO-friendly (oops)… However, with DTRelay, we have the opportunity to request the resource and present the appropriate metadata response without the need for costly, burdensome, and problematic prerendering (http://prerender.io).
  • Serverless
    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.

Utility

  • 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).

Security

  • 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.
  • Auditing
    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.

Development

  • 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.

There are many other benefits when using DTRelay. Contact us to find out more. You can view examples of how DTRelay is used here.