< https://security.stackexchange.com/questions/205837/openid-connect-is-sto... > Hi, I'm currently in the phase of integrating my web-site to OpenID Connect provided by KeyCloak. The web-site is not a single page application. However, different parts of the application are delivered by different web services. In each site delivered by these different web services, the user can call a standard REST API. This REST API can only be accessed with an access token received from KeyCloak. Thus, the user needs to log-in on the web-site using authorization code flow of OpenId Connect < https://openid.net/specs/openid-connect-core-1_0.html> offered by KeyCloak <https://www.keycloak.org/> and use the access token given by the token endpoint. This request with the access token can be either sent by browser or by one of the back-end services delivering the current web-site. Thus, we can either do a a client-side integration or server-side integration with the REST API. Unfortunately, the server-side integration is not that feasible due to the complex structure of back-end systems. I cannot even integrate most of web services with KeyCloak. Thus, I could store the access token in the browser in local storage < https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage> and access to the REST API directly from browser. However, I'm still unsure if storing the access token in browser will bring a security vulnerability. I could not see any official statement regarding this in the standards or in the KeyCloak documentation, so far. I have seen applications both storing it in the back-end and storing in the browser and I still can't tell the exact security benefit of using a session over an access token when we store it in the back-end. I do not intend to save refresh token in the browser and use only authorization code flow with the help of a back-end service. My questions: Is it a security vulnerability to store the access token in browser? E.g., in local storage, in a cookie with HttpOnly, or both of them? Is there a way to mitigate the security threat and still store it in browser? Is there a best practice or guideline for storing the access tokens of OpenID Connect that you could refer to? What is the difference from the security perspective between storing the access token and session, if we can use the session to access the API over an intermediary service? Thank you for your assistance in advance! Regards, Timur _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Thank you for your answer. What is the reason behind keeping it short? In my use case, it is valid for 2 hours and I will store it somewhere during that period. Regards, Timur Sent from my mobile device. Am 22.03.2019 um 08:48 schrieb Sebastien Blanc <sblanc(a)redhat.com&gt;: I'm not sure to understand you usecase and anyway the access token lifespan should always be really short (it's 1 minute by default in Keycloak) so I don't really see the point of storing it in the local storage. On Thu, Mar 21, 2019 at 8:42 PM Timurhan Sungur <timurhan.s(a)gmail.com&gt; wrote: > < > https://security.stackexchange.com/questions/205837/openid-connect-is-sto... > > > Hi, > > I'm currently in the phase of integrating my web-site to OpenID Connect > provided by KeyCloak. The web-site is not a single page application. > However, different parts of the application are delivered by different web > services. > In each site delivered by these different web services, the user can call > a standard REST API. This REST API can only be accessed with an access > token received from KeyCloak. Thus, the user needs to log-in on the > web-site using authorization code flow of OpenId Connect < > https://openid.net/specs/openid-connect-core-1_0.html> offered by > KeyCloak <https://www.keycloak.org/> and use the access token given by > the token endpoint. This request with the access token can be either sent > by browser or by one of the back-end services delivering the current > web-site. Thus, we can either do a a client-side integration or server-side > integration with the REST API. > > Unfortunately, the server-side integration is not that feasible due to > the complex structure of back-end systems. I cannot even integrate most of > web services with KeyCloak. Thus, I could store the access token in the > browser in local storage < > https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage> > and access to the REST API directly from browser. However, I'm still unsure > if storing the access token in browser will bring a security vulnerability. > > I could not see any official statement regarding this in the standards or > in the KeyCloak documentation, so far. I have seen applications both > storing it in the back-end and storing in the browser and I still can't > tell the exact security benefit of using a session over an access token > when we store it in the back-end. I do not intend to save refresh token in > the browser and use only authorization code flow with the help of a > back-end service. > > My questions: > > Is it a security vulnerability to store the access token in browser? > E.g., in local storage, in a cookie with HttpOnly, or both of them? > Is there a way to mitigate the security threat and still store it in > browser? > Is there a best practice or guideline for storing the access tokens of > OpenID Connect that you could refer to? > What is the difference from the security perspective between storing the > access token and session, if we can use the session to access the API over > an intermediary service? > Thank you for your assistance in advance! > > > Regards, > > Timur > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >

We are communicating over HTTPS as stated in the link you have sent. Shortening the lifespan of the access token is not an option and does not make sense in our use case. Regards, Timur Sent from my mobile device. > Am 22.03.2019 um 09:26 schrieb Sebastien Blanc <sblanc(a)redhat.com&gt;: > > Because your access token could be compromised and could be used to call services that can verify offline this token. https://www.keycloak.org/docs/latest/server_admin/index.html#compromised-... > >> On Fri, Mar 22, 2019 at 9:03 AM Timurhan Sungur <timurhan.s(a)gmail.com&gt; wrote: >> Thank you for your answer. What is the reason behind keeping it short? In my use case, it is valid for 2 hours and I will store it somewhere during that period. >> >> Regards, >> >> Timur >> >> Sent from my mobile device. >> >>> Am 22.03.2019 um 08:48 schrieb Sebastien Blanc <sblanc(a)redhat.com&gt;: >>> >>> I'm not sure to understand you usecase and anyway the access token lifespan should always be really short (it's 1 minute by default in Keycloak) so I don't really see the point of storing it in the local storage. >>> >>>> On Thu, Mar 21, 2019 at 8:42 PM Timurhan Sungur <timurhan.s(a)gmail.com&gt; wrote: >>>> <https://security.stackexchange.com/questions/205837/openid-connect-is-sto... >>>> Hi, >>>> >>>> I'm currently in the phase of integrating my web-site to OpenID Connect provided by KeyCloak. The web-site is not a single page application. However, different parts of the application are delivered by different web services. >>>> In each site delivered by these different web services, the user can call a standard REST API. This REST API can only be accessed with an access token received from KeyCloak. Thus, the user needs to log-in on the web-site using authorization code flow of OpenId Connect <https://openid.net/specs/openid-connect-core-1_0.html> offered by KeyCloak <https://www.keycloak.org/> and use the access token given by the token endpoint. This request with the access token can be either sent by browser or by one of the back-end services delivering the current web-site. Thus, we can either do a a client-side integration or server-side integration with the REST API. >>>> >>>> Unfortunately, the server-side integration is not that feasible due to the complex structure of back-end systems. I cannot even integrate most of web services with KeyCloak. Thus, I could store the access token in the browser in local storage <https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage> and access to the REST API directly from browser. However, I'm still unsure if storing the access token in browser will bring a security vulnerability. >>>> >>>> I could not see any official statement regarding this in the standards or in the KeyCloak documentation, so far. I have seen applications both storing it in the back-end and storing in the browser and I still can't tell the exact security benefit of using a session over an access token when we store it in the back-end. I do not intend to save refresh token in the browser and use only authorization code flow with the help of a back-end service. >>>> >>>> My questions: >>>> >>>> Is it a security vulnerability to store the access token in browser? E.g., in local storage, in a cookie with HttpOnly, or both of them? >>>> Is there a way to mitigate the security threat and still store it in browser? >>>> Is there a best practice or guideline for storing the access tokens of OpenID Connect that you could refer to? >>>> What is the difference from the security perspective between storing the access token and session, if we can use the session to access the API over an intermediary service? >>>> Thank you for your assistance in advance! >>>> >>>> >>>> Regards, >>>> >>>> Timur >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user