Oauth.Us Architecture


Internal Services


Each Oauth.Us provider comes bundled with several services:

  • A web-based administrative portal
  • A web-based user portal
  • An authorization server
  • An endpoint server

Each of these services run on a different port so that users can easily connect to the right service.

In addition to these services, each provider also supplies its own MongoDB server that runs locally as a private container on the same host. This server stores user credentials and other key information regarding the provider.

Resource Servers


Oauth.Us interfaces with external resource servers via endpoints. Clients wishing to access protected resources should redirect requests to the endpoint server.

docs/../../../_static/img/endpoint_architecture.png

Because these endpoints are configured in a language-agnostic manner, the actual resource servers can be written in any web framework. Also, it’s possible to associate multiple OAuth providers with a single set of resources.

This can be used, for example, to create multiple classes of users. Users associated with a provider contained in a private instance may enjoy greater rate limits. A provider contained with a public subnet, however, may only authenticate a few users and have stricter rate limits.

Network Security


Because resource servers are external to the provider, it is important that clients cannot directly fetch resource from the resource servers. Otherwise the clients would be able to bypass authentication and authorization. Instead, the resource servers should be contained within a private subnet so that only the OAuth provider can access those resources. Users should redirect resource requests to the endpoint server.

Oauth.Us will automatically place new providers in a public subnet unless otherwise directed. Here are some additional pointers regarding public and private subnets.

Database Security


As previously mentioned, all user credentials and information are stored in a private MongoDB server. The server is not accessible to the internet and can only be accessed by the local OAuth services.

In addition to these safeguards, all user passwords are salted and hashed with bcrypt. The actual passwords are never stored in any database. In addition, the hashed passwords are then encrypted using AES256 using a random encryption key unique to each provider. Similarly all tokens are encrypted using AES256 to easily verify the origin of the token.