In our application, there are tree methods of registering/signin :
Email / Password
Google
LinkedIn
For various reasons, we wish to disable LinkedIn registration, but not the login.
It is important that the current users that registered and uses LinkedIn everyday to log into the app, remain able to.
Is there any way to disable a method of registering, but not logging in?
Or what would be the best way to have current LinkedIn user change to Email and Password ?
For social logins, Auth0 doesn’t really differentiate between logins and registration. There’s just the first login and subsequents ones.
You could write a rule that prevents user from using LinkedIn if it is the first login. The Disable social signups template (one of the templates offered when you create a new rule) is a good start, and you would have to replace the is_social condition used in it for a isLinkedIn or something like that:
[...]
//const is_social = context.connectionStrategy === context.connection;
const is_linkedin = context.connectionStrategy === 'linkedin';
// if it is the first login (hence the `signup`) and it is a social login
if (context.stats.loginsCount === 1 && is_linkedin) {
[...]
The rule will deny authorization, and an error will be sent back to the application. The application can handle the error and show a good explanation to the user. I guess you’ll want to preemptively explain in the UI that the “LinkedIn” button is only good for users that already signed up.
As for:
what would be the best way to have current LinkedIn user change to Email and Password ?
That, unfortunately, depends a lot on the architectural choices of the application (like whether you have any information about the users in your application, or if you keep additional information in user_metadata/app_metadata in the user profile).
A simple method, for instance, could be that when a LinkedIn user logs in into your application, you tell the user that the signup method is no longer available and that they will have to log in with a different method. This second authentication request could be pointed to a different callback location (e.g. /callback/linkedin_replacement). In that callback location, you would get the new user id, migrate old data to the new user id, then delete the linkedin user (or flag it as disabled).