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 :
- A user logs in with credentials gets a jwt of 20 minutes lifetime.
- 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.
- If it was never used to refresh it is accepted and used to issue a low grade access token.
- If the token was used before, or had different client+device+user than its parent offer a credential check (password or lockscreen code)
- 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.
- If lockscreen fails the user is presented with login screen.
The questions are :
- 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 )
- What are user experience problems an attacker can cause on the app while on this scheme ?