Re: [keycloak-dev] client requested account linking

Op 24 feb. 2017, om 09:21 heeft Marek Posolda <mposolda(a)redhat.com&gt; het volgende geschreven: Don't we have a plan to rewrite AccountService to use Angular+REST? If yes, then we are fine though. We will have REST endpoint for link broker, which can be invoked with the bearer token as long as the token has "manage-account" scope. We don't need to care about CSRF then. I can see the only reason to keep support browser+cookie based flows - the case when client application doesn't have Keycloak token. But from what you mentioned in the last paragraph, it looks that their client has our access token? Marek On 23/02/17 23:24, Bill Burke wrote: > A customer has asked us to implement a feature in which there is a > browser endpoint on keycloak. This URL can be told to link to a > specific identity broker provider (Google, Facebook, etc.) and then the > browser would be redirected back to the client. Pretty much what exists > in the Account Service console, but without having to look at the > Account Service. The reason for this is that they are doing integration > with a specific social provider and don't want to have to go through the > Account Service pages. Seems pretty reasonable and valid use case... > I'm worried about a couple of things: > > * The design of it > > * The security implications. > > The implementation would be simple enough, it would just extract code > from the accoutn service. The endpoint would take a "providerId" > paramter that would be the idp linking to, a "clientId" for the client > requesting the link, and a "redirect_uri" to redirect back to after the > link is successful. Obviously the redirect_uri would be validated > against the clientId. > > Now comes the interesting part, the security implications. Account > linking in the Account Service is fine and dandy and doesn't have any > security holes because we guarantee that the Account Service initiated > the linking via a CSRF check. For this new Client-Requested-Linking > feature, if we do nothing, and just model it as above, we cannot > guarantee that the client initiated the linking request. What are the > implications of this? This feature would be vulnerable to CSRF. A > rogue website could initiate account linking to a specific configured > provider. Is this bad? I don't know. We can guarantee that the > redirect uri is valid. The browser would never get back to the rogue > website. So what can we do to improve this? > > * We could do nothing and hope its ok that anybody can initiate a link. > > * We could add a consent screen like this: "Application 'clientId' is > requesting that you link your user account to 'providerId'. Do you > agree to this? You will be redirected to this provider if you click > ok.". This of course relies on the user to actually read the page. Is > this good enough? > > * My last thought would be OIDC specific. We could use the POST binding > trick that SAML does to do a browser redirect via a POST call. THe POST > would contain the access token the client has. We match this token up > against the browser cookie to make sure its the same session. We also > make sure that the access token has permission to request a link. There > are 2 downsides to this approach a) This requires some code on the > client side to obtain the access token and then to package it up into an > HTML document so the POST binding trick can be done. b) This will only > work for OIDC clients. SAML clients will be left in the dust, although > I guess we could allow SAML to push a signed assertion back. > > > Thoughts? > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev