What is OAuth?
Let’s demystify OAuth by starting with a definition. At its core, OAuth provides clients secure access to a server’s resources on behalf of a resource owner. OAuth allows access tokens to be issued to third-party clients by an authorization server with the approval of the resource owner (i.e Facebook profile). The third-party can then use the token to access protected resources hosted by the resource server. If you were ever asked by an application to give permissions to access your personal data, such as sharing your Facebook or Google contacts, you have more than likely used OAuth.
Unfortunately, there’s a lot of confusion around the use cases of OAuth, which starts with some fundamental misconceptions. So in this article, we’re going to be looking at some of these misconceptions and analyze why you shouldn’t use OAuth for authentication purposes.
OAuth: Authorization vs. Authentication
Before we delve further into the pitfalls of OAuth authentication it is important to note the differences between authentication and authorization.
- Authentication is the process of verifying identity.
- Authorization is the process of giving the user permission to access a specific resource or function.
The two are often wrongly used interchangeably, this will be of note in the next section.
OAuth Isn’t Meant For Authentication
When a client uses OAuth, a server issues an access token to a third party, the token is used to access a protected resource, and the source validates the token. Notice, that at no point is the identity of the owner of the token verified.
You can think of a token issued by a resource server like it’s a ticket to a movie. Nowhere on the ticket does it say any identifying information about an individual, it simply is used as a way of saying I have permission to enter.
More so, an access token doesn’t represent or indicate a user is authenticated. This means that the issued token may be in the hands of a bad actor or a machine. It’s impossible to know!
Access Tokens Can Contain Anything
There is no standard structure for an access token. The token isn’t meant to be understood by the client, it is meant to be validated by the resource server. This means that the token can theoretically contain anything and the client would have no way of knowing.
A bad actor can easily inject a leaked or stolen access token (and impersonate the resource server) when the client accepts access tokens. This comes from the fact that clients assume that only the resource owner can present it with a valid access token for that resource.
OAuth Risks Cross-Site Request Forgery
A Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. Let’s take a look at how I could potentially use CSRG with OAuth.
- I visit some client’s websites (Facebook, Google, etc.) and start the process of authorizing that client to access some service provider using OAuth.
- The client asks the service provider for permission to request access on my behalf, which is granted.
- I am redirected to the service provider’s website, where I would normally enter my username/password to authorize access.
- Instead, I trap/prevent this request and save its URL.
- I somehow get you to visit that URL instead. If you are logged in to the service provider with your own account, then your credentials will be used to issue an authorization code.
- The authorization code is exchanged for an access token.
- Now my account on the client is authorized to access your account on the service provider.
There is just no way for a client to be sure that no one cut and paste a token from a different request.
Replace Tokens With Certificates With SecureW2
If you want to authenticate users, there is no better method than X.509 digital certificates. A certificate is tied to the identity of a user and device for the life of the certificate. The certificate cannot be transferred to another device, so the users on your network are always correctly identified.
Certificates provide a substantial upgrade to network security and user experience as proper usage of certificates can eliminate the threat of Man-in-the-Middle attacks and password-based headaches.
Many organizations hesitate to implement certificate solutions because of the historic difficulties of issuing certificates. However, SecureW2 provides a #1 rated JoinNow onboarding software. This software allows end-users to self-enroll for certificates in just a few minutes. Once enrolled, they can be easily authenticated to your network and applications safely and securely.
SecureW2 provides everything an organization needs to use digital certificates for automatic authentication to a network. For more information about our cost-effective solution, check out our pricing page.
