2

Apparently there are a lot of people having this problem, but none of the scenarios seem to be exactly what I'm experiencing. I'm using Azure AD B2C with HTTPS. I can consistently create the problem, but am at a loss to know how to fix it.

Recreating the problem:

  1. Make sure to be logged out.
  2. Go directly to a link in the site. This will bring up the login screen. After successful login, the user should be taken to the page in question.
  3. Hit the "Back" button. This brings up the error, and the user will be at https://domain/MicrosoftIdentity/Account/Error.

I've tried every combination/permutation of cookie policies I can think of, but to no avail.

If I can't solve the problem, perhaps someone could tell me how to redirect https://domain/MicrosoftIdentity/Account/Error to https://domain/MicrosoftIdentity/Account/SignOut, thereby simply forcing a loggout. I'd be satisfied with that.

Bradley Plett
  • 163
  • 1
  • 11
  • Technically not really a problem. What happens when you go back is you're actually 'post' ing again to the server with an authentication ticket, but the ticket is used and hence you get an error. You could implement a Post-Redirect-Get pattern to prevent this behavior. – Dennis VW Dec 15 '21 at 20:33
  • I understand what you mean, but my clients aren't impressed with the error! Please elaborate on how to "implement a Post-Redirect-Get pattern". – Bradley Plett Dec 15 '21 at 22:07
  • I added the answer for you. - On a side note, you might not have to implement or change anything if you explain to them that what they're doing is _never_ part of a normal user flow. Who signs into an app and then goes back immediately? – Dennis VW Dec 16 '21 at 09:52
  • Actually, the situation is not as bizarre as you might think. The client is sent a URL on their mobile device. They click the link, sign in, and see the document in question. They then hit the "Back" button thinking they will be returned to their messaging app but are instead presented the ugly error screen. – Bradley Plett Dec 16 '21 at 17:21
  • So, given the new information, what part of that flow is under your control, the messaging app, the file host, or neither? – Dennis VW Dec 16 '21 at 23:15
  • Only the web site. – Bradley Plett Dec 17 '21 at 09:25
  • I would honestly like to help you resolve this issue, but it's not clear to me what website you're talking about, or how any of what you said fits into that. If you can more clearly describe the flow in your question, that would really help. – Dennis VW Dec 17 '21 at 14:33

1 Answers1

0

What this really is:

From an authentication/application's perspective this behavior is correct. Let me clarify. I bet the following is something almost every internet user has experienced:

You submit a form, click on the back button and this alert pops up, asking you to 'resubmit the form'?

When you clicked back in the browser it simply executes the exact same request that you did earlier. Not a big deal in HTTP-GET requests, but kind of a pita in POST-requests because it can potentially cause duplicate data or worse. Or in this case, you run into security measures preventing the (ab)use of one-time tickets.

Although the behavior is correct, I understand that your client's perception is, that the app must simply be broken..

The solution, or preventive measure:

To be clear, I haven't actually tried this and this is more of a 'could-possibly-work' answer in the case of AzureAD B2C.

Nevertheless, I think you might be able to circumvent this perceived problem through:

Implementing a POST-redirect-GET pattern inside your application so that you point the redirect URI of the B2C tenant to an endpoint inside your application and when the request comes in, simply redirect the request to a GET method.

Hopefully this helps, but in case you want a more definitive answer try searching Google for the pattern or maybe someone else here knows about a working solution and wants to contribute to this post in the comment section or provide an answer. Either way, good luck!

Dennis VW
  • 2,977
  • 1
  • 15
  • 36