How Oauth And Openid...

## What are OAuth 2.0’s Security Challenges and Vulnerabilities? The use of OAuth 2.0 for authentication delegation presents risks of vulnerabilities, whether or not OpenID Connect is implemented (although OIDC is now widely adopted). These vulnerabilities do not stem from the protocol itself, but rather from its implementations. They can be grouped into several categories: - Vulnerabilities in the OAuth client application: insufficient anti-CSRF protection, poor Implicit Grant management, over-reliance on the client OAuth server. - Leakage of authorisation codes or access tokens. - Vulnerabilities in the OAuth server: incorrect validation of scopes (scope upgrade). … - `**scope**`: Authorisation scope. Here, ‘openid profile’ gives access to user profile information defined by OpenID. - `**state**`: Anti-CSRF token containing a random and unpredictable value, to protect against cross-site request forgery attacks. These parameters, although necessary, can become points of vulnerability if they are poorly managed. In what follows, we explore the associated risks and how to prevent them. ... The state parameter is not mandatory in OAuth 2.0, but its use is strongly recommended. If this parameter is not activated, if it is not checked by the client application, or if it is predictable (non-random), a CSRF (Cross-Site Request Forgery) attack becomes possible. Example: A client application allows its users to link their account to a social network. ... … Without an anti-CSRF (`state`) mechanism, an attacker could steal access to a user account simply by getting them to click on a malicious link: `https://client-app.com/oauth?code=KJSUSIEGHBSHEOKJJSOIPE`. By clicking on this link, the user would unknowingly link their account to the attacker’s social network, enabling the attacker to log in using the victim’s social network credentials. … However, from a security point of view, it is crucial that the server checks that the information provided by the user corresponds to the access token. Without this verification, a user could falsify their data, for example by submitting an incorrect email address to access another user’s account. ### Overconfidence in the OAuth server This vulnerability is not specific to OAuth, but concerns authentication delegation mechanisms in general. It may also be present in authentication systems such as SAML. In the context of a multi-tenant client application, users can sometimes configure their accounts to delegate authentication to their own OAuth server. This is particularly useful because a client with centralised authentication (SSO) can use it to manage user access to the client application. … At this stage, the client application uses the user’s data (such as their email address) to associate it with existing accounts on the platform and thus create a session for the user on the corresponding account. **However, it is crucial that the client application server verifies that the OAuth server providing this information actually belongs to the server configured for the user’s account in question (for example, the email address).** In other words, the client application should never blindly trust the external OAuth server without verifying the data: as this server is under the control of external actors, it could return any email address (4.). If the client application does not check the correspondence between the email address and the OAuth server, an attacker could take control of another user’s account (5. and 6.). … ### Leaks of authorisation codes or access tokens During the OAuth authentication process, the response from the OAuth server is particularly sensitive, as it contains an element that is crucial for authenticating the user (be it a code, an access token or a JWS). If this element is intercepted, it is possible to compromise the user’s account. A common method of doing this is to manipulate the `redirect_uri` parameter. If the server does not validate this parameter correctly, or if it is too permissive, an attacker can redirect the user to a malicious platform instead of the client application. … The attacker, in possession of the authentication code, will then be able to access the user’s data. However, in general, the `redirect_uri` parameter cannot be manipulated in this way, as the OAuth server configuration allows the definition of specific domains or URLs that are accepted. In this case, the attacker could attempt an intermediate redirect by exploiting another open redirect vulnerability present on the platform. … - A malicious client application could exploit a user token to access more information than it is authorised to, by modifying the `scope` parameter when exchanging with the OAuth server. - As part of an Implicit Grant, an attacker could intercept a user’s token (for example, when it is sent by the browser) and contact the `/userinfo` endpoint of the OAuth server, while modifying the `scope`. This would potentially allow user data to be extracted, even if it was not in the initial scope of the token.