Download - 1000 ways to die in mobile oauth
![Page 1: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/1.jpg)
1000 Ways to Die in Mobile OAuth
Eric Chen, Yutong Pei, Yuan Tian,Shuo Chen,Robert Kotcher and Patrick Tague
![Page 2: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/2.jpg)
What is this work about?
● In 2014, Studied OAuth usage in 200 Android/iOS OAuth applications.○ 60% were implemented incorrectly.○ Pinpointed the security-critical portions in OAuth specs that were not
effectively communicated to mobile app developers. ● In 2016, these problems are not totally fixed, and new
problems are emerging…● How to do OAuth securely, especially for mobile?
![Page 3: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/3.jpg)
What is OAuth?
![Page 4: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/4.jpg)
Three parties in OAuth
Resource Owner Relying partyService Provider
![Page 5: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/5.jpg)
Service Provider
Authorization VS AuthenticationAuthorizationA process for end-users to grant a third-party website access to their private resources stored on a service provider.
Resource Owner
Relying party
?
![Page 6: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/6.jpg)
Authorization VS AuthenticationAuthorizationA process for end-users to grant a third-party website access to their private resources stored on a service provider.
Resource Owner
Relying party Service Provider
?
![Page 7: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/7.jpg)
Authorization VS AuthenticationAuthenticationA process for a user to prove his or her identity to a relying party, utilizing his or her existing session with the service provider.
Service Provider Resource Owner
?Relying party
![Page 8: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/8.jpg)
Authorization VS AuthenticationAuthenticationA process for a user to prove his or her identity to a relying party, utilizing his or her existing session with the service provider.
Service Provider Relying partyResource Owner
?
![Page 9: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/9.jpg)
Authentication
Service Provider
Resource Owner
Relying party
Authorization
Relying party
Service Provider
?
Resource Owner
?
![Page 10: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/10.jpg)
Brief history of OAuth
● (2007) OAuth 1.0 ● (2010) 1.0 Standardized through ietf ● (2012) OAuth 2.0 (has 4 “grant types”)
○ Authorization code grant○ Implicit grant○ Resource owner password credentials○ Client credentials
![Page 11: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/11.jpg)
Used by real world mobile apps
● (2007) OAuth 1.0● (2010) 1.0 Standardized through ietf ● (2012) OAuth 2.0 (has 4 “grant types”)
○ Authorization code grant○ Implicit grant○ Resource owner password credentials○ Client credentials
![Page 12: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/12.jpg)
For the rest of this talk
● Study the OAuth specs in terms of their security.○ Protocol versions: OAuth 1.0, OAuth 2.0 implicit flow○ Use cases: Authorization, Authentication
● Identify parts of the specification that were miscommunicated to mobile developers.
![Page 13: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/13.jpg)
OAuth 1.0
Register your application on the service provider
![Page 14: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/14.jpg)
UserService Provider Relying party
1. [App ID, Resource_type ]
2. Req TokenVerifies signature
● Signed with app secret● Resource_type can
be: email, user’s photos, etc
OAuth 1.0
![Page 15: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/15.jpg)
User
2. Req Token3. Req Token
4. User grants permission
5. Req Token
Verifies signature
Browser redirection
1. [App ID, Resource_type ]Service Provider Relying party
OAuth 1.0
![Page 16: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/16.jpg)
User
2. Req Token3. Req Token
4. User grants permission
5. Req Token 6. [Req Token]
7. Access Token
Verifies signature
Verifies signatureSigned with app secret
1. [App ID, Resource_type ]Service Provider Relying party
OAuth 1.0
![Page 17: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/17.jpg)
User
2. Req Token3. Req Token
4. User grants permission
5. Req Token 6. [Req Token]
7. Access Token
8. [Access token]
9. Protected resource: email, contact, etc
Verifies signature
Verifies signature
Verifies signatureSigned with app secret
1. [App ID, Resource_type ]Service Provider Relying party
OAuth 1.0
![Page 18: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/18.jpg)
OAuth 1.0 Security - Relying Party Identity
9. Protected resource
Relying party
4. User grants permission
Service Provider
Achieving security:The receiver of the protected resource must be the same principle that the user granted access to.
Untrusted
![Page 19: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/19.jpg)
User
2. Req Token3. Req Token
4. User grants permission
5. Req Token 6. [Req Token]
7. Access Token
8. [Access token]*
9. Protected resource
Verifies signature
Verifies signature
Verifies signature
1. [App ID, Resource_type ]
Service Provider Relying party
OAuth 1.0 Security - Relying Party Identity
* the secret is only known between the relying party and service provider
Relying party’s web server
![Page 20: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/20.jpg)
User
2. Req Token3. Req Token
4. User grants permission
5. Req Token 6. [Req Token]
7. Access Token
8. [Access token]*
9. Protected resource
Verifies signature
Verifies signature
Verifies signature
1. [App ID, Resource_type ]
Service Provider Relying party
Vulnerability - Locally stored secrets
Many applications decide to bundle this secret into their mobile apps.
Relying party’s mobile application
![Page 21: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/21.jpg)
Vulnerability - Locally stored secrets
![Page 22: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/22.jpg)
Vulnerability - Locally stored secrets
● After we notified Quora and Pinterest in 2014 ○ Both Quora and Pinterest revoked their
existing relying party secrets.○ Quora’s twitter authentication was non-
functional after our report.● Currently both not using twitter login
anymore...
![Page 23: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/23.jpg)
OAuth1.0a improvement User
2. Req Token3. Req Token
4. User grants permission
5. Req Token, verifier6. [Req Token, verifier]
7. Access Token
8. [Access token]
9. Protected resource
Verifies signature
Verifies signature and the verifier
Verifies signature
1. [App ID, Resource_type ]
Service Provider Relying party
Verifier is only sent to the registered redirect URL
OAuth 1.0a
![Page 24: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/24.jpg)
Locally store secrets + redirect URL
User
2. Req Token3. Req Token
4. User grants permission
5. Req Token, verifier6. [Req Token, verifier]
7. Access Token
8. [Access token]
9. Protected resource
Verifies signature
Verifies signature and the verifier
Verifies signature
1. [App ID, Resource_type ]
Service Provider Relying party
Evernote doesn’t checkThe redirect URI
Get the local secrets of a benign app to fake the login
Change the callback URI
![Page 25: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/25.jpg)
Security critical design and implementation for OAuth1.0/a
● Relying Party○ Do not bundle client secret in the client side
● Service Provider○ Register the redirect URI and check the redirect URI
● Or…
![Page 26: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/26.jpg)
Use OAuth2
![Page 27: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/27.jpg)
OAuth 2.0 implicit flow
User Service Provider Relying party
2. User grants permission
3. Access token
4. Access token
5. Protected resource
1. App ID, Resource_type, redirect URI
1. No relying party secret!2. No signature/encryption.3. Access token is not bound
to a RP
Verifies redirect URI
Relying party must supply a “redirect URI” to receive access tokens from the service provider
![Page 28: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/28.jpg)
Handling redirection in Implicit flow
User Service Provider Relying party
2. User grants permission
3. Access token
4. Access token
5. Protected resource
1. App ID, Resource_type, redirect URI
Verifies redirect URI * *The receiver of the access
token must be the same as the registered redirect URI
Browser redirection (HTTP 302)
![Page 29: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/29.jpg)
Handling redirection in mobile applications
spotify server
User’s device
Facebook server
Access token Access token
intent://token
The “intent” URI- scheme is registered by the receiving relying party application
![Page 30: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/30.jpg)
Handling redirection in mobile applications
spotify server
User’s device
Facebook server
Access token
Access token
intent://token
attacker server
The attacker can registerand overwrite the callback for the “intent” scheme
![Page 31: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/31.jpg)
Handling redirection in mobile applications
● Secure redirection using Android Intents:○ Each application is signed using a developer key.○ We can check the developer’s key hash of the intent receiver.
relying_party = Activity.getCallingPackage();
dev_key_hash = getPackageManager().
getPackageInfo(relying_party, PackageManager.GET_SIGNATURES);
![Page 32: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/32.jpg)
Using Implicit Flow for Authentication
User Service Provider Relying party
2. User grants permission
3. Access token
4. Access token
5. Protected resource
1. App ID, Resource_type, redirect URI
Verifies redirect URI
The OAuth 2.0 implicit flow is not secure for authentication
The access token is not bound to a relying party
![Page 33: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/33.jpg)
Vulnerability - Using authorization flow for authentication
● Vulnerability in Wish’s Android application using FB login:
Attacker server
Smartphone
AuthenticatesAccess token
Bob
Facebook server
Access token
Wish server
Smartphone
Authenticates
Access token
Attacker
Facebook server
Access token
Access tokenUser ID
![Page 34: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/34.jpg)
● Facebook also supports a modified implicit flow for authentication.
User Service Provider Relying party1. App ID, redirect URI
3. Access Token2. User grants permission
5. User’s FB ID
4. [Access Token]Verifies redirect URI
Verifies appsecret_proof
cryptographic hash of the access token using the relying party secret
Vulnerability - Using authorization flow for authentication
![Page 35: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/35.jpg)
User Service Provider Relying party1. App ID, redirect URI
3. Access Token2. User grants permission
4. [Access Token]Verifies appsecret_proof
5. Proof succeeded
6. proof succeeded
Verifies redirect URI
8. User’s FB ID
7.Access Token
● Keek’s (vine-like app with 65 million users) “appsecret_proof” flow
Sent between the user’s device and the service provider
Vulnerability - Using authorization flow for authentication
![Page 36: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/36.jpg)
User Service Provider Relying party1. App ID, redirect URI
3. Access Token2. User grants permission
4. [Access Token]Verifies appsecret_proof
5. Proof succeeded
6. proof succeeded
Verifies redirect URI
8. User’s FB ID
7.Access Token
● Keek’s “appsecret_proof” flow
Sent from the client’s device
Vulnerability - Using authorization flow for authentication
![Page 37: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/37.jpg)
Distribution of authentication methods for Facebook relying parties:● Using unmodified implicit flow: 84.7%● Using wrongly implemented app_secret proof 1.3%● Using correctly implemented app_secret proof 14%
● Bounty reward from Instagram (Facebook)
Vulnerability - Using authorization flow for authentication
![Page 38: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/38.jpg)
OpenID Connect ID token - signed JWTeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCaGRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwLCJpYXQiOjEzMTEyODA5NzAsImF0X2hhc2giOiI3N1FtVVB0alBmeld0RjJBbnBLOVJRIn0.VW_s1XIAkhlFTfx90VjofHjbRqM5MEtMA5mlctc7dCE
Payload: { "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "at_hash": "77QmUPtjPfzWtF2AnpK9RQ" }
![Page 39: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/39.jpg)
OAuth 2 Code Authorization Flow
User Service Provider Relying party
2. User grants permission
3. Authorization Code
4. Authorization Code
5. Access token
1. App ID, Resource_type, redirect URI
Verifies redirect URI
6. Access token
7. Protected resources
![Page 40: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/40.jpg)
Code Authorization Flow- verify the code
User Service Provider Relying party
2. User grants permission
3. Authorization Code
4. Authorization code + client credential
5. Access token
1. App ID, Resource_type, redirect URI
Verifies redirect URI
The authorization code should be one-time password
6. Access token
7. Protected resources
The service provider should verify that the authorization code belongs to the same relying party
![Page 41: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/41.jpg)
Vulnerabilities- not verifying the codeVulnerability in Sohu news app with Sina login:
Attacker server
Android
AuthenticatesAuthorization code
Bob
Sina server
Authorization code
Sohu server
Android
Authenticates
Authorization code
Attacker
Sina server
Authorization code
Authorization codeAccess token
![Page 42: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/42.jpg)
Security critical design and implementation for OAuth2
● Do security checks in the server side● Verify the receiver and sender of security-
critical content such as code and token
![Page 43: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/43.jpg)
Lake of Consent Information- Tencent
User Service Provider Malicious Relying party
2. User logs into Tencent3. Access token,
[App ID, User ID]
1. App ID, redirect URI
Verifies redirect URI
4. Access token, [App ID, User ID]
● No information about relying party for Tencent mobile UI
User’s device App ID is public information
The user sees the same Tencent login-dialog for all relying parties
![Page 44: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/44.jpg)
Impacts
User Service Provider Malicious Relying party
2. User logs into Tencent3. Access token,
[App ID, User ID]
1. App ID, redirect URI
Verifies redirect URI
4. Access token, [App ID, User ID]
● No information about relying party for Tencent mobile UI
User Service Provider Relying party
2. User logs into Tencent3. Access token,
[App ID, User ID]
1. App ID, redirect URI
Verifies redirect URI
4. Access token, [App ID, User ID]
User’s device Attacker’s device
~700 million users affected.
Tencent acknowledged the vulnerability and patched it within a week.
![Page 45: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/45.jpg)
No Consent Page- Sina
Sina doesn’t show consent page if the user logs in her Sina account
Attacker
Bob
Attacker sends a phishing link
Attacker’s app is approved without consent
![Page 46: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/46.jpg)
No State Token
Relying party should use state token to identify the login session Smartphone
Login attacker’s account
Attacker
Github server
Phishing link to attacker’s account
Bob will be logged into attacker’s account
Bob
Smartphone
![Page 47: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/47.jpg)
Mobile Webview
Service provider should not provide long term cookie in the webview login
Webview provides the feature that app can get the cookies from the webview it embeds
Facebook uses long term cookie even inside webview, and attackercan reuse the cookie to log in as the user.
![Page 48: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/48.jpg)
How to use mobile OAuth securely?
● Service provider○ Verify the Identity of the token/code receiver ○ Consent page○ Set short term cookie for webview○ Adopt OpenID connect for authentication
● Relying party○ Do not trust the client
■ Do not store content locally■ Perform security checks on the server
○ Choose the right flow and follow the flow
![Page 49: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/49.jpg)
Summary● Studied OAuth usage in 200 Android/iOS OAuth
applications.○ 60% were implemented incorrectly.
● Dissected OAuth specifications for security.○ Initially designed for authorization, not authentication!○ Initially designed for web, not mobile!
● The OAuth Working group should provide clear usage guidelines for mobile platforms
![Page 50: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/50.jpg)
Thank you
![Page 51: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/51.jpg)
What is this work about?
![Page 52: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/52.jpg)
Why so many vulnerable applications?
● Specifications were written for authorization, not authentication.
● Specifications were written for web applications, not mobile applications.
![Page 53: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/53.jpg)
Our study
● Field study of 200 Android/iOS applications○ 133 were taken from top 600 ranked applications in
app stores○ 16 were manually selected (Quora, Weibo)○ 16.8% service providers, 84.5% relying parties, 1.3%
both● 59.7% of these applications were vulnerable
to attacks
![Page 54: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/54.jpg)
Differences between web and mobile platforms
1. Different redirection mechanisms○ HTTP 302 Vs. iOS custom schemes or intents
2. Lack of application identity○ No concept of “Origin” for mobile applications
3. Client-side heavy protocol logic○ Observation: mobile apps have heavier clients
![Page 55: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/55.jpg)
Differences between web and mobile platforms
1. Different redirection mechanisms○ HTTP 302 Vs. iOS custom schemes or intents
2. Lack of application identity○ No concept of “Origin” for mobile applications
3. Client-side heavy protocol logic○ Observation: mobile apps have heavier clients
![Page 56: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/56.jpg)
Motivation
Oauth is designed for authorization, but is used for authentication
![Page 57: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/57.jpg)
User
2. Req Token3. Req Token
4. User grants permission
5. Req Token 6. [Req Token]
7. Access Token
8. [Access token]
9. User_ID
Verifies signature
Verifies signature
Verifies signature
1. [App ID, “User_ID_Type” ]
Service Provider Relying party
OAuth 1.0 - Authentication
Unique FB ID that identifies the user
![Page 58: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/58.jpg)
4. User grants permission
9. User_ID
OAuth 1.0 authentication security
User Service Provider Relying party
User is untrusted
Achieving security:● Sent from the service provider and
cannot be tampered by the user.
● Only the approved relying party can receive the user’s ID.
![Page 59: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/59.jpg)
2. Req Token3. Req Token
4. User grants permission
5. Req Token 6. [Req Token]
7. Access Token
8. [Access token]
9. User_ID
Verifies signature
Verifies signature
Verifies signature *
1. [App ID, User_ID ]
OAuth 1.0 authentication security
User Service Provider Relying party
Cannot be tampered by the attacker
* Signature verification binds an access token to the issued party
![Page 60: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/60.jpg)
General OAuth Security
● User’s consent○ Need to display the app’s name and icon, and
scopes that we be granted● Session identifications
○ Need to use state token to identify the session, or else attackers might trick users to log in on behalf of them
![Page 61: 1000 ways to die in mobile oauth](https://reader034.vdocuments.mx/reader034/viewer/2022042619/58729d3d1a28ab07208b4f9b/html5/thumbnails/61.jpg)
Take a way
● Service provider○ Checking logic on the server side○ Consent page○ Set short term cookie for webview
● Relying party