locked
Azure AD Authentication Back Button Issues RRS feed

  • Question

  • User-2120644463 posted

    I am trying to resolve an issue with ASP.NET in regards to how it facilitates authentication against Azure AD.  Overall I am able to successfully authenticate, however there are seemingly unavoidable issues when the user presses the back button.  Specifically, the user eventually sees a series of error related pages as described further below.

    The steps below are what can be taken to replicate the issue, followed by the error pages themselves.

    1) Visual Studio 2019 16.5.4 > Create New Project > ASP.NET Core Web Application > [Provide details such as project name] > Create > .NET Core, ASP.NET Core 3.1, Web Application, Authentication configured for Work or School Accounts and Cloud - Single Organization > Create.

    2) All items in Startup.cs, appsettings.json, and the Azure Active Directory App Registration are all kept at their respective defaults.  I have provided the Startup.cs code further below if that is of any interest.

    3) Run application (debugging or not), authenticate, arrive at default page.  Pressing the back button repeatedly results in the following:
    First, Document Expired Browser page
    Second, Accepts POST requests only Azure page
    Third, Application error page (technically this can be handled by defining custom error event handling code demonstrated further below).

    My question is whether or not there is a means of avoiding the error related pages.  Ideally, when the user presses the back button they would avoid being returned to any authentication related pages and the browser will take them to whatever page they may have been on prior to the authentication process beginning.  Part of what amplifies the issue is that users are sometimes unable to simply keep pressing the back button in order to get to the pre-authentication related pages due to being automatically redirected to the authentication process.

    Also note that I am trying to avoid manually redirecting users to a specific page given users may come from a variety of locations.  For example, some users may initially come from a home page that doesn't require authentication, whereas others may be at entirely different location by the use of bookmarks.

    Finally, the exact error related pages that display will vary based on the browser used.  For this demonstration I am using FireFox.  Chrome has similar issues.

    Thanks

    Startup.cs

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Threading.Tasks;
    using Microsoft.AspNetCore.Authentication;
    using Microsoft.AspNetCore.Authentication.AzureAD.UI;
    using Microsoft.AspNetCore.Authorization;
    using Microsoft.AspNetCore.Builder;
    using Microsoft.AspNetCore.Hosting;
    using Microsoft.AspNetCore.HttpsPolicy;
    using Microsoft.AspNetCore.Mvc.Authorization;
    using Microsoft.Extensions.Configuration;
    using Microsoft.Extensions.DependencyInjection;
    using Microsoft.Extensions.Hosting;
    
    namespace ASPNETFormAuthenticationDemoDotNetCore
    {
    	public class Startup
    	{
    		public Startup(IConfiguration configuration)
    		{
    			Configuration = configuration;
    		}
    
    		public IConfiguration Configuration { get; }
    
    		// This method gets called by the runtime. Use this method to add services to the container.
    		public void ConfigureServices(IServiceCollection services)
    		{
    			services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
    				.AddAzureAD(options => Configuration.Bind("AzureAd", options));
    
    			services.AddRazorPages().AddMvcOptions(options =>
    			{
    				var policy = new AuthorizationPolicyBuilder()
    					.RequireAuthenticatedUser()
    					.Build();
    				options.Filters.Add(new AuthorizeFilter(policy));
    			});
    		}
    
    		// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    		public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    		{
    			if (env.IsDevelopment())
    			{
    				app.UseDeveloperExceptionPage();
    			}
    			else
    			{
    				app.UseExceptionHandler("/Error");
    				// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    				app.UseHsts();
    			}
    
    			app.UseHttpsRedirection();
    			app.UseStaticFiles();
    
    			app.UseRouting();
    
    			app.UseAuthentication();
    			app.UseAuthorization();
    
    			app.UseEndpoints(endpoints =>
    			{
    				endpoints.MapRazorPages();
    				endpoints.MapControllers();
    			});
    		}
    	}
    } 


    Startup.cs Error Event Handling

    	services.Configure<OpenIdConnectOptions>(AzureADDefaults.OpenIdScheme, options =>
    	{
    		options.Events = new OpenIdConnectEvents
    		{
    			OnAuthenticationFailed = context =>
    			{
                               ...
    			},
    
    			OnRemoteFailure = context =>
    			{
                               ...
    			}
    		};
             });
    Friday, June 12, 2020 5:16 PM

All replies

  • User-474980206 posted

    you can add client code to cleanup the browser history. see

       https://developer.mozilla.org/en-US/docs/Web/API/History_API

    Friday, June 12, 2020 7:33 PM
  • User-2120644463 posted

    you can add client code to cleanup the browser history. see

       https://developer.mozilla.org/en-US/docs/Web/API/History_API



    The sounds like a potential option, although I imagine that would work better when the frontend is more JavaScript focused.  I was hoping to find a more seamless way of bypassing the issue when working with plain Razor Pages or MVC.  Plus there's the concern of knowing when to trigger the manual manipulation of the users browser history on top of indirect concerns of replicating a similar unexpected issue in regards to manipulating the users browsing history.

    Thanks

    Tuesday, June 16, 2020 2:12 PM