OAuth comes in a few different flavors. This implementation of OAuth comes from Version 22 of the OAuth 2.0 protocol and is heavily influenced by Facebook’s Server Side OAuth Authentication and Github’s API.
OAuth is a secure way to grant authorization without having to transfer passwords to third parties. If you’ve used an iPhone or Android app to access Twitter or Facebook you’ve likely used OAuth.
The flow is simple: it is started when a user clicks on an authorization button. They are then directed to the OAuth provider’s website, such as Facebook. They are then prompted to confirm with the OAuth provider that they are who they say they are by logging in. The user is then given the opportunity to grant authorization to the OAuth client (where the request was initiated, such as an iPhone app). After returning to the client, a code is sent that can be exchanged for a secure token. This secure token can be used to authenticate as the user. This way an iPhone app can ask for personalized content to show to the user, such as a friend list or messages. This is the mechanism that drives most of the web.
This video covers a typical flow an OAuth client follows with an OAuth provider for obtaining and using an access_token.
Client and server side web applications can use this type of authorization to add features to their service such as posting things to a timeline or adding personalization.
OAuth is simple in concept, but can be tricky to implement right. Many services also support basic auth. With basic auth, you send a user’s username and password along with every request. While this is fairly simple, it means that the client application stores your password, and this is not very secure.
This website is an OAuth provider, and you can create an OAuth client to access this website as a logged in user for select URLs.
To get started with getting your first OAuth token, follow the Quick Start Guide.← back