Hi there, we have a single page application using the JS adapter. Once the user is logged in and a page redirect occurs, the SPA loads, but immediately reloads once again when keycloak adapter authenticates. Since the user was logged in before already, we would have assumed that no further page refresh has to be made. Interestingly, when we manually pass on all the token values in the init method (for testing purposes), the page doesn't refresh a second time and the user is authenticated. As we would have expected it to be. This might be just a misunderstanding of how this adapter is supposed to work, but from our understanding the purpose of the iframe and the set cookie is to make sure the user stays authenticated. Thus, shouldn't the keycloak adapter "store" the tokens and use them on a page refresh if they are valid in order to authenticate without the need for an additional page refresh? Would be nice if somebody can explain this mechanism a bit further and maybe even give a hint on what we are doing wrong here.. We are puzzled at the moment. Thanks Gregor _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

I am, and I believe that I have noticed this behavior as well. I get redirected back to the app with "?prompt=none" appended to the URL. On 09/29/2016 10:16 AM, Sebastien Blanc wrote: Hi, Are you using keycloak.init({ onLoad: 'check-sso' }) ? Sebi On Thu, Sep 29, 2016 at 4:01 PM, Gregor Jarisch <gregor(a)jarisch.net&gt; wrote: > Hi there, > > we have a single page application using the JS adapter. Once the user is > logged in and a page redirect occurs, the SPA loads, but immediately > reloads once again when keycloak adapter authenticates. > Since the user was logged in before already, we would have assumed that > no further page refresh has to be made. > > Interestingly, when we manually pass on all the token values in the init > method (for testing purposes), the page doesn't refresh a second time and > the user is authenticated. As we would have expected it to be. > > This might be just a misunderstanding of how this adapter is supposed to > work, but from our understanding the purpose of the iframe and the set > cookie is to make sure the user stays authenticated. > Thus, shouldn't the keycloak adapter "store" the tokens and use them on a > page refresh if they are valid in order to authenticate without the need > for an additional page refresh? > > Would be nice if somebody can explain this mechanism a bit further and > maybe even give a hint on what we are doing wrong here.. We are puzzled at > the moment. > > Thanks > > Gregor > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ keycloak-user mailing listkeycloak-user@lists.jboss.orghttps://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

We tried login-required as well as check-sso. In case of a user logged in, it doesn't seem to do anything different. Stian, in fact, it seem to be as you described it. A logged on user loads the page and it gets redirected to keycloak and back again, than loads the website a second time. So twice. But why is this necessary? This is a bad UX experience and a performance loss as well. If the user is logged in, it should not redirect anywhere. Couldn't the js adapter simple make an XHR request to the keycloak server - as other js requests would do it - and only redirect in case the user isn't logged in? I believe that way would be much more user friendly (visually appealing in particular) and faster as well, because you don't have twice the loading time of your page. Am I missing something here or could this be improved that way? Gregor From: Stian Thorgersen <sthorger(a)redhat.com&gt; To: Jess Sightler <jsightle(a)redhat.com&gt; Cc: keycloak-user <keycloak-user(a)lists.jboss.org&gt; Sent: 30.09.2016 8:42 Subject: Re: [keycloak-user] Prevent JS Adapter from redirecting if already logged in With check-sso what should happen is: * keycloak.js checks session cookie. If no cookie it does nothing * If session cookie exists redirect to login page with prompt=none * If session is valid Keycloak redirects back to app with code and keycloak.js swaps the code * If session wasn't valid Keycloak redirects back to app With a logged-in user the app page should be loaded twice. Once when first visited then a second time after the prompt=none redirect. Are you seeing the page being loaded twice or three times? On 29 September 2016 at 17:27, Jess Sightler <jsightle(a)redhat.com&gt; wrote: > I am, and I believe that I have noticed this behavior as well. I get > redirected back to the app with "?prompt=none" appended to the URL. > > On 09/29/2016 10:16 AM, Sebastien Blanc wrote: > > Hi, > > Are you using > > keycloak.init({ onLoad: 'check-sso' }) ? > > > Sebi > > > > On Thu, Sep 29, 2016 at 4:01 PM, Gregor Jarisch <gregor(a)jarisch.net&gt; > wrote: > >> Hi there, >> >> we have a single page application using the JS adapter. Once the user is >> logged in and a page redirect occurs, the SPA loads, but immediately >> reloads once again when keycloak adapter authenticates. >> Since the user was logged in before already, we would have assumed that >> no further page refresh has to be made. >> >> Interestingly, when we manually pass on all the token values in the init >> method (for testing purposes), the page doesn't refresh a second time and >> the user is authenticated. As we would have expected it to be. >> >> This might be just a misunderstanding of how this adapter is supposed to >> work, but from our understanding the purpose of the iframe and the set >> cookie is to make sure the user stays authenticated. >> Thus, shouldn't the keycloak adapter "store" the tokens and use them on a >> page refresh if they are valid in order to authenticate without the need >> for an additional page refresh? >> >> Would be nice if somebody can explain this mechanism a bit further and >> maybe even give a hint on what we are doing wrong here.. We are puzzled at >> the moment. >> >> Thanks >> >> Gregor >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user@lists.jboss.orghttps:// 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 > _______________________________________________ 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

