3

I was going through Oauth2 docs and thought it was kind of permissive security wise, so i tried to implement JWT tokens with a special scheme like in the picture for a mobile app communicating with a web API.

Notes : i didnt like Oauth2 refresh tokens idea as they might get stolen and allow parallel usage (by legit and malicious users) unless you implement theft detection by rotating them (refreshing refresh token upon each request) in this case why use them at all ?

How the auth flow works :

  1. A user logs in with credentials gets a jwt of 20 minutes lifetime.
  2. Upon expiry the jwt gets refreshed by hitting the db checking if it's blacklisted (relogin) and if not check if it was used to generate a new token.
  3. If it was never used to refresh it is accepted and used to issue a low grade access token.
  4. If the token was used before, or had different client+device+user than its parent offer a credential check (password or lockscreen code)
  5. If passed, this check issues a new first grade token that blacklists all its parents and children on the db, its like a new first user login.
  6. If lockscreen fails the user is presented with login screen.

The questions are :

  1. What are possible security holes ? (I found two use cases : stolen valid access token lasts 20 minutes same issue as Oauth tokens. No gain no loss here. And stolen sleeping token : user not logged in for say 7 days, token gets stolen and used until user logs in again or token chain revoqued after 3months of persistance - our policy - and this theft has small chances since token has to be intercepted at the last request the user makes on the app , slimmer than stealing an Oauth2 refresh token )
  2. What are user experience problems an attacker can cause on the app while on this scheme ? jwt token flow
  • 1
    If you set your JWT in a cookie that is marked 'http-only' and transmit it via HTTPS, it should be quite safe from hijack vectors, or at least that's what I thought. More security is always good but I wonder if this is overkill. – jpodwys May 13 '16 at 1:03
  • @jpodwys i hate cookies lol. Did you spot flaws that are non existant in Oauth flows. – Asma Hakim May 13 '16 at 7:35
  • Hating cookies makes no sense to me. The alternative is to store your JWTs in local/seesionStorage which is more vulnerable to XSS than an http-only cookie. As for the algorithm, I can't comment on whether it's more secure than Oauth's. Perhaps posting an issue on Oauth's GitHub repo would be more likely to get you feedback from people intimately familiar with Oauth. – jpodwys May 14 '16 at 2:51
3

As @jpodwys says in his comment, HTTPS is a secure transit. It seems very unlikely to me that an attacker could steal an OAuth2 refresh token and not steal other critical information. That is, by the time you are having tokens stolen over HTTPS connections, you've already been pwned and it's game over. OAuth2 is a well-tested protocol that has many tested implementations in many languages. I strongly suspect that it will be more secure than anything that you choose to design and implement on your own. In general, rolling your own is a mistake. See all of these answers for reasons why.

In answer your question about why refresh tokens exist, they exist to allow the user to revoke authorization, not to deal with a stolen refresh token (as that effectively never happens). Consider the case where a user grants access and then later, abruptly revokes it. You want to minimize the delay between the revocation occurring to the revocation having effect. One way to bring the delay to (near) zero is by checking with the service provider on every call. But checking with the SP on every request isn't performant. Instead, you allow the access token to be used for a limited time period and force it to be renewed every once in a while. This means that if the user revokes authorization, it will take effect in a time no-longer than the life of the access token.

  • Stolen refresh tokens are possible thats why Oauth2 recommands their rotation (refresh with every request) and their revocation takes effect in the same time as the last token which is the same result with this scheme. I know self implemented solutions are prone to major error thats why i am trying to get it checked from different ressources. – Asma Hakim May 13 '16 at 7:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.