I’m not the first one to ask this: Enforce terms consent for social login via lock. But I haven’t seen a satisfying solution.
With the mustAcceptTerms: true option set in Locks, users who signup with an IdP are forced to check the terms-and-conditions checkbox. Great! However, as has been pointed out, they can still login with that IdP, bypassing the terms-and-conditions check.
The linked solution suggests adding a rule to check for a app_metadata.terms_accepted flag. However, no such flag gets set when the user checks the checkbox. You can create an addition hidden property, but that only works for database accounts.
As far as I can tell, there is no way to tell if a IdP user has check the terms-and-conditions checkbox the first time the login or signup. So the solution is to…always assume they haven’t checked it? That would be a terrible user experience for users who actually did.
Am I missing something obvious here? I worked on this problem for nearly twelve hours yesterday and have not come up with a viable solution.
1 Like
Hi @michael.farnsworth,
Note that as per docs:
https://auth0.com/docs/libraries/lock/v11/configuration#mustacceptterms-boolean-
the flag only applies to database connection users.
Also, I don’t think relying on that checkbox that mustAcceptTerms (which only shows on the signup tab but not the login tab) is reliable, because technically, for Social Connections there’s no difference between a login and a signup. A user can as well use the “Login with Google” on the login tab instead of signup tab with no difference (even if he hasn’t loggedin/signed up before).
I would use a redirect rule with a custom consent page (on your end), and store this information in the user’s metadata. Then check for it in a Rule at login whether he’s accepted it yet or not.
Update: I actually just found that that checkbox mustAcceptTerms is a pure client-side check (obviously, as it’s just a configuration set on the client side). And you are right, it doesn’t get stored anywhere in the user profile. I will report that internally.
So, if you go into the HTML DOM and remove the ‘disabled’ attribute, a user can even signup without checking that checkbox, which obviously isn’t intended.
So, therefore, for the moment I’d even more recommend to go with the approach outlined above.
1 Like
Thanks for the reply. At least, now I know I wasn’t missing something simple.
-Michael
2 Likes
Glad we were able to help!
Just to help drawing attention to this thread: We are also struggling with this!
We would have expected that Auth0 provides a lean solution for this. We are discussing various workaround right now that will lead to worse user experience 
3 Likes
