# Securing Internal Applications

DevFeed: [Securing Internal Applications](<https://devfeed.tech/articles/securing-internal-applications-19700.md>)

Original publisher: [Read original article](<https://word.bitly.com/post/47548678256>)

Author: Wordbitly

Published: 2013-04-09T17:19:51Z

Content type: article

Language: en

Sources: [Bitly](<https://devfeed.tech/sources/bitly.md>)

Topics: [Authentication](<https://devfeed.tech/topics/authentication.md>), [Authorization](<https://devfeed.tech/topics/authorization.md>), [servers](<https://devfeed.tech/topics/servers.md>), [nginx](<https://devfeed.tech/topics/nginx.md>), [OAuth 2.0](<https://devfeed.tech/topics/oauth2.md>), [Google](<https://devfeed.tech/topics/google.md>), [HTTP](<https://devfeed.tech/topics/http.md>)

Tags: [authentication](<https://devfeed.tech/tags/authentication.md>), [authorization](<https://devfeed.tech/tags/authorization.md>), [google](<https://devfeed.tech/tags/google.md>), [http](<https://devfeed.tech/tags/http.md>), [nginx](<https://devfeed.tech/tags/nginx.md>), [oauth2](<https://devfeed.tech/tags/oauth2.md>)

## AI overview

The article describes Google Auth Proxy, an HTTP reverse proxy developed by bitly to secure internal applications with Google Account authentication through Google's OAuth2 API. It addresses the limitations of HTTP Basic Auth and application-specific authorization lists by allowing access for individual Google Accounts or an entire Google Apps domain.

## Source excerpt

A common infrastructure problem is managing access to internal applications. Some patterns for solving that problem include: fronting internal apps with HTTP Basic or HTTP Digest authentication through Apache or nginx, running the apps on secret ports, and bundling an authentication system as part of each application. Many off-the-shelf applications include no built-in authentication, and count on upstream proxies/systems for access control which limits options for securing them. Google Auth Proxy is a tool we have developed to give us a better ability to secure internal applications by using Google Account authentication (like many other startups, we rely on Google Apps). At bitly, we like fronting HTTP applications with Nginx and use that approach for nearly all of our stack, from Tornado apps handling our core APIs to common internal tools (e.g. Nagios, Munin, Graphite) to homegrown tools like NSQ and our deploy system. For many of those systems, we took advantage of this by configuring HTTP Basic authentication to restrict access. Using Basic Auth however led to situations where the authentication information would be stored in configuration files and scripts, leaking it throughout the repository. Some of our homegrown tools initially relied on bitly's OAuth 2 service for authentication, which meant that sign in was managed through bitly accounts by the OAuth flow. This left each application to handle authorization by maintaining a list of bitly accounts that actually had permission to access the app. This was an improvement over HTTP Basic Auth as each application did not need to accept or store passwords, but it was less than ideal because each app still needed to store and manage its own list of authorized users. Over time, this led to a large number of disparate systems with separate authorization lists. This approach was only feasible for internal tools and thus couldn't apply to other open source applications we were using. We developed Google Auth Proxy a