The accepted answer here as to why OAuth2 access tokens expire:
- Many providers support bearer tokens which are very weak security-wise. By making them short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token. (What does this mean? I take it to mean allow transmission without TLS? Anything else?).
- Large scale deployment don't want to perform a database lookup every API call, so instead they issue self-encoded access token which can be verified by decryption. However, this also means there is no way to revoke these tokens so they are issued for a short time and must be refreshed.
- The refresh token requires client authentication which makes it stronger. Unlike the above access tokens, it is usually implemented with a database lookup.
Assuming that we don't support non-encrypted transmission of the access token takes care of the first bullet point.
Assuming that we are fine with doing a database lookup against a revokable, completely random access token takes care of the second one.
For mobile apps, client authentication cannot be stronger, because "the client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret." (Google). That eliminates the third concern.
So what is the benefit of separating short-lived access tokens and long-lived refresh tokens in this scenario? Is it "okay" to just issue non-expiring access tokens and ignore the whole refresh token part?