[keycloak-user] Question about the javascript-adapter and the check-sso option with a confidential client

[Marek Posolda]

I think your possibilities are either:
- Use different client for keycloak.js (public client) and different 
client for your confidential servlet application
- Don't use keycloak.js at all, but instead do some HTTP Filter to deal 
with "autologin" . You will manually try to redirect to keycloak with 
"prompt=none" . If user is not logged, keycloak will redirect back to 
the callback redirect_uri, where you recognize if there is "code" or 
"error" parameter and based on that, you know if user is logged or not. 
If user is logged, you can redirect to secured URL to properly trigger 
authentication process (maybe you can optimize this step by reuse the 
"code", which you already have and directly open the secured URI with 
it, but I am not 100% sure if it works with considering that you also 
need correct "state" etc.) Otherwise, you can set some state or 
something, to recognize that autologin has been already unsuccessfully 
tried.

Maybe you can create JIRA to request support "autologin" for other types 
of clients then public keycloak.js clients.

Marek

On 25/06/16 11:44, Tomás García wrote:
>
> Hi,
>
>  I wonder if it's possible to just check the SSO state with a 
> confidential client. My use case is the following one:
>
> - I have a website which uses a confidential client to login with 
> Keycloak.
>
> - I want to add autologin to this website.
>
> - So I use the javascript adapter with the following option object for 
> the init method: { onLoad: 'check-sso' }. The javascript adapter is 
> built without the secret key in its constructor (obviously if I put 
> the secret key in there, there's no point to use a confidential client 
> at all).
>
> But Keycloak fails with a "type=CODE_TO_TOKEN_ERROR, 
> error=invalid_client_credentials" error.
>
> So I don't know how feasible or secure is to just check that the 
> Keycloak session inside the cookie of the user's browser is still 
> valid. In my case, the browser doesn't need to get the user info, 
> access token, etc, because what I'll do is redirect the user to the 
> Keycloak login page with the confidential client afterwards is the 
> operation is successful. Since the Keycloak session is valid, Keycloak 
> should redirect back with the authentication code without asking 
> credentials to the user.
>
> Additional note: the CORS header isn't added to 400 responses in 
> Keycloak, so it was a bit confusing looking at the JS console in the 
> browser, because it complained about CORS but it was just Keycloak 
> giving the 400 response without the allow-origin header.
>
> Thanks.
>
> -- 
>
> *Tomás García Pérez
> *
>
> *Software Developer*
>
> *Intra**House***
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160627/8bf9a720/attachment.html