How does OAuth work in REST API?
Your thoughts?
OAuth 2 is an open-standard protocol for accessing data on a user's behalf without exposing the user's credentials.
Prior to the OAuth protocol, if an application wanted user data from another application, it would need to have the user's login credentials (username/password) to access the other application on the user's behalf...
This is bad for a couple of reasons. Requiring the user's credentials requires responsible and secure handling of that information. If the sensitive information is compromised then unauthorized users can access the user's account. It also gives the application unlimited access to the user's account as they have their password. Lastly, if the user updates their credentials then the client application has to manage the process of getting the updated credentials. All bad...
Using OAuth 2, client applications can securely access user data from another site without needing their username/password. It's important to remember that OAuth is a standard that resource servers/providers implement. For such reasons, there are subtle differences in how the OAuth flow can work.
With that being said, the high level flow involves redirecting the user to an authorization server where they login with their username/password. This authorization server verifies the user has correct information and redirects them back to the client application (the application that wants the user's Facebook photos as an example) with an authorization code. The client then calls the authorization server again with the authorization code to get an access token back. This access token is used to call the resource server so it a can retrieve resources in an "authorized" fashion.
So why so many hops? Why all the back and forth with getting a token just to get another token? By getting an authorization code first, the client application proves that it is allowed to get the access token...
Which brings us to grant types. The flow described uses an authorization code grant. Alternatively, an implicit grant allows a browser based application to retrieve the access token without the authorization code step. There is also a client credentials grant where an application can get a token with a username/password.
OAuth 2 protocol was defined around RESTful operations so you should be asking how OAuth works in general. That's like asking how does bash work with computers...
It is designed specifically for HTTP so it works with REST :)
give it a rest eh?
OAuth is specifically designed to work with HTTP aka REST APIs. This means the question should really be "How does OAuth work?"....
So how does OAuth work? What is OAuth anyways?
OAuth is short for Open Authorization. OAuth is a protocol for allowing users of web applications to access content from their accounts on other applications.
If you've ever "Signed in with Google" or accessed your Instagram photos from another site then you've experienced the OAuth 2 protocol.
So why does OAuth matter? Because without OAuth a user would have to give their credentials (username/password) to applications in order to get data from their Twitter, Facebook, Gmail accounts etc. This would be VERY bad because the application then has your username/password and can do whatever they want on your Twitter account etc.
OAuth is a secure way for applications to get some of your secured data in an authorized/secure fashion...
In terms of how it works...
Let's say you want to sign in with Twitter to access Pinterest.
In this case, Pinterest is considered the client and Twitter the resource server.
As the user, you are the resource owner.
When you click "Sign in with Twitter", you are redirected to an authorization server, in this case Twitter (making Twitter both the resource server and auth server which is common).
The auth server asks for your username/password and validates it's you.
The auth server redirects you back to the client (Pinterest) with an authorization code.
Pinterest calls the auth server (Twitter) with this code and gets back an access token.
Pinterest then uses this token to make authorized requests fo the resource server (Twitter).
This allows Pinterest to get your email address from twitter and sign you into their platform.
While different variations of this flow exist (grant_types), this is the general idea. Without collecting the user's username / password, an application is able to securely get user data from another application in a secure/authorized way.