Xamarin Social Authentication with Native SDK's and OAuth through SFSafariViewController and Android Custom Tabs.

NOTE: This is currently a work in progress...

Social authentication in mobile apps has evolved since the beginning of Xamarin. Providers such as Google and Facebook offer native SDK's to help deliver a delightful user experience when authentication with their platforms.

iOS and Android have both recently provided their own extensions of the operating system browser (SFSafariViewController and CustomTabs) and now prefer (and in some cases such as Google, require) that you use them for enabling social authentication in your apps.

Plugin.SocialAuth aims to provide you with the latest and greatest options for adding social authentication to your Xamarin apps as easily as possible.

• NuGet packages
• Automatic handling of refreshing of access tokens in OAuth2
• More known provider support with specific authentication implementations (Fitbit, Meetup, etc).
• Windows UWP support!
• Helpers to create Authenticated HttpRequestMessage objects for further user with provider API's

You can pick and choose which providers you want to use on each platform.

[*] All of the Native SDK Provider options are packaged as separate NuGet packages in case you don't need them in your app (or want to use one of the OAuth providers instead of the Native SDK implementation), so that you don't incur their size or dependencies in such a case.

The core API is available in a .NET Standard 1.4 library via NuGet.

There is a shared instance of SocialAuthManager which you can access to authenticate. Here is an example of invoking the Native Facebook SDK authentication flow:

// See if we previously logged in with any particular account
var existingAccount = SocialAuthManager.Current.AccountStore.FindAnyAccount(ProviderType.Facebook);

// Authenticate with Facebook's native SDK
var account = await SocialAuthManager.Current.AuthenticateFacebookAsync(new FacebookAuthOptions(), existingAccount?.Id);

In the above sample, we are first trying to look up any existing Facebook account from our local AccountStore in order to pass the Id into the Authentication call.

Plugin.SocialAuth takes care of caching authenticated accounts for you so that future Authentication calls will avoid the UI authorization flow, if the cached account is unexpired and valid.

We can just omitt the Id in the Authentication call if we don't care to look in the local cache first.

Before we can actually use the sample above, and call the Authentication methods, we need to do some setup.

Additionally each provider and platform may require specific application configuration.

In your AppDelegate's FinishedLaunching method we need to add some calls to Init and Register our providers:

// Init the things
SocialAuth.Init();
FacebookAuthProvider.Init(SocialKeys.FACEBOOK_APP_ID;

Some providers like Facebook require a specific Init call like in the first block above, while others do not.

Next, we need to register the different provider implementations we would like to associate with the provider types:

//Register custom handlers
SocialAuthManager.Current.RegisterProvider<FacebookAuthProvider>(ProviderType.Facebook);
SocialAuthManager.Current.RegisterProvider<GoogleAuthProvider>(ProviderType.Google);
SocialAuthManager.Current.RegisterProvider<TwitterSafariServicesAuthProvider>(ProviderType.Twitter);
SocialAuthManager.Current.RegisterProvider<OAuth2SafariServicesProvider>("fitbit");

You can see it's possible to use a custom providerTypeId, but the ProviderType enum will contain most common providers.

Notice the generic type argument of the RegisterProvider call contains the implementation type that will be used when the authentication call is made for the given provider type.

This means it's possible to register an OAuth2SafariServicesProvider as the implementation for ProviderType.Facebook if you'd rather use SFSafariViewController instead of the Native Facebook SDK.

Some providers will require relaying calls from your AppDelegate.OpenUrl override to SocialAuthManager.OpenUrl. You should add the following code to your AppDelegate:

// We need to relay open url calls to social auth
public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation)
{
	if (Plugin.SocialAuth.iOS.SocialAuth.OpenUrl(application, url, sourceApplication, annotation))
		return true;

	return false;
}

Android is very similar to iOS, but instead, you should call your Init's and RegisterProvider's in the MainActivity of your app.

Android also requires that we relay our current Activity's OnActivityResult (if you're using Xamarin.Forms this should be in your MainActivity):

// Pass OnActivityResult back into social auth
protected override void OnActivityResult(int requestCode, Result resultCode, Intent data)
{
	base.OnActivityResult(requestCode, resultCode, data);

	Plugin.SocialAuth.Droid.SocialAuth.OnActivityResult(requestCode, resultCode, data);
}

Also, in some cases where we will receive callbacks into our own application (eg: in the case of OAuth1CustomTabsAuthProvider and OAuth2CustomTabsProvider), we need to setup an Activity subclassing Plugin.SocialAuth.Droid.CustomTabs.OAuthCallbackActivity which registers itself with an IntentFilter handling the DataScheme of your Callback/Redirect URL that you are using with your OAuth provider. Here's an example that registers the scheme plugin.socialauth:// and assumes you're passing something like plugin.socialauth://twitter to your authentication provider as your callback/redirect URL:

// We need this callback to redirect callbacks into our app to SocialAuth to handle
[Activity(NoHistory = true, LaunchMode = Android.Content.PM.LaunchMode.SingleTop)]
[IntentFilter(new[] { Intent.ActionView },
			  Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable }, DataScheme = "plugin.socialauth")]
public class SocialAuthOAuth1CallbackActivity : Plugin.SocialAuth.Droid.CustomTabs.OAuthCallbackActivity
{
}

Each social provider will have specific guides to setting up keys/credentials and in some cases your app configuration for iOS/Android in order to make authentication work.

You will need to visit Facebook for Developers to setup an Application. Additionally there are instructions for setting up iOS and Android app login:

• Facebook Login for iOS Quickstart
• Facebook Login for Android

NOTE: Facebook Login for iOS requires that you add specific URL schemes to your Info.plist file.

NOTE: Facebook Login for Android requires that you add some specific items to your AndroidManifest.xml file. Additionally you will need to provide .keystore hashes in the Facebook Developer portal under your Android App settings. Be sure to add hashes for your debug.keystore as well as the .keystore used for signing Play store builds.

You will need to visit Google API Developer Console to create an application and Credentials to use in your apps. There are specific guides for iOS and Android to setting up your app as well:

• Google Sign-In for iOS
• Google Sign-In for Android

NOTE: Google for iOS requires that you add some specific items to your Info.plist file. Additionally you will need to add a GoogleService-Info.plist in your iOS app project.

NOTE: Google for Android is a bit tricky when it comes to setting up your keys in the Google API Developer Console. You will want to setup an Android key credential for the ClientId but for the ServerClientId you will want to setup an OAuth web application type credential.

The SocialAuthManager handles caching account information including tokens and in some provider cases, basic profile info, if you pass in the Id of the IAccount returned from a previous Authentication call. Omitting this parameter will cause the cache to be skipped.

This means when you call the AuthenticateAsync (..) method, if there are still unexpired / valid tokens in your cache, the Account object will be immediately returned instead of going through the user sign in flow again.

If there is no associated account already signed in and cached, calling AuthenticateAsync (..) will cause the sign in flow to begin.

Both Google's and Facebook's Native SDKs additionally manage their own cache. Plugin.SocialAuth will attempt to use these caches if its own cache is invalid. In some cases, this means the user will not need to be asked to sign in (e.g.: Facebook can sign in automatically if you've already granted the application access with the same account on another device).

In the case of OAuth2 providers, if there is a refresh_token in the cache and the access_token is expired, a call to refresh the access token will be attempted. If successful, the UI authentication flow can be avoided and the new access token and refresh tokens will be cached for future use.

On both iOS and Android, account caches are stored using platform specific secure storage API's.

Copyright (c) 2017 Jonathan Dick

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.