The OAuth protocol, which lets external web applications request access to authentication details from other services providers,such as Gmail or Facebook, has become quite popular. But even after the most up-to-date release, version 2.0, there's disagreement on how secure OAuth is.
Eran Hammer, a former OAuth author, says that OAuth 2.0 is insecure. In a 2012 blog post, "OAuth 2.0 and the Road to Hell", Hammer explains why he disassociated himself from the project. The bottom line on why:
When compared with OAuth 1.0, the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure.
Jim Manico, one of the OWASP Authentication Cheat Sheet authors, recommends Auth1.0a, even though it has now been deprecated. He notes that Twitter still supports Auth1.0a.
Is OAuth 2.0 too risky for your organization? Here's a detailed look at the issues you need to understand to decide on authentication protocols.
Why use OAuth?
Many of the benefits for implementing OAuth derive from its functionality. OAuth makes users' lives easier, since they don't need to go through lengthy procedures and forms to register and log in. For an organization that wants to know more about its users, OAuth lets you create a social graph. On the downside, the protocol does not take care of session management or authentication.
Developers must consider important guidelines to create strong authentication with OAuth as well. A great guideline for this is the OWASP Authentication Cheat Sheet. Developing strong authentication has multiple and complex requirements, OAuth can make some of these requirements easier, but it can be more complex to create.
Example implementation: Facebook OAuth
Let's look at Facebook's popular OAuth implementation. Developers willing to use it must register and obtain an app ID and app secret (client credentials) linked to a unique URL.
Based on your application programming language, Facebook recommends a specific software development kit (SDK). If you are using PHP, AngularJs or JQuery, it's best to use a specific SDK that suits your development needs, Facebook notes.
The next step consist of testing it. This next piece of HTML code needs to be inserted on a web page and will allow any Facebook user to "like" something on a web app:
This is the easiest part of the integration. In contrast, the real challenge comes from integrating the OAuth Facebook SDK with your custom app and managing login sessions within your application for registered website users.
Integrating a custom app with OAuth login
In the Facebook example, a database containing our user ID's must be created. As in any application, users must be registered first, before they can log in. You can create a MySQL database "users" table using a script similar to the one shown on the next code snippet. Running the script creates a table where the OAuth provider and the ID from that user can be saved into the database:
CREATE TABLE 'users' (
'id' int(20) NOT NULL AUTO_INCREMENT,
'oauth_provider' varchar(255) COLLATE utf8_unicode-ci NOT NULL,
'firstname' varchar(255) COLLATE utf8_unicode_ci NOT NULL,
'lastname' varchar(255) COLLATE utf8_unicode_ci NOT NULL,
'email' varchar(255) COLLATE utf8_unicode_ci NOT NULL,
'gender' varchar(10) COLLATE utf8_unicode_ci NOT NULL,
'locale' varchar(10) COLLATE utf8_unicode_ci NOT NULL,
'created' datetime NOT NULL,
'modified' datetime NOT NULL,
PRIMARY KEY('id')
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
User table Mysql script example.
One security advantage with OAuth is that passwords are not saved in the database. However, user information such as IDs (token credentials) obtained from the OAuth service, do need to be saved in it. Also, the application will require a set of custom classes to handle authentication, and to check if the user who logged through the OAuth provider has been registered in your custom application.
This is the tricky part, because even though you are using an external authentication provider, many things stay the same with regard to the authentication and session management within your application. You'll need custom classes to handle it, which normally is already done as part of a framework like Lavarel or .NET.
$fb = new Facebook\Facebook([Partial Login.php example page containing the APP ID and secret in clear text
'app_id' => '{app-id}', // Replace {app-id} with your app id
'app_secret' => '{app-secret}',
'default_graph_version' => 'v2.2',
]);
OAuth's security shortcomings
OAuth takes care of important security features, such as password strength controls, but others are worrisome, such as how to keep the App ID and secret secure. According to a SANS, there are 4 forms of attack against OAuth implementation:
- Lack of data confidentiality and server trust : This includes brute force attacks against the server.
- Insecure storage of secrets: App ID and the secret can be exposed if the source code is not properly secured. These values should be hashed or encrypted/obfuscated from potential praying eyes.
- OAuth implementation with flawed session management: The session must be entirely designed and developed on the custom app, so depending on which programming language you use, issues may arise from improper management (see the OWASP Top Ten Project.)
- Session fixation attack with OAuth: An unknown application can lure users to disclose their credentials. A malicious application might forward users to a fake login service provider page to obtain user names and passwords from victims. In addition, the service provider has no way to know whose key it is authorizing during the handshake.
A recent SC magazine article quoted security researchers from the University of Trier:
“In this attack, the attacker (running a malicious RP) learns the user's credentials when the user logs in at an IdP that uses the wrong HTTP redirection status code...The researchers said that in order to fix this problem, only HTTP 303 codes should be permitted in OAuth."
Is OAuth 2.0 a no-go?
OAuth has some serious vulnerabilities, and even carefully following security recommendations to avoid an insecure implementation makes developing applications with OAuth risky. Critical applications requiring the highest security should probably skip OAuth 2.0 for now, until flaws in the protocol are fixed.
Image credit: Flickr
Keep learning
Get up to speed on Zero Trust security with TechBeacon's Guide.
Understand why API security needs access management with this Webinar.
Learn how how privilege and policy management improves your cyber resiliency in this Webinar.
Find out why Zero Trust means rethinking your security approach.
Answer this question: Is your environment adaptive enough for Zero Trust? Get this free white paper.
