Help & Support
What is OAuth?
OAuth consists of a set of standard protocols (OAuth1.0, OAuth2.0) designed to securely perform authentication and authorization over the internet. While the full specifications of these protocols are fairly complex, integrating OAuth in your application is straightforward. Fundamentally, OAuth delineates the responsibility of authentication and authorization to a set of authorization servers (a.k.a, provider). Many well known social media sites, including Google, Facebook, and Twitter, provide their own OAuth providers. For applications that integrate with these providers, users can sign in with their social media credentials.
What is the advantage of OAuth2 over using simple authentication?
OAuth provides several advantages of traditional authentication schemes. First, OAuth cleanly separates the responsibility of authentication and authorization. That means, in theory, your application should be able to use alternative providers or even multiple providers. So long as the provider conforms to the OAuth standard, you should be able to use it. Second, OAuth is a token-based system. That means your application passes around tokens in order to access resources. In the case of OAuth2, tokens are short-lived and easily revoked. That means even if a token is leaked, the damage will be contained. Finally, token-based security is ideal for API-based applications. This makes OAuth ideal when there may be multiple client applications (e.g., mobile and web applications).
Is OAuth2 only used by social media sites?
No! OAuth (and especially OAuth2) is a relatively new standard, and as such much of the initial adoption has been in the social media space. However, many other applications now support OAuth including Salesforce, Zenefits, GitHub, and Trello. Over time we believe that most online applications will support OAuth.
How does Oauth.Us compare to using other social media OAuth providers?
The key difference is that Oauth.Us helps you create your own OAuth2 provider, whereas with Google, Facebook, etc. you are forced to use their provider. Typically you would want to use a social media provider if your application needs access to social media-specific resources (i.e., you need to post a message on behalf of a user), or you are fairly certain that your users will have an account with the appropriate social media provider.
It makes less sense to use a social media provider if you need to protect your own API resources, or if your users may not want to use existing social media credentials. For example, business application users may feel uncomfortable using their personal Google credentials to log in to a work-specific application.
Another great advantage is that with Oauth.Us you can control the overall user experience more tightly. When using a social media provider, you are forced to redirect the user to an external site with its own distinct visual branding. With Oauth.Us, however, each provider can be customized to blend into the application more naturally. Oauth.Us is designed so that your users never realizes they have left your application.
What features does Oauth.Us support?
Oauth.Us supports the OAuth2 standard. OAuth2 is a newer standard than OAuth1 and is designed to be easier to integrate for client applications. OAuth2 supports multiple ways of authenticating users, and Oauth.Us supports the following “credential flows”:
- Authorization codes
- User credentials (a.k.a Password flow)
- Client credentials
- Refresh tokens
What security metrics does Oauth.Us implement?
Oauth.Us implements several security measures to mitigate the possibility of a data breach. First, when you create a custom Oauth.Us provider, the provider is launched in a separate subnet in your own AWS account. This makes it simple to lock down network access when necessary. User passwords are never stored on the provider. Instead, the password ishashed using bcrypt with a random salt. The hashed value is then encrypted using AES256 using a random provider-specific key. Similarly all tokens incorporate a random element and are encrypted with the provider-specific key.