<p dir="ltr">Wouldn&#39;t saml support it fairly easily? It&#39;s just another auth request with SE different params?</p>
<div class="gmail_quote">On 29 Apr 2016 16:19, &quot;Bill Burke&quot; &lt;<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Sounds great.  I hope we don&#39;t have to implement this for SAML too
    ;)<br>
    <br>
    <div>On 4/29/2016 12:02 AM, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Clients should be able to obtain tokens with reduced scope
          and longer or shorter expiration, then later request new
          tokens with increased scope and different expiration. They
          should also be able to require different levels of
          authentication and also require re-authentication.<br>
        </div>
        <div><br>
        </div>
        <div>An application may for example:</div>
        <div><br>
        </div>
        <div>* At first only need users email - this would allow showing
          the name + email. In this situation a long expiration access
          token in combination with implicit flow would do. It&#39;s also
          not necessary to re-authenticate the user and a user that has
          been logged-in for months or even a year is fine. </div>
        <div><br>
        </div>
        <div>* When a user clicks on orders it would require the
          password and extend scope to be able to view orders. Now
          you&#39;ll want to switch to short expiration access tokens and
          authorization code grant. You&#39;ll also want to make sure the
          user logged-in fairly recently, max 30 days could be sensible.</div>
        <div><br>
        </div>
        <div>* When a user tries to purchase something the user now has
          to provide the OTP to be able to purchase with saved credit
          card details. You&#39;ll also want to make sure the user logged-in
          very recently, max a day could be required. There may also be
          cases where you always want the user to re-authenticate, for
          example when trying to purchase something over a certain price
          level.</div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
    </blockquote>
    <br>
    <pre cols="72">-- 
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
  </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>