2

In the OAuth2 Implict Grant flow, the access token is added to the URL fragment as part of the redirect from the Authorization Server to the Relying Party. Since this access token is made visible to the end-user in the Callback URL, this URL could be copied to a separate browser (or device), thereby allowing 2 independent browsers to use the same session.

For example, Medium's Facebook SSO login exposes the following Callback URL:

https://medium.com/m/callback/facebook#access_token=[ACCESS_TOKEN]&data_access_expiration_time=1646537637&expires_in=5162&long_lived_token=[LONG_LIVED_TOKEN]&state=[STATE]

This URL could be copied to another browser to allow access to the user's account on another device as long as the access token has not expired.

This could lead to a circumstance where login sessions are not properly logged, as the 2 browsers would be sharing the same session. This may also not be ideal where preventing concurrent sessions is necessary.

However, this type of flow, and the inclusion of the access token in plaintext in the URL, appears to be the standard practice when Oauth2 is used (In fact, https://portswigger.net/web-security/oauth appears to take for granted that the access token would be thus exposed, and just tries to limit the damage if an attacker were to get hold of the access token before it expires, e.g., by limiting the scope, recommending use of HSTS to prevent MITM, etc.). So what would be the best way to detect "session sharing", so that the proper authentication policies can be applied?

Rifa Achrinza
  • 125
  • 4

3 Answers3

0

Oauth2 tokens are designed to be shared over public channels, not for secret or encrypted channels.

That's why a oauth2 token should not contain sensitive information and should expire.

With this assumption, these tokens will be downloaded(after login) to the web browser or mobile app. In this sense, no matter if authorization code flow (backend sends the token to the web) or implicit grant flow (token is received directly on the url) are used, token will be accessible in the browser or mobile app.

Regarding to the session, tokens are not related to the session. Token is just a string in the web(spa) or mobile, to be sent to the backend (apis/microservices) commonly as an http header. Also this oauth2 token is related to the authorization

Session should be managed on the web (Session, cookies), android (SessionManager, SharedPreferences) or ios (UserSessionPrototype).

Check these links:

Session flow for webs

  • when your user enter to your web app, using some session manager you could detect if jane@doe has a valid prior session.
  • if not, redirect her to the login.
  • if user enter valid credentials:
    • you must give her a valid access_token
    • you must flag that jane@doe has a valid session, someone in the backend of web or in your security platform.

If the same user jane@doe tries to enter to the same web in another browser, device, network or different country, you web should be capable of detect this and show a message like "You have a valid session on another device..."

As you can see, oauth2 tokens are not related to the classic and standard way of session management of webs and probably on native mobiles.

Anyway if you want to use oauth2 to detect session sharing, it occurs to me that you can detect if the same access_token is being used from multiple sources ips. You will need to register the ips of your users, handle scenarios like connection from public networks, etc etc. As you can see, this is not a oauth2 concern

JRichardsz
  • 114
  • 2
0

Indeed, securing web apps 101 says "Don't do it. Always send sensitive data in POST requests rather than in query strings in URLs". With sensitive data in query strings, it becomes vulnerable to shoulder surfing and other attacks, as this security stack exchange page resoundingly explains.

And "Information exposure through query strings in url" on the OWASP web site gives an example that specifically includes authentication tokens:

https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for user, authz_token, and expire will be exposed in the following locations when using HTTP or HTTPS:

  • Referer Header
  • Web Logs
  • Shared Systems
  • Browser History
  • Browser Cache
  • Shoulder Surfing

The only reason I can think of that OAuth2 considers that it is ok, is that the access tokens have a short lifetime and are never reused. But maybe rather than looking for a way to detect session sharing with OAuth2, look for a more secure alternative to OAuth2.

auspicious99
  • 493
  • 3
  • 17
0

Copying the callback URL and using it in another browser will not work if the page checks the state parameter:

The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token. This will ensure that the client is not tricked into completing any redirect callback unless it is linked to an authorization request initiated by the client. The "state" parameter should not be guessable, and the client should be capable of keeping the "state" parameter secret.

(RFC 6819, Section 4.4.2.5)

If a user copies the URL to another browser, the state check will fail because the website does not recognize the state value since it did not started that authentication request.

The implicit flow with providing tokens in a URL callback is not state of the art nowadays and will be removed in OAuth 2.1.

Instead, the authorization code flow should be used. In this flow a short lived authorization code is included in the callback URL. This code can be redeemed at the token endpoint to obtain the tokens. This is also secured by requiring the client to authenticate with its client credentials and / or by using PKCE (Proof Key for Code Exchange by OAuth Public Clients, RFC 6749).

JuliusPC
  • 101
  • 3