Two questions: - Did you configure OTP script ( enabled ) in oxTrust? - Did you change the 'Manage Authentication' to OTP? Point to be noted: Make sure to check this in incognito panel. Like, apply above change in one browser and test in another browser. Otherwise you might lock yourself to Gluu oxTrust admin panel.

OTP script is enabled, yes. With 'Manage Authentication' you mean the default authentication method (ACR)? No, that's still set to casa, which seems correct to me, since I want to offer a choice between Username/Password and External logins (via passport). To reiterate: via Username & Passwort I'm asked for OTP correctly and login with both factors is successful. It's just that going via Github instead completely skips OTP.

Hi David, When authentication is delegated to a third party no 2FA applies from Gluu side. It's the usual "Sign in with" feature you find at other portals. If you want to prompt for a second factor after the user has logged in at the third party you would have to implement changes in the casa script. All major websites you integrate via passport implement 2FA and github is no exception, visit this [page](https://github.com/settings/security). Another observation is, when no credentials have been enrolled, users can still login with usr+password only to Casa. And this is not security problem.

Jose, thank you for confirming. I can understand your thought process when looking at 2FA from a user's perspective (i.e. the user decides to use 2FA volunarily to incrase account security). I was looking at the topic more from a security policy point of view (i.e. the organization decides to mandate 2FA) and then you can only control what happens in Gluu and not necessarily what happens at Github et al. Then I think it would be beneficial to allow external authentication as an alternative to username &password login while still enforcing 2FA at Gluu. Whether or not it's a good idea to rely on external providers in these cases in the first place is another thing, of course ;)

> the user decides to use 2FA volunarily... Yes. Casa design was driven by this principle among others. We found that most sites, be they social networks, e-wallets, etc. start with user+password and encourage people to use 2fa but they simply don't force it. We followed that generic "standard" approach. There are some hints in the UI that invite users to enroll credentials, and you can make it more blatant by using the `2fa_requisite` [flag](https://gluu.org/docs/casa/administration/2fa-basics/#forcing-users-to-enroll-a-specific-credential-before-2fa-is-available) on some authn mechanisms so the options to enroll appear more "up-front". > I think it would be beneficial to allow ... > Whether or not it's a good idea to rely These 2 kind of go hand-in-hand. If you onboard an external provider that you consider trustworthy, I wouldn't care about second factor because probably that practice takes place there already (at the provider). Successful logins coming from there can be deemed safe. When unsure about trustworthiness, this is more critical and forcing 2FA to happen sounds like a better idea. However this conflicts severely with the current design: only "local" users (ie. who have a password in the local Gluu database) can enroll credentials and have 2FA; "conversion to local" takes place when using the "Set a password" menu item in Casa. Ignoring this inconvenience, there is also some likelihood the external provider already applies some form of strong authentication before the users lands Casa, and undergoing 2FA twice for users would be confusing. As I see it, one should not integrate external providers when the resource you are trying to give access to is highly sensitive. For instance I don't think online banking apps, Amazon, Paypal, and the like would ever allow such thing. From my experience with 2FA in the last years I've found that a one-size-fits-all approach to strong authentication doesn't seem to exist. Things get complicated too easily, so we kind of favor simplicity. Add to it the fact that composable authentication flows are a utopia, and Gluu is not an exception. Probably step-up authentication (user prompted to present a credential when attempting to perform a sensitive action inside an app) is a better strategy, however, it is beyond the scope of Casa. There are no plans to support this feature in Gluu in the short term.

Jose, thanks for that insight. Very interesting to read. I agree with you that 2FA is a complex topic, every big player does things slightly differently and that it's impossible to find a solution that caters to every possible scenario. I also was not aware, that Casa's use case is only "local" users and with that in mind the current implementation does make a lot of sense. Thanks, I'll close the issue.