3

I know the concept of OAuth2 and OpenID. in our application authentication is happening through OKTA and we receive access-token in a response. Our architecture is a microservice-architecture and we are using EmberJS at frontend.
we have to implement remember-me functionality it will keep the user logged in for the next 30 days. I did some study on it and came to points that will satisfy my requirements.

  1. keep user session active for 30 days in OKTA.
  2. refresh access token periodically based on its expiry time.

How this refreshing will work if browser is closed? Let's say a user is logged in and closed the browser then reopened it after 3 days.

Sanjay
  • 1,958
  • 2
  • 17
  • 25

1 Answers1

1

With respective to OAuth 2.0 best practices, it is recommended to have short lived access tokens. There is a dedicated RFC definition such best practices which is identified by RFC6819 - OAuth 2.0 Threat Model and Security Considerations. There are several sections which emphasise on using short lived access tokens .For example here you can see why it is recommended.

With this perspective, you may handle this situation using browser cookies. Cookies are the mechanism which helps browser and server to maintain states. In a typical web application, login state can be maintained through cookies. There are two variants of cookies.

  1. Session cookie
  2. Persisted cookie

The second cookie type, persisted cookies do not go out of browser when browser is closed. Of course user can clear cookies to remove them. In your scenario, you can set such a cookie to user with desired lifetime. In the backend, you need to map cookie value to a state, which should start when backend receive a valid access token/ ID Token (after authentication and authorization step).

About cookies security, there are many things you must concentrate on. But the most important are setting cookie to be secure and HttpOnly.

Also, you may store a reference to refresh token in backend correlating to the cookie. Then for each fresh usage you can use refresh token to obtain access token if you require for example API access with access token.

Community
  • 1
  • 1
Kavindu Dodanduwa
  • 12,193
  • 3
  • 33
  • 46
  • Is there any benefit of storing a refresh token in cookie instead of local storage? – jelhan Sep 02 '19 at 15:17
  • @jelhan you should not store refresh token as it is in front end of an application. It must be persisted in a backend. Of course you may correlate it to cookie with some sort of hashing. But be extra careful in such a situation. – Kavindu Dodanduwa Sep 02 '19 at 16:55
  • Stroring a refresh token on authorization server only doesn't make much sense. You wouldn't need such a token at all in that case. https://tools.ietf.org/html/rfc6819#section-3.3 is also very clear that refresh tokens are meant to be used and hold by client. – jelhan Sep 02 '19 at 19:58
  • 2
    @jelhan please go through best practice recommendations https://tools.ietf.org/html/rfc6819#section-5.3.3 . Refresh token must be protected as if it is set of credentials. That's the reason you must not store it as it is where malicious party can access them. Specially in its pure form. And depending on application type, thing differ too - https://tools.ietf.org/html/rfc6819#section-4.1.2 – Kavindu Dodanduwa Sep 03 '19 at 05:26
  • 1
    @jelhan Also, it's not about storing refresh token in authorization server. It is storing with client application (client of authorization server). Do not get confused about word client. – Kavindu Dodanduwa Sep 03 '19 at 05:48