<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Stian,<div><br></div><div>With regards to the "Reset password" flow, will we send the password written in the email to the user? How long can the user use this temporary password?</div><div><br></div><div>I know that some services do this, but the most common flow that I've seen in a quick benchmarking was an email with link that takes the user to a page to enter and save the new password (see images below).</div><div><br></div><div>I just want to clarify this point before prototyping. </div><div><br></div><div><img id="c2251ef5-3dee-4ee9-b4c6-20fe0fc3f604" height="552" width="882" apple-width="yes" apple-height="yes" src="cid:E9BFF548-6DC9-42D6-A84A-2E81EC801B2D"><img id="c87512f3-5f35-40ab-abf6-77ba8d62ecb4" height="421" width="734" apple-width="yes" apple-height="yes" src="cid:5DBE111F-930A-483B-A08F-896A81E4C189"><img id="afe70764-0a10-4a17-a961-b2d2b23749cd" height="358" width="760" apple-width="yes" apple-height="yes" src="cid:F1725EF6-98AF-456C-8657-D84569F6EFC8"></div><div><br></div><div>Thanks,</div><div>Gabriel</div><div><br></div><div><div><div>On Sep 11, 2013, at 9:33 AM, Bill Burke wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br>On 9/11/2013 8:27 AM, Bill Burke wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 9/11/2013 8:24 AM, Stian Thorgersen wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Unless someone else has already started to work on (or is very interested) I plan to work on account workflows. This work includes:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* Email verification<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* Reset password<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* Configure TOTP after registration if required by realm<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* Marking user as requiring actions before they can login to applications<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I've outlined a proposal on:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://github.com/keycloak/keycloak/wiki/User-Actions">https://github.com/keycloak/keycloak/wiki/User-Actions</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Finally, when an account is in the state of requiring actions (read the above wiki page to understand what I'm talking about!) the user should have access to the account management pages, but not to applications themselves. I was thinking in this case the accessCodeId could be passed as a query parameter, which would allow the account management pages to verify that the user is logged in, but at the same not enable SSO to applications (as the cookie isn't set yet). An alternative I was thinking of was that the SkeletonKeyToken could have the status added to it, but I don't like that approach as that would require applications to check the status. Any other suggestions?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Not sure you need to do that. User has an "enabled" property. If that<br></blockquote><blockquote type="cite">is not good enough, we could add a enum state variable to it. SSO/OAuth<br></blockquote><blockquote type="cite">logins would ensure that the user was in the appropriate state and<br></blockquote><blockquote type="cite">forward to the appropriate pages. It needs to do this anyways.<br></blockquote><blockquote type="cite"><br></blockquote><br>Sorry, disregard my previous email. I read your blurb too quick.<br><br>Yes, you would need to pass along the accessCodeId along to the account <br>management pages if an action is required. Another option might be to <br>set a session cookie for the accessCode and destroying this cookie when <br>the browser is finally redirected back to the application.<br><br>The application should not be aware of Keycloak auth server specifics, <br>so I don't think adding account state to the SkeletonKeyToken is a good <br>idea at the moment.<br><br>-- <br>Bill Burke<br>JBoss, a division of Red Hat<br><a href="http://bill.burkecentral.com">http://bill.burkecentral.com</a><br>_______________________________________________<br>keycloak-dev mailing list<br>keycloak-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/keycloak-dev<br></div></blockquote></div><br><div apple-content-edited="true">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br class="Apple-interchange-newline">--</div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Gabriel Cardoso<br>GateIn Portal | User Experience Designer<br><br></div>
</div>
<br></div></body></html>