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