JWT authentication and authorization schema

Question

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 ?

Answer 1

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.