OAuth is a popular web application security feature that allows you to sign in with a third-party provider, such as Facebook or Google, to access your account. This can help protect your data from unauthorized access and help you stay secure on the web. There are many benefits to using third-party sign-on, including: You can be more secure online: By using a third-party provider, you can be sure that your data is being protected by someone who has a strong track record of safeguarding user data. This will help keep you safe from potential cyber threats and protect your personal information from being accessed by unauthorized individuals. By using a third-party provider, you can be sure that your data is being protected by someone who has a strong track record of safeguarding user data. This will help keep you safe from potential cyber threats and protect your personal information from being accessed by unauthorized individuals. You can save time: By signing in with a third-party provider, you can save time signing in to each website and application multiple times. This will help reduce the amount of time it takes for someone to gain access to your account if they are able to guess your password or crack the security code on an old device. By signing in with a third-party provider, you can save time signing in to each website and application multiple times. This will help reduce the amount of time it takes for someone to gain access to your account if they are able to guess your password or crack the security code on an old device. You can be more confident online: By using a third-party provider, you have greater confidence that the site or application is legitimate and not just another scam attempt designed to steal your money or personal information. This way, you know that any site or application claiming to be related to yours is likely legitimate and not just tryingto take advantage of users’ trust issues.
OAuth gets rid of the need to store confidential user passwords on your server. Instead, the user trusts you to access their basic profile information from a service like Google, who handles the authentication for you.
Third-Party Sign-on Frees You from Handling Passwords
Third-party sign-on is an alternative to username/password authentication. You’ve definitely encountered this before if you’ve ever been asked to log in with Google or Facebook—you simply authenticate with your social media profile without putting in any passwords.
It’s easier to talk about the problems with the alternatives. If you didn’t want to utilize third-party authentication, you’d have to handle it all yourself. This means you’ll be responsible for storing your user’s passwords, which isn’t impossible if they’re properly salted and hashed. But it’s a hassle, and you don’t want to be responsible for any potential data breach involving passwords, even if they’re stored properly.
Third-party sign-on eliminates the chance of that happening, because you’ll never handle anything private at all. That job is left up to Google, Facebook, and any other OAuth provider. Even if your entire server network is compromised, you won’t have access to anything except publically viewable social media profiles.
What’s the Downside?
Theoretically, there’s nothing different about OAuth compared to password auth; it’s just a different way of signing in. But in practice, OAuth does raise a few issues.
First, you must trust the OAuth provider to securely handle your user’s data. This isn’t really your problem though, as any breach on their side doesn’t affect your service. But control over users signing in is handed off to the provider, which some people may not be okay with.
The user must also trust you to authenticate with the provider, and they must also have an account with one of the providers. The solution to this is to offer multiple providers; a user may not want to sign up with their Facebook account, but they may be okay signing up in with their Gmail account.
However, this presents another problem unique to OAuth—users can create multiple accounts on accident. Often, the sign-up process is the same as logging in, because it’s handled in the same flow. This can lead to users forgetting which account they signed up with, and accidentally signing up with a new account. This could even be a violation of the GDRP if it’s not handled properly. You’ll want to make sure “Sign Up” and “Log In” are handled separately.
How Does It Work?
Third-party sign-on uses OAuth 2.0 for authentication. OAuth is a collection of standards, and there are many different OAuth flows for different use cases. The most common one used for social sign-on is the Authorization Code Flow.
In the auth code flow, your server delivers your web app as usual to the client. When they click “Sign Up,” they’ll be redirected to your sign-in page with the OAuth provider (Google, in this example). You’ll have to register your application with Google and provide some info that your users will see. Google will ask the user if it is okay if your application accesses their profile information.
If the user accepts, Google redirects them to a callback URL with an authorization code.
This authorization code functions as the key to the user’s account. Though it isn’t exactly a key; it’s more like an IOU where the client confirms that the server is allowed to access the account. It’s only allowed to be used by your server.
It is only used once, as your server will immediately pass the key to Google to get an access token and ID token, which is used to actually access the user’s account. Optionally, you can request a refresh token to update the access token after it expires, without prompting the user for another authorization code.
In this flow, you’re only requesting access to view basic profile information, so you can identify the user. This is called your scope, which is the amount of data and number of functions you’re allowed to access. Each OAuth provider has different scopes (here’s a list of Google’s), and you can also use OAuth for administrative access to accounts, such as services that would need to access a user’s inbox or Google Drive account.
How Do I Set It Up?
We’ll use Google’s OAuth libraries for this example, as they’re simple to set up. But Facebook, Github, and Twitter all are popular OAuth providers as well, and it’s a good idea to implement at least two providers into your application. And if you’re developing an iOS app, you’re required to implement Apple as an OAuth provider through their Sign In With Apple program (if you’re using third-party sign-on in the first place).
First, head over to the Google API Console, and create a new project. Select “Web Browser” as the client type, and specify your origin URL.
Next, include the Google platform library as a script on your site:
And include your client ID as a meta tag in your site’s header:
You can implement the button yourself, or use their prebuilt one:
From there, users should be able to fully authenticate. But this button defines a callback, “onSignIn,” where you’ll want to perform all the processing you need. For example, you could ask Google for basic profile information on the user:
If you’re authenticating further with a backend server, you’ll want to send ID tokens rather than profile information, as these can be validated by the server.
If you don’t want to set this up yourself, you can use Auth0, which is free for up to 7,000 monthly users, and also supports Touch ID and two-factor auth. Or you can use another library like react-google-login, which will handle this process in a React app.