I totally understand the security first approach and fully agree with having it as default behavior. Nonetheless would it be nice if the adapter would support storing the security context with an optional parameter if one would need it this way and understands the trade off. In the end, having a clean solution implemented that works is definitely better than hacking this by oneself and maybe thus opening up serious security vulnerability.. Would that be an option for you guys allowing this behavior with an optional configuration of the adapter? * From: * Stian Thorgersen <sthorger(a)redhat.com&gt; * To: * Gregor Jarisch <gregor(a)jarisch.net&gt; * Cc: * keycloak-user <keycloak-user(a)lists.jboss.org&gt; * Sent: * 30.09.2016 13:07 * Subject: * Re: [keycloak-user] Prevent JS Adapter from redirecting if already logged in keycloak.js was primarily written aiming a single page-app. For security reasons it doesn't store any security context information outside the window memory (single tab). So when you open a new tab or refresh the page you are not actually authenticated with the application, only with the Keycloak SSO server. Hence the need to do a redirect. That's how OAuth2 and OpenID Connect flows work and there's no support to retrieve tokens using XHR requests as that would make it rather insecure. You can however share the security context between tabs and page refreshes if you want. That's then a trade-off you make on usability vs security. We chose security by default in this case. To do that all you need to do is store the tokens in HTML5 storage and initialize keycloak.js with the tokens. If you do this I would be careful about what permissions the tokens have in case they are indeed leaked (don't give super priviledges to this app for instance). On 30 September 2016 at 11:12, Gregor Jarisch <gregor(a)jarisch.net&gt; wrote: We tried login-required as well as check-sso. In case of a user logged in, it doesn't seem to do anything different. Stian, in fact, it seem to be as you described it. A logged on user loads the page and it gets redirected to keycloak and back again, than loads the website a second time. So twice. But why is this necessary? This is a bad UX experience and a performance loss as well. If the user is logged in, it should not redirect anywhere. Couldn't the js adapter simple make an XHR request to the keycloak server - as other js requests would do it - and only redirect in case the user isn't logged in? I believe that way would be much more user friendly (visually appealing in particular) and faster as well, because you don't have twice the loading time of your page. Am I missing something here or could this be improved that way? Gregor From: Stian Thorgersen <sthorger(a)redhat.com&gt; To: Jess Sightler <jsightle(a)redhat.com&gt; Cc: keycloak-user <keycloak-user(a)lists.jboss.org&gt; Sent: 30.09.2016 8:42 Subject: Re: [keycloak-user] Prevent JS Adapter from redirecting if already logged in With check-sso what should happen is: * keycloak.js checks session cookie. If no cookie it does nothing * If session cookie exists redirect to login page with prompt=none * If session is valid Keycloak redirects back to app with code and keycloak.js swaps the code * If session wasn't valid Keycloak redirects back to app With a logged-in user the app page should be loaded twice. Once when first visited then a second time after the prompt=none redirect. Are you seeing the page being loaded twice or three times? On 29 September 2016 at 17:27, Jess Sightler <jsightle(a)redhat.com&gt; wrote: > I am, and I believe that I have noticed this behavior as well. I get > redirected back to the app with "?prompt=none" appended to the URL. > > On 09/29/2016 10:16 AM, Sebastien Blanc wrote: > > Hi, > > Are you using > > keycloak.init({ onLoad: 'check-sso' }) ? > > > Sebi > > > > On Thu, Sep 29, 2016 at 4:01 PM, Gregor Jarisch <gregor(a)jarisch.net&gt; > wrote: > >> Hi there, >> >> we have a single page application using the JS adapter. Once the user is >> logged in and a page redirect occurs, the SPA loads, but immediately >> reloads once again when keycloak adapter authenticates. >> Since the user was logged in before already, we would have assumed that >> no further page refresh has to be made. >> >> Interestingly, when we manually pass on all the token values in the init >> method (for testing purposes), the page doesn't refresh a second time and >> the user is authenticated. As we would have expected it to be. >> >> This might be just a misunderstanding of how this adapter is supposed to >> work, but from our understanding the purpose of the iframe and the set >> cookie is to make sure the user stays authenticated. >> Thus, shouldn't the keycloak adapter "store" the tokens and use them on a >> page refresh if they are valid in order to authenticate without the need >> for an additional page refresh? >> >> Would be nice if somebody can explain this mechanism a bit further and >> maybe even give a hint on what we are doing wrong here.. We are puzzled at >> the moment. >> >> Thanks >> >> Gregor >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user@lists.jboss.orghttps:// 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 > _______________________________________________ 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