Re: [keycloak-dev] Application Initiated Actions Draft #2

On Mon, 1 Apr 2019 at 21:43, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Mon, Apr 1, 2019 at 3:44 PM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> >> >> On Mon, 1 Apr 2019, 18:54 Pedro Igor Silva, <psilva(a)redhat.com&gt; wrote: >> >>> Hi Stian, >>> >>> A few additional comments: >>> >>> * "or alternatively the application can include an id_token_hint with >>> the request that proves the application does not need consent from the user" >>> >>> I understand that ID Tokens should be short-lived, but aren't we >>> setting the exp of ID tokens with the value from access tokens? See >>> org.keycloak.protocol.oidc.TokenManager.AccessTokenResponseBuilder#generateIDToken. >>> >> >> On my phone so can't look at that. ID tokens have some expiration as >> access tokens surely? >> > > It seems so > https://github.com/keycloak/keycloak/blob/061693a8c981987216d37658c7937dd.... > I did run some tests to make sure I'm not missing anything ... Hope I'm > wrong :) > They should have the same expiration surely?

> > >> >> >>> In addition to that, I don't think that using a front-channel to pass >>> tokens is something we want to do given that there are a lot of >>> considerations around this approach. If we are really going this way, I >>> think we should at least consider some form of proof-of-possession. >>> >> >> I'm not 100% convinced about id_token_hint either, but OIDC spec already >> uses id_token_hint several places. It's in the auth endpoint already (not >> something we're adding) also used in logout specs. I also struggle to see >> how it can be missused even if obtained. >> >> Proof of possession is a nice idea, but not sure how that could be done >> without storing additional things at the server side. >> > > I can look at that if you want and see if we can apply here some PoP > technique. > Sure - we could potentially support both id_token_hint and a PoP technique (if we can do the latter in a nice way) > > I missed this parameter in OIDC spec. So maybe we are cool then and > should just use it? Kind of interesting this, you see a lot of warnings in > OAuth 2.0 about using front-channel to deliver tokens (e.g.: implicit) and > in OIDC I did not find anything ... Well, we are backed by the spec then to > keep this simple... > There's a difference in leaking a refresh token and access token to leaking a ID token IMO. From thinking about it I can't see how you would use a leaked ID token as apps don't accept them in the same way as services accept access tokens.

> > Of course, this is different than sending tokens to a client which you > don't control. But still, suffer some of the same vulnerabilities ... > > >> >> >>> For last, maybe you should explicitly mention the usage of TLS? >>> >> >> I do believe that is already implied? Oauth/OIDC/tokens are completely >> insecure without TLS. >> > > Yeah, I just wanted to highlight this based on the list of considerations > you added into "Notes on id_token hint". You pointed out some that could be > considered to be an implied concern. > > >> >> >>> Regards. >>> Pedro Igor >>> >>> On Wed, Mar 27, 2019 at 9:43 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> Based on feedback and also thinking about this a bit more I've now >>>> updated >>>> the proposal for Application Initiated Actions. >>>> >>>> Please read and comment on the update draft if you're interested. >>>> >>>> >>>> https://github.com/keycloak/keycloak-community/blob/master/design/applica... >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>