OAuth 2.0 roles:
Resource owner: The resource owner is simply the user that is interested in granting a registered OAuth application to access their account. Again, there’s no disclosure of passwords here or full access to the account. The extent to which the user data can be accessed is defined by scope. Different scope results in different kinds of OAuth 2.0 permission dialogs. Generally, scopes allow permissions such as read or write access to the account data, but it’s up to the provider to declare scopes as per their usage.
Client:A client is simply an application registered to the provider (say Facebook/Google+) and is used by the third party to access or manipulate a user’s or resource owner’s data. This concludes that a client is merely an application which allows the third party to request on behalf of the resource owner to the OAuth provider.
Resource server: A resource server contains protected information or user data which can be accessed by the means of access tokens. Simply put, a resource server allows/denies access of a specific resource to an application.
Authorization server: An authorization server is capable of granting or denying a client an access token. The authorization server authenticates the resource and, generally through various interactions, issues an access token to the client if everything goes well. A resource server and authorization server are closely knit and when in the same web application, often referred to as an OAuth API.
The application: The application or client must be registered on the OAuth provider’s website. The registration process involves the third party fill-out details, such as application name, website link, logo, configuration data, and so on. Once the registration is done,an application is assigned a unique identifier called the client ID.
Redirect URI: Every application must redirect to a pre-determined URI once the OAuth flow is complete. By default, the authorization server rejects redirect_uri mismatches between application configuration and the actual one provided. The redirect URI is a crucial component of the OAuth flow, and hijacking this can result in nasty outcomes, which we’ll see in upcoming sections of this chapter. Access token An access token is a secret token allotted to the application and is tied to a particular user with specific permissions. The resource server expects an access token every time a request is made to it.
Client ID: The client ID is a unique identifier that is returned when the application is registered successfully. It is not secret information and is crucial in the working of OAuth applications. Different OAuth implementations refer to the client ID differently, for example, Application ID.
Client secret: Client secret is a unique token generated during the registration process and is tied to the client ID. As the name suggests, a client secret is private information and shouldn’t be exposed. It is used internally while generating access tokens.
There are different types of vulnerabilities identified due to incorrect implement of oauth.I have listed down few vulnerabilities that I have gone through.
Note:The list will be updated whenever I read something new and interesting.
If you like the content, please follow me on medium and LinkedIn
LinkedIn: https://www.linkedin.com/in/pravin-r-p-oscp-28497712b/
