[keycloak-dev] client requested account linking

[Marek Posolda]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev