This is one article written as part of my studies for the CompTIA Security+ exam. (SY0-601) Make me better by commenting below.
OAuth enables you (user) to authorize some of your identity information to an OAuth-enabled service without giving the OAuth-enabled service your password for the Identity Provider (which is hosting your identity information) . At about 15:00 minutes into the video in  is a good diagram that walks through this.
- Resource Owner – User (like me), who has the ability to say yes or no to sharing data
- Client – service
- Authorization Server – System that the user uses to authorize/approve sharing the data
- Resource Server – System or API that holds my data that the client wants
- Authorization Grant – Grant that says the user said yes. There are various types of grants (see RFC 6749, Section 4.1)
- Redirect URI/Callback – After the user clicks yes, where do I go back to the client
- Access token – How the client gets access to the Resource Server, the client exchanges the Authorization code for an Access Token. This is attached to the messaging to the Resource Server. The token has the authorized scopes.
Scopes are not Attribute Based Access Control. More Discretionary Access Control….
Scopes are granted per client. I think that’s important to call out. I did not come across explicit definition of the access control method provided by OAuth scopes. Based on my understanding, the OAuth 2.0 framework provides for Discretionary Access Control. This is based on the requirement that the user is granting access to its resources. This seems similar to a Linux user chmod’ing a file to give another user access.
I have asked the question to the stackoverflow community and will update based on the responses there.
Interesting that the protocol is divided into front channel (in the browser) messaging and then more secure back channel messaging. The exchanging of the authorization code for the access token is over the back channel, a secret key was exchanged/established between the client and the resource server ahead of time to allow for secure transmit of the authentication grant and the access token. During the token exchange, the secret key is passed.
Authentication v Authorization
OAuth wasn’t designed for authentication but sites started using it for this purpose. It is for authorization. There’s no way to get the user ID. In other words, services were using OAuth for authenticating of a user but the service wasn’t able to get the authentication information (so they added hacks).