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>:
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> 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