Rethinking on auth plugin contract

[msp98]

Right now the auth plugin has lots of loginWith methods.

loginWithGoogle()
loginWithMeta()
loginWithApple()
loginWithTwitter()
loginWithGithub()
loginWithLinkedin()
loginWithMicrosoft()

Which might grow as soon as we want to add a new provider method. And this functionality is "closed"(in OCP terms), but not open for adding new providers. A better way would be to open the plugin interface for adding a provider implementation, and accept a contract for login, logout etc. This way the core plugin contract will not have to worry about adding new providers, as and when required, keeping the abstractions at the heart and extensibility at the consumer end.

[pavanpodila]

Can you take a first cut at the contract ? We can iterate on that

[Sourav-nonstop]

Define Interface:

abstract class AuthProvider {
  Future<void> login();
  Future<void> logout();
}

Implement Providers:

class GoogleAuthProvider implements AuthProvider {
  @override
  Future<void> login() async {
    // Google login implementation
  }

  @override
  Future<void> logout() async {
    // Google logout implementation
  }
}

class MetaAuthProvider implements AuthProvider {
  @override
  Future<void> login() async {
    // Meta login implementation
  }

  @override
  Future<void> logout() async {
    // Meta logout implementation
  }
}

And we can use DIP to use AuthProvider everywhere

void authenticate(AuthProvider provider) {
  provider.login();
}

@msp98 are you suggesting something like this? I am starting this

[pavanpodila]

How will the interface look for the following login providers:

• email/password
• passwordless
• SAML within Org

the login method is where we can add arguments to specifically deal with provider specific details, so a Map<String, dynamic> will be required for the login method ..