> For the complete documentation index, see [llms.txt](https://newrouge.gitbook.io/roguebook1/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://newrouge.gitbook.io/roguebook1/group/web/oauth-2.0.md).

# OAuth 2.0

Open Authorisation Framework

I started with PortSwigger Labs and i thinks it's the best resource for someone wanting to learn about OAuth and common vulnerabilities here. You can access it through here:  <https://portswigger.net/web-security/oauth>&#x20;

* OAuth 2.0 is completely different from OAuth 1, it's not a sequel of it.
* There are mainly 2 grant types used in OAuth i.e. "Authorization code" , "Implicit" grant.

## Components:

There are mainly 3 components in OAuth framework.

* CLIENT APPLICATION: Application that needs access of user's data to let user sign-up on their application.
* RESOURCE OWNER: Owner of data whose data is being requested.
* OAUTH SERVICE PROVIDER: Service where user's data is stored and client application is already registered with this service in order to use it e.g. Google, Facebook, Github etc.

## Recon:

* Identifying that OAuth is being used by client application. It's easy to do so when you see:

  * Signup with social media services, google, github etc.
  * A request like `/auth?client_id=a45tbk&redirect_uri=https://example.com/oauth&response_type=code&scope=openid%20profile%20email`&#x20;
  * `client_id`, `redirect_uri`, `scope` are good indicators of OAuth.

* Look up for these files on OAuth server:

  * `/.well-known/oauth-authorization-server`
  * `/.well-known/openid-configuration`

  <br>

## Vulnerabilities:

* Testing for if `state` parameter is tied to session of user otherwise CSRF like attack is possible.
* Check how OAuth service provider checks `redirect_uri` parameter. If you can put your server's url in `redirect_uri` parameter then you can successfully steal victim's authorization code or Access token, depending on the grant type, by sending the malicious url to victim.
* If redirect url is making a pattern matching check if you can try to bypass that checks e.g `legitwebsite.com@attacker.com`, `lgitwebsite.attacker.com`
* Check if you can find an open redirect on this website that can be used to proxy data to your server.
* Check if you can leak code to arbitrary page on client's website `https://client-app.com/oauth/callback/../../example/path` and if you find some vulnerability on `https://client-app.com/example/path` then you can leak OAuth code.
* Scope abuse, check if you can send scope parameter to ask more details then required.
* Check if anyone can register with OAuth service provider without any authorization.