2

I'm designing a new REST API for a mobile app service, which is something I've not yet had to do from scratch. I decided to use OAuth 2.0 with the Resource Owner Password Credentials grant.

Ideally, users should login once and remain authenticated forever, until they log out or access is revoked. I've read that I should use short-lived access tokens and a long-term refresh token, with the benefit being that even if the refresh token is stolen, you need the client secret to request a new access token, which itself could be revoked.

But mobile apps are considered public clients, which should not use client secrets, so is there actually any benefit to using refresh tokens in this situation, rather than just using long-lived access tokens?

1

You got it right: there is no actual benefit. A client secret within a public executable binary can easily be found. Either by analysis of the binary or network traffic sniffing. You can make it very difficult but not impossible.

However, i would strongly recommend against long lived access tokens. If one of these gets stolen you cannot revoke it. Its out there and valid for probably years. However, if you use refresh tokens and access tokens that live for hours at most you can prevent an attacker from getting hold of a new access token even if they manage to steal the refresh token.

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.