[keycloak-dev] Two Factor Authentication via Email.

[Bill Burke]

On 1/11/2016 4:15 PM, Thomas Darimont wrote:
> I'm currently working on a PR that provides "Two factor authentication 
> via email" https://issues.jboss.org/browse/KEYCLOAK-240.
>
> My current implementation comes with a custom EmailCodeAuthenticator
> that generates a short code String in the challenge(...) Method and
> sends an email to the email address that is configured for the current 
> user.
>
> The user can then copy and paste the code into an input field, similar
> to OTP codes are handled. If the user entered the wrong code, a new
> email is sent to the user's email address.
>
> The email code is saved as a user level credential.
>
> I wonder whether this is the right approach or whether it would be better
> to allow the user to regenerate the code on demand instead of
> regenerating it every time?
>

Don't know what you mean by that.  Just store the OTP within the 
ClientSessionModel.  Generate the OTP, store it within the ClientSession 
model, send the OTP to the user, display the OTP input page.  IMO, you 
also should not resend the email on failure. Instead, supply a button 
that they can click to resend the email.

> For the former I'd have to provide a REST endpoint similar to what 
> happens for verifying an email
> during registration - where should this be placed?
>
> For sending the actual email I'm currently using a 
> EmailSenderProvider, however I think a EmailTemplateProvider might be 
> more appropriate ;-)
> May I simply add a method to the EmailTemplateProvider interface?
>

We should have a more generic method on EmailTemplateProvider.

> Btw. I think this would be a good base for having an SMS based 2nd 
> factor authenticator, as requested here: 
> https://issues.jboss.org/browse/KEYCLOAK-241
>
> It would make sense to have the mobile phone number as a first-class 
> user attribute and showing it on the profile page by default instead 
> of just having it only in the data model.
>
> Another point that comes to my mind is that I could make sense to 
> specify an email code policy in the same way OTP policies are 
> supported. This could then be used to differentiate between email
> codes that are usually handled via copy&paste whereas codes
> that come via SMS are usually typed in by hand and should therefore
> be somewhat short ;-)
>

All that makes sense.  Never did an SMS based module as the SDKs used 
differ per country, are quite diverse, and most of the time(?) cost money.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com