# Flaws in Client Application > *Flaws in the client's application's implementation of OAuth.* ## Implicit Grant Type * The implicit grant type sends access tokens via the browser as a URL fragment. * If the app wants to maintain the session after the user closes the page, it needs to store the current user data, i.e., user ID and access token. It will often submit this data to the server in a `POST` request and then assign the user a session cookie. * The problem arises due to the fact that the server does not have any secrets/passwords to compare with the submitted data -> it is **implicitly trusted**. This request is exposed to attackers via their browser and can be leveraged for user impersonation.

Image taken from here.

### LAB: Authentication Bypass via OAuth Implicit Flow > **Goal**: Log into the application as `carlos`.
The access token provided (Step 3) is not tied with a specific user. If we change the email address, which in this case is used as the user identification, we can authenticate as any other user (Step 5).
## Flawed CSRF protection * The optional, but highly recommended, `state` parameter should contain the hash of something tied to the user's session when the OAuth flow is initiated. * If the authorization request does not contain the `state` parameter, it means that an attacker can potentially initiate an OAuth flow themselves before tricking a user's browser into completing it (similar to a classic CSRF attack). ### LAB: Forced OAuth Profile Linking > **Goal**: Use a CSRF attack to attach your own social media profile to `admin` and delete `carlos`. The authorization request has not `state` parameter and redirects to `/oauth-linking`. After copying the URL, we need to drop the request so the code will remain valid for use.
When the admin loads the `iframe` payload, it will complete the OAuth flow resulting in attaching their account to `wiener`'s social media profile. Thus, when `wiener`'s social profile is used to log into the application, the account will have elevated privileges.