Simplified OAuth, SSO, Native Auth in separate module

[jan-tennert]

What kind of change does this PR introduce?

Feature, the target branch is probably going to change, since this PR would be included in 4.0

What is the current behavior?

auth-kt does two things: mirroring the JS SDK in terms of API methods but also providing platform specific implementations for stuff like OAuth, Deeplinks, etc. This approach worked, but is now getting even more bloated with the addition of passkeys and a proposed API in #1283 (which is now included in this PR). Also, people not using these platform-specific implementation, still have the needed dependencies included, which is not ideal.

What is the new behavior?

Everything below is work-in-progress. Note that if this PR goes through with the proposed changes, compose-auth might get obsolete and removed in 4.0

Base changes

auth-kt really only provides:
(1) Methods to call the Supabase API (now with split auth.signInWithPassword(), auth.signInWithOtp(), auth.signInWithIdToken(), etc for SDK parity)
(2) Handle session management, if not disabled (this PR also makes all API related methods return a UserSession and also an option to disable the session importing into memory, so it is even easier for server-side applications)

auth-native provides:

• Seamless platform specific implementations for OAuth, Native Auth, Passkeys, Lifecycle Management, Deeplinks (of depending on the platform)

The only thing you have to do:

install(Auth.withNative())

Note that the base auth-kt doesn't have any of these methods, since they would need platform specific dependencies. If users decide to make their own implementation they can just use auth.getOAuthUrl(...) and auth.passkeys

New syntax

Sign in [With Email() or Phone()]

val session = supabase.auth.signInWithPassword(Email("myEmail@example.com"), password = "123345") {
        // ...
}

Sign in with OTP

supabase.auth.signInWithOtp(Email("myEmail@example.com")) {
      // ...
}

Sign up [with Email() or Phone()]

val response = supabase.auth.signUp(Email("myEmail@example.com"), password = "12345") {
    // ...
}
println(response.session)
println(response.user)

Sign in with ID Token

val session = supabase.auth.signInWithIdToken(OAuthProviders.GOOGLE, token = "12343") {
    // ...
}

Native-Auth module:
Sign in with OAuth

supabase.auth.signInWithOAuth(OAuthProviders.GOOGLE) {
    // ...
}

Linking identity

supabase.auth.linkIdentity(OAuthProviders.GOOGLE) {
    // ...
}

Sign in with SSO

supabase.auth.signInWithSSO(SSODomain("domain")) 
supabase.auth.signInWithSSO(SSOProvider("providerId"))

Native Google Auth (or OAuth as a fallback)

// required for Android:
install(Auth.withNative()) {
    nativeAuth {
         googleClientId = "..."
    }
}
val result = supabase.auth.signWithGoogle()
when(result) {
    GoogleSignInResult.Cancelled -> TODO()
    GoogleSignInResult.OAuthInitiated -> TODO()
    is GoogleSignInResult.Success -> TODO()
}

Native Apple Auth (or OAuth as a fallback)

val result = supabase.auth.signWithApple()
when(result) {
    AppleSignInResult.Cancelled -> TODO()
    AppleSignInResult.OAuthInitiated -> TODO()
    is AppleSignInResult.Success -> TODO()
}

Android / iOS OAuth related changes

Android

On Android, the only thing you have to do now is set the app scheme and optionally the host in the build configuration:

android {

    defaultConfig {
        manifestPlaceholders["supabaseAuthScheme"] = "myScheme"
        // optional: 
        manifestPlaceholders["supabaseAuthHost"] = "myHost"
    }
    
}

The library will take care of everything else. No more handleDeeplinks() or something similar. The library will also catch magic links.

iOS

On iOS, ASWebAuthenticationSession is now used for OAuth, fixing #1253 and also making the process more iOS idiomatic. For magic links / deeplinks from outside the app, you still have to use handleDeeplinks(), but with a new method for better visbility in Swift (SupabaseDeeplinkHandlerKt.handleDeeplinks(). The scheme entry in PList.info is still required as is setting the scheme in the config:

install(Auth) {
     appScheme = "myScheme" 
}

Todos:

• Fix tests
• Think about maybe making it possible to use the credentials while signing in (so you can set them in the user's data)
• KDocs
• Documentation
• Passkeys
• Google Auth on iOS Will probably not happen in this PR, waiting for SwiftPM getting more stable

[hieuwu]

I wonder now that we have auth-native , how about ones in supabase-kt-plugins ? Should native auth related code in plugins be moved to auth-native ?

[jan-tennert]

I wonder now that we have auth-native , how about ones in supabase-kt-plugins ? Should native auth related code in plugins be moved to auth-native ?

Do you mean what happens to compose auth?

Everything below is work-in-progress. Note that if this PR goes through with the proposed changes, compose-auth might get obsolete and removed in 4.0

[hieuwu]

I wonder now that we have auth-native , how about ones in supabase-kt-plugins ? Should native auth related code in plugins be moved to auth-native ?

Do you mean what happens to compose auth?

Everything below is work-in-progress. Note that if this PR goes through with the proposed changes, compose-auth might get obsolete and removed in 4.0

Interesting. This would make the integration more convinient 👍

[jan-tennert]

cc @grdsdev

[hieuwu]

Nice one @jan-tennert 👍. I was about to ask if we can replace spm4kmp from the plugins to this. Let me know if you need some iOS testing

[jan-tennert]

Yea I'll probably leave that one out of this PR. Also not completely sure how that swift pm integration works with publishing yet