How does OAuth 2.0 actually solve the problem?

In order to see how OAuth 2.0 solves this problem of sharing resources, let's look at how this problem was solved before OAuth 2.0 was created.

Without OAuth 2.0 – GoodApp wants to suggest contacts by looking at your Facebook friends

Imagine that you have just signed up for the service GoodApp. As a new user, you don't have any contacts. GoodApp wants to suggest contacts for you to add by looking at your Facebook friends. If any of your Facebook friends are on GoodApp, it will suggest that you add them.

Before the creation of OAuth 2.0, this was solved in a very insecure way. GoodApp would ask you for your username and password for Facebook. GoodApp would then log into Facebook on your behalf to get your friends. This interaction can be looked at like this:

Here is how it works:

1. You ask GoodApp to suggest contacts to you.
2. GoodApp responds by saying, "Sure! Just give me your Facebook username and password please!"
3. You give GoodApp your username and password for your Facebook account.
4. GoodApp then logs into Facebook using your credentials, effectively impersonating you, to request your friend list.
5. Facebook happily obliges, giving GoodApp your friend list.
6. GoodApp then uses this information to tailor suggested contacts for you.

Why is this a bad idea? There are five key reasons:

• You have given GoodApp the power to do *anything* with your account: This is known proverbially as giving it the "keys to the city". You have essentially given GoodApp access to everything in your account, as if they were you. Now imagine it wasn't GoodApp. Instead it was NewUnknownApp. It's easy to see how this becomes very dangerous.
• GoodApp may save your password, and may do so insecurely: In order for GoodApp to maintain access to your account, they would need to store your credentials. The act of storing your password is an extremely bad practice and should be avoided at all times. To make things worse, different companies enforce different standards of security, some of which are shockingly low.
• You are giving more chances for your password to get stolen: You are sending your username and password across the Internet. The more times you do this, the more risk there is for someone to steal it.
• You have to change your Facebook password if GoodApp ever gets hacked: If GoodApp somehow got compromised, your Facebook credentials will also have been compromised. You would then need to change your Facebook password as a result of GoodApp getting owned.
• There is no way to revoke access: If GoodApp was acquired by EvilCorp and started doing things that you didn't like, the only way to revoke access would be to change your Facebook credentials.

With OAuth 2.0 – GoodApp wants to suggest contacts by looking at your Facebook friends

Now, let's take a look at that interaction, but this time utilizing the OAuth 2.0 protocol. In this scenario, GoodApp would "ask" Facebook for your friend list. You give permission to this by logging into Facebook and approving the request. Once the request is approved, GoodApp would then be able to fetch your friend list from Facebook on your behalf.

Let's have a look at the flow:

1. You ask GoodApp to suggest contacts to you.
2. GoodApp says, "Sure! But you'll have to authorize me first. Go here…"
3. GoodApp sends you to Facebook to log in and authorize GoodApp.
4. Facebook asks you directly for authorization to see if GoodApp can access your friend list on your behalf.
5. You say "yes".
6. Facebook happily obliges, giving GoodApp your friend list. GoodApp then uses this information to tailor suggested contacts for you.

Why is this better? Five key reasons to contrast the five points in the previous example:

• You aren't giving it the "keys to the city" anymore: Notice, in this example, you aren't giving your Facebook username and password to GoodApp. Instead, you are giving it directly to Facebook. Now, GoodApp doesn't have to even worry about your Facebook credentials.
• Since you aren't giving your credentials, GoodApp no longer needs to store them: With your authority delegated from Facebook, you don't need to worry that GoodApp is storing, or even seeing, your Facebook password.
• You send your password across the Internet less frequently: If you already had an active session with Facebook, you actually wouldn't need to reauthenticate with them. If GoodApp has federated identities with Facebook, you would have to send your password even less frequently.
• You don't have to change your Facebook password if GoodApp ever gets hacked: This is because of the next point.
• There is a way to revoke access: OAuth 2.0 provides the ability for a service provider to revoke access to a client. If GoodApp ever got compromised, or got acquired by Evil Corp, you could go to Facebook and revoke GoodApp's access.