What is OAuth?
The basic OAuth process is widely used to integrate third-party functionality that requires access to certain data from a user’s account. For example, an application might use OAuth to request access to your email contacts list so that it can suggest people to connect with. However, the same mechanism is also used to provide third-party authentication services, allowing users to log in with an account that they have with a different website.
Each party maintains an authentication model that is defined by the OAuth 2.0 standard to support OAuth flow from application to application: the authorization code (client authorization code) is signed by an OAuth provider, the client app sends an authorization header specifying the request type (which may include a grant or read-only flag), and then the resource owner of the given API requests its access rights. All this is in the HTTP headers, and most of HTTP is handled by a middleware. So by creating a resource-specific OAuth 2.0 middleware, you can create flow that shares access.
How is OAUTH implemented?
The user chooses the option to log in with their social media account. The client application then uses the social media site’s OAuth service to request access to some data that it can use to identify the user. This could be the email address that is registered with their account, for example. After receiving an access token, the client application requests this data from the resource server, typically from a dedicated endpoint. Once it has received the data, the client application uses it in place of a username to log the user in. The access token that it received from the authorization server is often used instead of a traditional password.
0Auth Security issues
Vulnerabilities in OAuth authentication emerge mainly because the design of OAuth is relatively vague and flexible by design. Even though basic functionality of each type of grant requires a handful of required components, the large majority of the implementation is purely unnecessary. This requires several configuration settings required to keep the data of users secure. Let us look at them in detail:
Implicit grant type
Given the risk involved with submitting access tokens through the browser, the implicit grant form is primarily preferred for single-page applications. Nevertheless, because of its minimal effort, it is most often used in traditional client-server web apps.
In order to address these issues, the client program will also send this data to the server in a POST request and then allocate a session cookie to the user, essentially logging in. This request is approximately equal to a query for submission of a form that may be submitted as part of a standard passcode login. Even so, in this case, the server does not have any secrets or keys to contrast with the data sent, that indicates that it is implicitly trusting.
Flawed CSRF protection
Imagine a platform that allows users to log in using either a conventional password-based system or by connecting their account to a social media profile using OAuth. For this scenario, if the program fails to use the state parameter, the hacker may probably hijack the victim user account on the client application by linking it towards their own social media page.
Understand that if the site requires users to log in explicitly through OAuth, the state parameter is possibly less important. Nevertheless, not using a state parameter will also cause attackers to create a CSRF login attack from which the user is fooled into signing in to the intruder’s account.
Optimally, the state parameter will include a random value, like the hash of anything connected to the user’s state when it first initiates the OAuth stream. This attribute is then transferred back and forth through the client application and the OAuth provider as a CSRF token for the client application. Consequently, if you find that an authorization order does not give a state parameter, this is incredibly fascinating from an intruder’s point of view. It theoretically means that they can start OAuth’s own flow before tricking a user’s browser to complete it, equivalent to a conventional CSRF attack.
Leaking authorization codes and access tokens
Presumably the far more prominent OAuth-based flaw is where the OAuth service configuration itself allows attackers to intercept permission codes or access tokens shared with other clients’ accounts. By taking a legitimate code or key, the intruder can be able to enter the data of the victim. At the end of the day, this will totally break their account-the intruder might theoretically log in as a victim user to any client program associated with this OAuth service.
Based on the grant form, a code or a token will be sent to the endpoint defined in the redirect uri parameter of the authorization request through the user’s browser. If the OAuth service fails to verify this URI appropriately, an intruder could be able to create a CSRF-like exploit by deceiving the victim’s browser to trigger an OAuth process that sends a code or token to a hackers redirect url.
The most stable authentication systems will need the redirect uri parameter to be transmitted when the code is shared. The server will then verify if this compares to the one it got in the original request for authorisation and, if not, refuse the exchange. As this happens in server-to-server requests through a protected side, this second redirect uri parameter cannot be managed by the attacker.
Unverified user registration
While verifying users via OAuth, the application program implicitly assumes that the data stored by the OAuth provider is accurate. It could be a risky conclusion to reach. Most platforms that have an OAuth service allow users to register an account without checking all their data, such as their email address, in such cases. An hacker will make advantage of this by setting up an account with the OAuth provider using the same information as the intended customer, perhaps with a recognized email address. Customer requests can then enable the attacker to sign up as a victim via this fake account with the OAuth provider.
How to prevent OAuth authentication vulnerabilities?
Here are a few guidelines:
- To mitigate vulnerabilities in OAuth authentication, rigorous verification of key inputs, in particular the redirect uri parameter, is necessary for both the OAuth provider and the client program. There is little constructed security in the OAuth framework, and therefore it is up to the programmers alone to render the OAuth flow as safe as possible.
- Mandate a client program to register a whitelist with appropriate redirect uris. Whenever practicable, use a strict byte-byte relation to verify the URI for any incoming requests. Enable only complete and correct matching instead of pattern recognition. This prohibits hackers from reaching other sites in whitelisted domains.
- Enact the state parameter to be using. Its value should also be connected to the user’s session by adding any unforeseen, time data, such as a hash comprising that session cookie. Which actually protects users from CSRF-like vulnerabilities. This even makes it incredibly difficult for a hacker to use the compromised codes of authorization.
- Please ensure that the access token has been given to the same client id that the request is made. You can also review the area sought to ensure that this corresponds to the field in which the token was initially issued.