I am attempting to obtain a Kerberos Token from a C# Application (not web-based, a standalone executable).
I have referred to this question to figure out how to do it, but even trying both answers, I get the same problem.
When I reach the GetToken line (using Furkat's answer as a reference here), I get an exception:
KerberosRequestorSecurityToken securityToken = tokenProvider.GetToken(TimeSpan.FromMinutes(1)) as KerberosRequestorSecurityToken;
Here is the exception and the nested innerExceptions:
Exception: The NetworkCredentials provided were unable to create a Kerberos credential, see inner exception for details.
innerException: Authenticating to a service running under a user account which requires Kerberos multilegs, is not supported.
innerException: The function completed successfully, but must be called again to complete the context
I have some serious problems trying to find any examples of this working for a non-web based application, the StackOverflow question I linked is pretty much the closest I've got to getting what I need.
I also have problems figuring out exactly how things are supposed to work, since I can't get an example to work on my side. I'm looking for some sort of unique token for the user, that can then be passed to a SAML POST call to a server for Single Sign On. What will this token look like? Is it right to use TokenImpersonationLevel.Impersonation, instead of Identification here? (Identification gives me the same problem).
So my question is about my error and how to fix it, but I would really appreciate an explanation with the answer, telling me about the context (what was going wrong, what I misunderstood, etc).
Here's my complete Method. It's in Proof-Of-Concept stage right now, so forgive the temporary bad naming and ugly code. I'm making lots of trial-and-error.
public string Method5()
{
try
{
var userName1 = new WindowsPrincipal(WindowsIdentity.GetCurrent()).Identity.Name;
var domainName = userName1.Split('\\').First();
var userName = userName1.Split('\\').Last();
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
var domain = Domain.GetCurrentDomain().ToString();
using (var domainContext = new PrincipalContext(ContextType.Domain, domain))
{
string spn = UserPrincipal.FindByIdentity(domainContext, IdentityType.SamAccountName, userName).UserPrincipalName;
KerberosSecurityTokenProvider tokenProvider = new KerberosSecurityTokenProvider(spn, TokenImpersonationLevel.Impersonation, CredentialCache.DefaultNetworkCredentials);
KerberosRequestorSecurityToken securityToken = tokenProvider.GetToken(TimeSpan.FromMinutes(1)) as KerberosRequestorSecurityToken;
string serviceToken = Convert.ToBase64String(securityToken.GetRequest());
return serviceToken;
}
}
catch (Exception ex)
{
return "Failure";
}
}
The error indicates that you are requesting a Kerberos User2User token. The multileg bit is correct, but somewhat misleading. The issue is that AD determines it's a U2U request and makes the API return a specific error, indicating it's U2U and requires a retry with different parameters. .NET doesn't understand this retry, hence the error.
The reason you're requesting a U2U token is because you're calling the token provider asking for it to request a token to access the given SPN, which in this case is just an ordinary user. This is generally not useful in client/server applications.
KerberosSecurityTokenProvider tokenProvider = new KerberosSecurityTokenProvider(spn, TokenImpersonationLevel.Impersonation, CredentialCache.DefaultNetworkCredentials);
What this code is doing is saying for a user that has been inferred by impersonation or authentication previously, request a token so that user can access a remote service {SPN}. A token is only useful for a single user to a single service. You can't just collect a token and user it everywhere. This is not how Kerberos-proper works. Kerberos determines the name of that service by the SPN. In this case it already knows who the caller is.
So, the correct solution is:
var identity = Thread.CurrentPrincipal.Identity; // domain\username1
var spn = "host/someservice.domain.com";
var tokenProvider = new KerberosSecurityTokenProvider(spn);
var securityToken = tokenProvider.GetToken(TimeSpan.FromMinutes(1)); // token for username1 to host/someservice.domain.com
I'm creating a service to search for users in LDAP. This should be fairly straightforward and probably done a thousand times, but I cannot seem to break through properly. I thought I had it, but then I deployed this to IIS and it all fell apart.
The following is setup as environment variables:
ldapController
ldapPort
adminUsername 🡒 Definitely a different user than the error reports
adminPassword
baseDn
And read in through my Startup.Configure method.
EDIT I know they are available to IIS, because I returned them in a REST endpoint.
This is my code:
// Connect to LDAP
LdapConnection conn = new LdapConnection();
conn.Connect(ldapController, ldapPort);
conn.Bind(adminUsername, adminPassword);
// Run search
LdapSearchResults lsc = conn.Search(
baseDn,
LdapConnection.SCOPE_SUB,
lFilter,
new string[] { /* lots of attributes to fetch */ },
false
);
// List out entries
var entries = new List<UserDto>();
while (lsc.hasMore() && entries.Count < 10) {
LdapEntry ent = lsc.next(); // <--- THIS FAILS!
// ...
}
return entries;
As I said, when debugging this in visual studio, it all works fine. When deployed to IIS, the error is;
Login failed for user 'DOMAIN\IIS_SERVER$'
Why? The user specified in adminUsername should be the user used to login (through conn.Bind(adminUsername, adminPassword);), right? So why does it explode stating that the IIS user is the one doing the login?
EDIT I'm using Novell.Directory.Ldap.NETStandard
EDIT The 'user' specified in the error above, is actually NOT a user at all. It is the AD registered name of the computer running IIS... If that makes any difference at all.
UPDATE After consulting with colleagues, I set up a new application pool on IIS, and tried to run the application as a specified user instead of the default passthrough. Exactly the same error message regardless of which user I set.
Try going via Network credentials that allows you to specify domain:
var networkCredential = new NetworkCredential(userName, password, domain);
conn.Bind(networkCredential);
If that does not work, specify auth type basic (not sure that the default is) before the call to bind.
conn.AuthType = AuthType.Basic;
Update 2017!
The issue I had when I posted the original question has got nothing to do with the recent changes Facebook made when they forced everyone to version 2.3 of their API. For a solution to that specific problem, see sammy34's answer below. Version 2.3 of the /oauth/access_token endpoint now returns JSON instead of form-encoded values
For historical reasons, here's my original question/issue:
I've got an MVC5 Web application which is using the built-in support for authentication via Facebook and Google. When we built this app a few months ago, we followed this tutorial: http://www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on and everything worked great.
Now, all of a sudden, the Facebook authentication has just stopped working alltogether. The Google authentication still works great.
Description of the problem: We click the link to connect using Facebook, we are redirected to Facebook where we are prompted if we wan't to allow our Facebook app access to our profile. When we click "OK" we are redirected back to our site, but instead of being logged in we simply end up at the login screen.
I've gone through this process in debug mode and I've got this ActionResult in my account controller as per the tutorial mentioned above:
// GET: /Account/ExternalLoginCallback
[AllowAnonymous]
public async Task<ActionResult> ExternalLoginCallback(string returnUrl)
{
var loginInfo = await AuthenticationManager.GetExternalLoginInfoAsync();
if (loginInfo == null)
{
return RedirectToAction("Login");
}
............
When stepping through the code and upon returning from Facebook, the loginInfo object is always NULL, which causes the user to be redirected back to the login.
In order to understand what is actually happening behind the scenes, I installed Fiddler and monitored the HTTP traffic. What I disovered is that upon clicking "OK" at the Facebook permission dialog, Facebook redirects back to our application with this URL:
https://localhost/signin-facebook?code=<access-token>
This URL is not an actual file and probably handled by some controller/handler built into this OWIN framework I'm guessing. Most likely, it is connecting back to Facebook using the given code to query information about the user which is trying to login. Now, the problem is that instead of doing that, we are redirected to:
/Account/ExternalLoginCallback?error=access_denied
Which I'm sure is something Facebook is doing, that is, instead of giving us the user data, it's redirecting us back with this error message.
This causes the AuthenticationManager.GetExternalLoginInfoAsync(); to fail and always return NULL.
I'm completely out of ideas. As far as we know, we did not change anything on our end.
I've tried creating a new Facebook app, I've tried following the tutorial again but I always have the same problem.
Any ideas welcome!
Update!
OK, this is driving me insane! I've now manually gone through the steps required to perform the authentication and everything works great when I do that. Why on earth is this not working when using the MVC5 Owin stuff?
This is what I did:
// Step 1 - Pasted this into a browser, this returns a code
https://www.facebook.com/dialog/oauth?response_type=code&client_id=619359858118523&redirect_uri=https%3A%2F%2Flocalhost%2Fsignin-facebook&scope=&state=u9R1m4iRI6Td4yACEgO99ETQw9NAos06bZWilJxJrXRn1rh4KEQhfuEVAq52UPnUif-lEHgayyWrsrdlW6t3ghLD8iFGX5S2iUBHotyTqCCQ9lx2Nl091pHPIw1N0JV23sc4wYfOs2YU5smyw9MGhcEuinvTAEql2QhBowR62FfU6PY4lA6m8pD3odI5MwBYOMor3eMLu2qnpEk0GekbtTVWgQnKnH6t1UcC6KcNXYY
I was redirected back to localhost (which I had shut down at this point to avoid being redirected immediately away). The URL I was redirected to is this:
https://localhost/signin-facebook?code=<code-received-removed-for-obvious-reasons>
Now, I grabbed the code I got and used it in the URL below:
// Step 2 - opened this URL in a browser, and successfully retrieved an access token
https://graph.facebook.com/oauth/access_token?client_id=619359858118523&redirect_uri=https://localhost/signin-facebook&client_secret=<client-secret>&code=<code-from-step-1>
// Step 3 - Now I'm able to query the facebook graph using the access token from step 2!
https://graph.facebook.com/me?access_token=<access-token-from-step-2>
No errors, everything works great! Then why the hell is this not working when using the MVC5 Owin stuff? There's obviously something wrong with the OWin implementation.
Update 22nd April 2017: Version 3.1.0 of the Microsoft.Owin.* packages are now available. If you're having problems after Facebook's API changes from the 27th March 2017, try the updated NuGet packages first. In my case they solved the problem (working fine on our production systems).
Original answer:
In my case, I woke up on the 28th March 2017 to discover that our app's Facebook authentication had suddenly stopped working. We hadn't changed anything in the app code.
It turns out that Facebook did a "force upgrade" of their graph API from version 2.2 to 2.3 on 27th March 2017. One of the differences in these versions of the API seems to be that the Facebook endpoint /oauth/access_token responds no longer with a form-encoded content body, but with JSON instead.
Now, in the Owin middleware, we find the method protected override FacebookAuthenticationHandler.AuthenticateCoreAsync(), which parses the body of the response as a form and subsequently uses the access_token from the parsed form. Needless to say, the parsed form is empty, so the access_token is also empty, causing an access_denied error further down the chain.
To fix this quickly, we created a wrapper class for the Facebook Oauth response
public class FacebookOauthResponse
{
public string access_token { get; set; }
public string token_type { get; set; }
public int expires_in { get; set; }
}
Then, in OwinStart, we added a custom back-channel handler...
app.UseFacebookAuthentication(new FacebookAuthenticationOptions
{
AppId = "hidden",
AppSecret = "hidden",
BackchannelHttpHandler = new FacebookBackChannelHandler()
});
...where the handler is defined as:
public class FacebookBackChannelHandler : HttpClientHandler
{
protected override async System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
{
var result = await base.SendAsync(request, cancellationToken);
if (!request.RequestUri.AbsolutePath.Contains("access_token"))
return result;
// For the access token we need to now deal with the fact that the response is now in JSON format, not form values. Owin looks for form values.
var content = await result.Content.ReadAsStringAsync();
var facebookOauthResponse = JsonConvert.DeserializeObject<FacebookOauthResponse>(content);
var outgoingQueryString = HttpUtility.ParseQueryString(string.Empty);
outgoingQueryString.Add(nameof(facebookOauthResponse.access_token), facebookOauthResponse.access_token);
outgoingQueryString.Add(nameof(facebookOauthResponse.expires_in), facebookOauthResponse.expires_in + string.Empty);
outgoingQueryString.Add(nameof(facebookOauthResponse.token_type), facebookOauthResponse.token_type);
var postdata = outgoingQueryString.ToString();
var modifiedResult = new HttpResponseMessage(HttpStatusCode.OK)
{
Content = new StringContent(postdata)
};
return modifiedResult;
}
}
Basically, the handler simply creates a new HttpResponseMessage containing the equivalent form-encoded information from the Facebook JSON response. Note that this code uses the popular Json.Net package.
With this custom handler, the problems seem to be resolved (although we're yet to deploy to prod :)).
Hope that saves somebody else waking up today with similar problems!
Also, if anybody has a cleaner solution to this, I'd love to know!
Noticed this problem yesterday. Facebook does not support Microsoft.Owin.Security.Facebook version 3.0.1 anymore. For me it worked to install version 3.1.0. To update to 3.1.0, run the command Install-Package Microsoft.Owin.Security.Facebook in Package Manager Console: https://www.nuget.org/packages/Microsoft.Owin.Security.Facebook
Ok I've got a solution to the problem.
This is the code I had previously in my Startup.Auth.cs file:
var x = new FacebookAuthenticationOptions();
//x.Scope.Add("email");
x.AppId = "1442725269277224";
x.AppSecret = "<secret>";
x.Provider = new FacebookAuthenticationProvider()
{
OnAuthenticated = async context =>
{
//Get the access token from FB and store it in the database and
//use FacebookC# SDK to get more information about the user
context.Identity.AddClaim(new System.Security.Claims.Claim("FacebookAccessToken",context.AccessToken));
context.Identity.AddClaim(new System.Security.Claims.Claim("urn:facebook:name", context.Name));
context.Identity.AddClaim(new System.Security.Claims.Claim("urn:facebook:email", context.Email));
}
};
x.SignInAsAuthenticationType = DefaultAuthenticationTypes.ExternalCookie;
app.UseFacebookAuthentication(x);
Notice how the
x.Scope.Add("email")
line has been commented out, but still I'm query-ing for the e-mail later in the OnAuthenticated handler? Yup, that's right. For some reason this worked flawlessly for a few weeks.
My solution was to simply uncomment the x.Scope.Add("email"); line to make sure that the scope=email variable was present in the initial request to Facebook.
Now everything works like it did!
I cannot understand why this worked before like it was. The only explanation I can come up with is that Facebook changed something on their end.
I had this same issue with the Google Authentication. The following worked for me: Changes to Google OAuth 2.0 and updates in Google middleware for 3.0.0 RC release
The last Facebook upgrade was on 2015-02-09 (https://www.nuget.org/packages/Microsoft.AspNet.WebPages.OAuth/)
The latest version of the API at that point was version 2.2. Version 2.2 expired on the 25th of March 2017, which is coincidentally when the problem started. (https://developers.facebook.com/docs/apps/changelog)
I'm guessing Facebook probably automatically upgraded the API and now the MS OAUTH library is unable to parse the new response.
tldr: The Microsoft WebPages OAuth library is outdated (for FB at least) and you'll probably have to find another solution
The above solutions didn't work for me. In the end, it seemed to be related to the Session. By "waking up" the session in the previous call, it would no longer return null from the GetExternalLoginInfoAsync()
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult ExternalLogin(string provider, string returnUrl)
{
Session["WAKEUP"] = "NOW!";
// Request a redirect to the external login provider
return new ChallengeResult(provider, Url.Action("ExternalLoginCallback", "Account", new { ReturnUrl = returnUrl }));
}
Like the OP, I had the 3rd party auth working fine for a long time then suddenly it stopped. I beleive it was due to the changes made in my code when I set up the Session to use Redis Cache on Azure.
I had this problem as well, but it wasn't caused by the scope setting. Took me a long time to figure that out, but what finally clued me in was by setting a custom logger by setting the following in OwinStartup.Configuration(IAppBuilder app).
app.SetLoggerFactory(new LoggerFactory());
// Note: LoggerFactory is my own custom ILoggerFactory
This outputted the following:
2014-05-31 21:14:48,508 [8] ERROR
Microsoft.Owin.Security.Cookies.CookieAuthenticationMiddleware
[(null)] - 0x00000000 - Authentication failed
System.Net.Http.HttpRequestException: An error occurred while sending
the request. ---> System.Net.WebException: The remote name could not
be resolved: 'graph.facebook.com' at
System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult
ar) --- End of inner exception stack trace --- at
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task
task) at
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at
Microsoft.Owin.Security.Facebook.FacebookAuthenticationHandler.d__0.MoveNext()
Based on the above call stack I found that my Azure VM was unable to resolve graph.facebook.com. All I had to do to fix that was to run "ipconfig /registerdns" and I was all fixed...
I have been working on solution for three days. And I've just found it on github(https://github.com/aspnet/AspNetKatana/issues/38#issuecomment-290400987)
var facebookOptions = new FacebookAuthenticationOptions()
{
AppId = "xxxxx",
AppSecret = "xxxxx",
};
// Set requested scope
facebookOptions.Scope.Add("email");
facebookOptions.Scope.Add("public_profile");
// Set requested fields
facebookOptions.Fields.Add("email");
facebookOptions.Fields.Add("first_name");
facebookOptions.Fields.Add("last_name");
facebookOptions.Provider = new FacebookAuthenticationProvider()
{
OnAuthenticated = (context) =>
{
// Attach the access token if you need it later on for calls on behalf of the user
context.Identity.AddClaim(new System.Security.Claims.Claim("FacebookAccessToken", context.AccessToken));
foreach (var claim in context.User)
{
//var claimType = string.Format("urn:facebook:{0}", claim.Key);
var claimType = string.Format("{0}", claim.Key);
string claimValue = claim.Value.ToString();
if (!context.Identity.HasClaim(claimType, claimValue))
context.Identity.AddClaim(new System.Security.Claims.Claim(claimType, claimValue, "XmlSchemaString", "Facebook"));
}
return Task.FromResult(0);
}
};
app.UseFacebookAuthentication(facebookOptions);
And to get values
var info = await AuthenticationManager.GetExternalLoginInfoAsync();
if (info != null)
{
var firstName = info.ExternalIdentity.Claims.First(c => c.Type == "first_name").Value;
var lastName = info.ExternalIdentity.Claims.First(c => c.Type == "last_name").Value;
}
Check you get an outside internet connection from your application. If not, fix your outside internet connection. My problem was I was using an EC2 AWS instance that suddenly stopped connecting to the internet. It took me a while to realize that was the problem.
This drove me insane. All was working until I deployed to my staging environment. I was using Microsoft.Owin.Security.Facebook version 3.0.1 from Nuget. Updated it to the prelease version 3.1.0 from Nuget and I no longer got the access denied error...
Even though i did everything what sammy34 said, it did not work for me. I was at the same point with HaukurHaf: When i make apirequest manually on browser it works perfect, but if i use my mvc app, GetExternalLoginInfoAsync() always returns null.
So i changed some rows on sammy34's codes like on this comment: https://stackoverflow.com/a/43148543/7776015
Replaced:
if (!request.RequestUri.AbsolutePath.Contains("/oauth"))
{
request.RequestUri = new Uri(request.RequestUri.AbsoluteUri.Replace("?access_token", "&access_token"));
}
var result = await base.SendAsync(request, cancellationToken);
if (!request.RequestUri.AbsolutePath.Contains("/oauth"))
{
return result;
}
Instead of:
var result = await base.SendAsync(request, cancellationToken);
if (!request.RequestUri.AbsolutePath.Contains("access_token"))
return result;
And added this row into my FacebookAuthenticationOptions:
UserInformationEndpoint = "https://graph.facebook.com/v2.8/me?fields=id,name,email,first_name,last_name,picture"
and now it works.(fields and that parameters optional)
Note: I did not update Microsoft.Owin.Security.Facebook
I have some authentication code for an Azure hosted mobile app that is being called from a WPF client. It attempts to authenticate the user as part of the initialisation of a Prism module that contains an authentication service. The async method to authenticate is written as follows:
public async Task AcquireTokenAndAuthenticateWebApiAsync()
{
try
{
//todo these are hardcoded :-( ... need to come from app settings!!
// settings for authentication
string resourceId = "https://windinspectordevmobileappservice.azurewebsites.net";
//string resourceId = "http://localhost:51293/";
string clientId = "5fe3b968-1d23-4667-9c31-86fac4ab4aec";
Uri redirectUri = new Uri("https://windinspectordevmobileappservice.azurewebsites.net/.auth/login/done"); // Page to say you have sucessfully signed in
const string appServiceUrl = "https://windinspectordevmobileappservice.azurewebsites.net";
string authorityUri = "https://login.windows.net/dnv.onmicrosoft.com";
this.authContext = new AuthenticationContext(authorityUri);
// authenticate against the AD
var result = await authContext.AcquireTokenAsync(
resourceId, clientId, redirectUri,
new PlatformParameters(PromptBehavior.Auto, false));
this.authResult = result;
// authenticate against the web api
Client = new MobileServiceClient(appServiceUrl);
JObject payload = new JObject();
payload["access_token"] = authResult.AccessToken;
var user = await Client.LoginAsync(
MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory,
payload).ConfigureAwait(false);
this.authenticatedUserName = this.authResult.UserInfo.DisplayableId;
}
catch (InvalidOperationException e)
{
}
}
About 50% of the time the call to LoginAsync is successful. However, at other times the LoginAsync call simply times out (the task times out with an exception). What could cause this?
I've attempted to turn on the logs in the client, but see no reason for the timeout in the logs:
Application Log from Successful LoginAsync Call:
2017-01-27T16:24:29 PID[23292] Verbose Received request: POST https://windinspectordevmobileappservice.azurewebsites.net/.auth/login/aad
2017-01-27T16:24:29 PID[23292] Verbose JWT validation succeeded. Subject: '__HeuajpWfXmUxZBrDvwAqcV0UOirMVrs5iCwvpnrrY', Issuer: 'https://sts.windows.net/adf10e2b-b6e9-41d6-be2f-c12bb566019c/'.
2017-01-27T16:24:29 PID[23292] Information Login completed for 'max.palmer#dnvgl.com'. Provider: 'aad'.
2017-01-27T16:24:29 PID[23292] Information Sending response: 200.77 OK
2017-01-27 16:24:29 WINDINSPECTORDEVMOBILEAPPSERVICE POST /.auth/login/aad X-ARR-LOG-ID=4f08
Application Log from LoginAsync call that times out:
734a-75e2-4674-a9c8-bd74caa1aa3f 443 - 80.5.95.115 ZUMO/3.1+(lang=Managed;+os=Windows;+os_version=6.2.0.9200;+arch=Win32NT;+version=3.1.50105.0) - - windinspectordevmobileappservice.azurewebsites.net 200 77 0 1089 2739 109
2017-01-27T16:26:29 No new trace in the past 1 min(s).
2017-01-27T16:26:34 PID[23292] Verbose Received request: POST https://windinspectordevmobileappservice.azurewebsites.net/.auth/login/aad
2017-01-27T16:29:29 No new trace in the past 1 min(s).
NB looking at these logs, when the login call is successful, I see "JWT validation succeeded", when it is not, I never see this line and it times out. I've checked many samples online for using this authentication pattern and the code looks good to me. I've also tried shifting the code to be called via an async command Execute method so that I'm async all the way (up).
Any thoughts on what else I can do to try to understand what might be the cause of the timeout in some cases?
One question I had is that the source code for MobileServiceClient is hosted at:
https://github.com/Azure/azure-mobile-services
However, this repository is marked as deprecated (or at least Mobile Services is deprecated in favour of Mobile Apps). I presume this class is still the one to use with Mobile Apps?
Is there any way I can step into the code? Do I need to fetch the source from Git and debug that?
I am a newbie at ASP.net programming. This is in reference to the Facebook C# SDK, I have managed to set up all the steps required for authentication on this SDK. However, I keep getting a null from the following code:
(reference: http://csharpsdk.org/docs/web/getting-started#5)
var accessToken = Session["AccessToken"].ToString(); //This line returns null and crashes
var client = new FacebookClient(accessToken);
dynamic result = client.Get("me", new { fields = "name,id" });
string name = result.name;
string id = result.id;
Just like in the example, I had set up a generic handler to set up the session variable to be stored in the HttpContext.Session object.
I even tried to modify the offending line to directly access the HttpContext and retrieve the access token:
var accessToken = HttpContext.Current.Session["AccessToken"].ToString();
but this yielded the same result.
Have I missed out something in the webconfig or is there some other way I can store the access token when shifting from the handler to the log in page?
Make sure in your Facebook developer settings that you do not have query string selected for your app as auth token paramenter!!!
This is the default mode and this wont work unless you do the following:
http://developer.facebook.com
Open your app page.
Then go Settings --> Auth Dialog --> Auth Token Parameter and select URI Fragment.
100% sure this is your problem. It's not included in any literature I found, and it's a damn shame.
If it is returning null then I would assume that the Session value is not being set - have you debugged to make sure the code which sets the session is being hit?
Looking at the linked article - it uses a HttpHandler to do this bit but does not mention anything about registering it in the Web.Config - have you done this? If not see here http://msdn.microsoft.com/en-us/library/46c5ddfy.aspx