<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">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">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><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">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">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><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><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 class="HOEnZb"><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">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>