You probably heard words like Software as a Service (SaaS) or Cloud. OAuth is the key factor in connecting them all together. Open Authorization (OAuth) is a protocol that allows an application to authenticate against a server as a user, without requiring passwords or any third party server that acts as an identity provider. It uses a token generated by the server and provides how the authorization flows most occur, so that a client, such as a mobile application, can tell the server what user is using the service. In the beginning, there was no standard for authorization hence was required to use username and password everywhere which is a security vulnerability. Then OAuth came along as a standard for authorization. It is an authorization framework that enables a third-party application to obtain a limited access to an HTTP service. It works over HTTP and connects with authorizations for APIs, devices, servers and applications with access tokens rather than using credentials such as username and password.
User- a customer who has an account in both consumer and service provider.
Consumer- Uses OAuth (Open API) to communicate between service provider.
Service Provider- Uses OAuth to communicate between consumer to provide service.
Consumer Key- API key associated with the application. It identifies the client which is the service that is trying to access user’s resource
Consumer Secret- Password used to authenticate consumer from service provider
Access Token- Access tokens are credentials used to access protected resources. There is no visible username/password. Token is meant to be the authorization to user’s resource
Below use case is compiled with above vocabulary in mind. Take a close look at how the vocabulary relates to the use case.
Below table may be outdated. The current modern companies are migrating into OAuth 2.
|Internet Service Companies||OAuth Version|
|Microsoft (Hotmail, Messenger, Xbox)||2.0|
|NHN (Open API)||1.0a|
|Daum (Yozm, Open API)||1.0a|
OAuth 1.0 Protocol is defined by RFC 5849. It is sometimes referred to as 3-Legged OAuth due to the number of requests between the provider and consumer. It has been found vulnerable to session fixation. Recommended uses are OAuth 1.0a or OAuth 2.0.
To enable an OAuth provider, you should add a Service Provider record with the necessary
access_token_url as defined by the protocol. Service provider’s API documentation should detail these for you. You will also need to define a
profile_url which is the API endpoint for requesting the currently authenticated user’s profile information. You will also need to register for a key/secret pair from the service provider.
This protocol is implemented by a number of providers. These providers include Twitter, Netflix, Yahoo, Flickr, Bitbucket, and Dropbox. Additional providers can be found on the OAuth.net Wiki.
Unlike OAuth 1.0, OAuth 2.0 is only a working draft and not an official standard. In many ways, it is much simpler than its predecessor. It is often referred to as 2-Legged OAuth because it removes the need for the request token step.
To enable an OAuth provider, you should add a
Provider record with the necessary
access_token_url as defined by the protocol. The provider’s API documentation should detail these for you. You
will also need to define a
profile_url which is the API endpoint for requesting the currently authenticated user’s profile information. You will also need to register for a key/secret pair from the provider.
OAuth 2.0 relies on HTTPS for security and is currently used and implemented by APIs from companies such as Facebook, Google, Twitter, and Microsoft. OAuth1.0a is more difficult to use because it requires the use of cryptographic libraries for digital signatures. However, since OAuth1.0a does not rely on HTTPS for security it can be more suited for higher risk transactions. I wouldn’t recommend using OAuth 2.0 for handling sensitive data. It is pretty much secured by HTTPS protocol.