I fully understand the benefits of refresh token in the case that Access Token gets compromised.

I send JWT access token to the server only through HTTPS for a mobile application and web application that needs lifetime login. So I believe the access token cannot be compromised unless user's device is in the attacker's hands. Again if user's device is with the attacker's hands then both refresh token and the access token would be compromised.

Is there any other way to compromise access token ? If NO, In my case, is it necessary to have refresh token system ?

UPDATE 1 : I use only single server. No seperate authentication server and resource server.

  • I don't understand why not just use HTTPS, since with the use of HTTPS you encrypt the content of the communication it's not only beneficial for the authentication, but also to protect the information of what is being transmitted through the Internet.
    – OiciTrap
    Jul 5, 2017 at 13:06
  • I've noted the edit, but I believe my answer still stands. It is possible for the resource server part of your application to have a leak while the authorization server part is still safe. Jul 5, 2017 at 13:12
  • @OiciTrap HTTPS is only for securing the information while it is being transported. It is not in itself an authentication mechanism. Explicitly identifying the user before setting up a session will be required if multiple people use the device. ("Mom, can I play Minecraft on the tablet?") Jul 5, 2017 at 13:15
  • I didn't say HTTPS is an authentication mechanism, I don't know what you are talking about.
    – OiciTrap
    Jul 5, 2017 at 13:18
  • @S.L.Barth But how could resource part of the server alone leak when entire thing is a single application. Also I repeat I use JWT token for authentication mechanism not HTTPS. Multiple users is still possible by giving different JWT token to different user. Jul 5, 2017 at 13:20

1 Answer 1


One major difference between Access Tokens and Refresh Tokens is who gets to see them.

The Access Token is handed out by the Authorization Server, and is then used by the client to gain access to the Resource Owner's resoures. The Access Token is seen by both the Authorization Server, the Client and the Resource Server.

The Refresh Token is handed out by the Authorization Server, and is only seen by the Client and the Authorization Server. The Resource Server never sees the Refresh Token.

So, the Access Token is more vulnerable; it is seen by more parties. A sloppy implementation on the Resource Server could lead to the leaking of the Access Token, while the Refresh Token would still be safe.

Credit: I had some help from this Stack Overflow answer writing this.
One scenario it mentions is that the Access Token might be sent as a query parameter, and then end up in a log file. The Access Token was protected by HTTPS during transit, but is now in the log file on the Resource Server. People who are not entitled to knowing the Access Token, might be entitled to see the log file. For example, students having a summer job as tech support.

What's important, though, isn't to try and invent a specific scenario in which things might go wrong. What's important is to realize that the Access token could leak with the Refresh Token still being safe. It's a form of defensive programming - be prepared for the case that there is a vulnerability in the Resource Server.

Since in the given situation the Authorization Server and Resource Server are a single application, most scenarios where the Access Token is compromised will also have a compromise of the Refresh Token.

As a side note, I've worked on a similar scenario. We used Identity Server as the Authorization Server. It was built into the application. If that application leaked, I would look to the Resource Server part first. Identity Server is built by security experts and, being Open Source, has been scrutinized by many. The Resource Server part of that particular application was proprietary. You may want to look at Identity Server for your application as well.

  • RFC 6740 explicitly requires that Refresh Tokens can be invalidated. I read somewhere that it does not require this for Access Tokens, but I'm not certain if that statement is correct. It would make sense to be able to invalidate Access Tokens, even if they're short-lived. Jul 5, 2017 at 13:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .