Does SignInAsAuthenticationType allow me to get an OAuth token without overwriting existing claims?

Question

I need a user to login to a website using out of the box authentication to Facebook. I now need to link to the users drive in Google (and other services). I want to use ASP.Net Identity OAuth Identity providers to handle the token exchange, BUT I don't want it to touch an existing UserCredential or use it for SignIn of the UserPrincipal

My goal is to prevent

• AuthenticateCoreAsync from returning a AuthenticationTicket that results in modifications to the current logged in user identity
• A user shortcutting the authentication system using claims obtained from Google. (I should already have the user logged in via other means)
• Prevent an unexpected token/cookie from being used to create a valid session, creating a privilege escalation scenario?

Question

1. What effect does setting a custom grantIdentity have on IOwinContext.Authentication.SignIn()?

2. Does SignInAsAuthenticationType solve my need?

3. If not, when would this be used?

Theoretical code using Google provider

// The cookie needs to be First in the chain.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = "CustomExternal",
    AuthenticationMode = AuthenticationMode.Passive,
    CookieName = "MyAwesomeCookie",
    ExpireTimeSpan = TimeSpan.FromMinutes(5),
    //Additional custom cookie options....
});

//Note that SignInAsAuthenticationType == AuthenticationType
app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions
{
    AuthenticationType = "GoogleBackOffice",
    ClientId = "abcdef...",
    ClientSecret = "zyxwv....",
    SignInAsAuthenticationType = "CustomExternal"
});

Answer 1

The Visual Studio 2015 MVC Individual User Accounts template does something like this. You create your first account (with a local username and password or a remote provider), and then you can link other identities to that one. It does this linking by maintaining two cookies during the login, one for the app and one for the external identity.

If you look in the ManageController under LinkLoginCallback, you should be able to tweak the logic at that point to store the external identity tokens, but not grant it login access to your application.

In other words, logic like this should be managed at the authorization layer in your controller logic, not at the authentication layer in the auth middleware.