<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 1 July 2016 at 14:44, Marek Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 01/07/16 08:58, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On 30 June 2016 at 16:25, Marek
            Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> I am adding some
                OIDC specs JIRAs with possibility how to fix them. I am
                including those, which will be easy to fix and I can
                look into them later today or tomorrow before PTO :<br>
                <br>
                <a href="https://issues.jboss.org/browse/KEYCLOAK-3189" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3189</a>
                - Add &#39;typ&#39; to JWT header<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>+1</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> <span title="KEYCLOAK-3190: Add &#39;kid&#39; to JWT header"><a href="https://issues.jboss.org/browse/KEYCLOAK-3190" target="_blank"><span title="KEYCLOAK-3190: Add
                      &#39;kid&#39; to JWT header"></span></a><a href="https://issues.jboss.org/browse/" target="_blank"></a><a href="https://issues.jboss.org/browse/" target="_blank">https://issues.jboss.org/browse/</a></span>KEYCLOAK-3190

                <span>- Add &#39;kid&#39; to JWT header</span></div>
            </blockquote>
            <div><br>
            </div>
            <div>+1</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><br>
                <a href="https://issues.jboss.org/browse/KEYCLOAK-3217" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3217</a>
                - <span title="KEYCLOAK-3217: UserInfo endpoint not
                  accessible by POST request secured with Bearer header"><span>UserInfo

                    endpoint not accessible by POST request secured with
                    Bearer header<br>
                  </span></span></div>
            </blockquote>
            <div><br>
            </div>
            <div>+1</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span title="KEYCLOAK-3217: UserInfo endpoint not accessible
                  by POST request secured with Bearer header"><span> <a href="https://issues.jboss.org/browse/KEYCLOAK-3147" target="_blank"></a><a href="https://issues.jboss.org/browse/KEYCLOAK-3147" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3147</a>
                    - OpenID Connect auth request redirect_uri behaviour
                    not according to spec<br>
                  </span></span></div>
            </blockquote>
            <div><br>
            </div>
            <div>+1 To just require redirect_uri in either case</div>
            <div><br>
            </div>
            <div>We need separate JIRAs for scope=openid and another one
              for removal of ID token when scope=openid isn&#39;t used</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    For now, I&#39;ve created <a href="https://issues.jboss.org/browse/KEYCLOAK-3237" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3237</a>
    for both things.<span class=""><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span title="KEYCLOAK-3217: UserInfo endpoint not accessible
                  by POST request secured with Bearer header"><span> </span></span><span title="KEYCLOAK-3222: WellKnown endpoint doesn&#39;t
                  return supported types of client authentication"><a href="https://issues.jboss.org/browse/KEYCLOAK-3222" target="_blank"><span title="KEYCLOAK-3190: Add
                      &#39;kid&#39; to JWT header"></span></a><a href="https://issues.jboss.org/browse/" target="_blank"></a><a href="https://issues.jboss.org/browse/" target="_blank">https://issues.jboss.org/browse/</a></span>KEYCLOAK-3222

                <span>- WellKnown endpoint doesn&#39;t return supported
                  types of client authentication<br>
                </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>+1</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span> </span><span title="KEYCLOAK-3222: WellKnown endpoint doesn&#39;t
                  return supported types of client authentication"><span><span title="KEYCLOAK-3190: Add &#39;kid&#39; to JWT header"><a href="https://issues.jboss.org/browse/" target="_blank"></a><a href="https://issues.jboss.org/browse/" target="_blank">https://issues.jboss.org/browse/</a></span>KEYCLOAK-3219

                    - </span></span><span title="KEYCLOAK-3222:
                  WellKnown endpoint doesn&#39;t return supported types of
                  client authentication"><span><span title="KEYCLOAK-3219: WellKnown endpoint doesn&#39;t
                      support claims_supported"><span>WellKnown endpoint
                        doesn&#39;t support claims_supported<br>
                      </span></span></span></span></div>
            </blockquote>
            <div><br>
            </div>
            <div>Maybe this one isn&#39;t so straightforward due to protocol
              mappers?</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Yes, right. Just publish it with some value will be easy (and
    probably will make OIDC test happy :) ) but tricky part is which
    value to use...<span class=""><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span title="KEYCLOAK-3222: WellKnown endpoint doesn&#39;t
                  return supported types of client authentication"><span><span title="KEYCLOAK-3219: WellKnown endpoint doesn&#39;t
                      support claims_supported"><span> <br>
                        <br>
                        All of those are quite straightforward and easy
                        to fix IMO.<br>
                        <br>
                        <br>
                        Besides that, there are those 2, which I first
                        rather want to confirm what exactly to do:<br>
                        <br>
                        - <a href="https://issues.jboss.org/browse/KEYCLOAK-3221" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3221</a>
                        Tokens not invalidated if an attempt to reuse
                        code is made <br>
                        <br>
                        We have just single-use code (which is good),
                        however OAuth2 specs recommends to invalidate
                        existing tokens if an attempt to reuse code is
                        done. And one OIDC test is in WARNING state
                        because of it (it tries to access UserInfo
                        endpoint with the accessToken issued with the
                        reused code). <br>
                        <br>
                        I can see 2 possibilities to fix:<br>
                        a) Invalidate just single clientSession where
                        &quot;code&quot; attempt reuse was made<br>
                        b) Logout whole userSession<br>
                        <br>
                        It looks to me that (a) is sufficient solution.
                        The potential issue with (b) is, that if
                        attacker can steal code, it gives him the
                        possibility to trigger global logout of user
                        from all apps. WDYT?<br>
                      </span></span></span></span></div>
            </blockquote>
            <div><br>
            </div>
            <div>I think option (a) is the correct approach. I interpret
              the spec to state that tokens associated with the specific
              code should be invalidated. Option (b) seems a bit over
              the top and not necessary I also wonder if there&#39;s
              non-malicious situations where an application could try to
              exchange a code twice, for example after a timeout or an
              automated connection retry?</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Not sure if this can be really an issue... Maybe we can fix and see
    if someone see issues?</div></blockquote><div><br></div><div>It&#39;s not an option if we go with (a), but it&#39;s a potential issue if we go with (b). We may not even know the correct user session if the client session doesn&#39;t exist. My vote is let&#39;s stick with option (a).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888"><br>
    <br>
    Marek</font></span><span class=""><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span title="KEYCLOAK-3222: WellKnown endpoint doesn&#39;t
                  return supported types of client authentication"><span><span title="KEYCLOAK-3219: WellKnown endpoint doesn&#39;t
                      support claims_supported"><span> <br>
                        <br>
                        - <a href="https://issues.jboss.org/browse/KEYCLOAK-3218" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3218</a>
                        Support for &quot;max_age&quot; in AuthorizationEndpoint
                        and &quot;auth_time&quot; claim on IDToken <br>
                        <br>
                        The possibility to implement is : <br>
                        - Add new note AUTH_TIME to UserSessionModel. It
                        will be time when authentication of user was
                        fully finished (including requiredActions).
                        Session note is used just so we don&#39;t need to
                        change the model ;)<br>
                        - If &quot;max_age&quot; parameter was requested, the
                        &quot;auth_time&quot; will be added to IDToken (or I will
                        re-check specs if we should rather always add it
                        to IDToken)<br>
                        - I am also thinking about adding hook to
                        CookieAuthenticator, so that if max_age
                        parameter was used and userSession authTime is
                        too &quot;old&quot;, the CookieAuthenticator will be
                        ignored and user will need to re-authenticate
                        with other authenticators (username/password
                        form etc). Then authTime will be updated on
                        userSession once authentication is finished.<br>
                      </span></span></span></span></div>
            </blockquote>
            <div><br>
            </div>
            <div>+1 Sounds good</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span title="KEYCLOAK-3222: WellKnown endpoint doesn&#39;t
                  return supported types of client authentication"><span><span title="KEYCLOAK-3219: WellKnown endpoint doesn&#39;t
                      support claims_supported"><span> <br>
                        WDYT?<br>
                        <br>
                        That will leave us with bigger things for OIDC
                        Basic certification ( scope parameter support,
                        possibly &#39;claims&#39; param support and &#39;acr&#39;
                        support).<span><font color="#888888"><br>
                            <br>
                            Marek</font></span></span></span></span> <br>
                </span> </div>
              <br>
              _______________________________________________<br>
              keycloak-dev mailing list<br>
              <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
              <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </span></div>

</blockquote></div><br></div></div>