Strange behavior on MAUI WebAuthenticator for android

[noorez]

Description

I am trying to use the WebAuthenticator on an Android platform to authenticate via OAuth authorization code flow with SAML/SSO.

1. we initiate to the authorize endpoint like: the /oauth2/authorizePoint
2. redirect to SAML/SSO provider to authenticate
3. SAML Assertion returns back to app to /oauth2/authorizePoint
4. /oauth2/authorize has a redirect back to the application scheme myapp://callback

the app appears to receive the response via the custom scheme, however, while having the remote chrome debugger attached, I can see the chrome tab webview strangely attempt to 'repeat' the authentication from start. --> call /oauth2/authorize --> notice we are already authenticated --> call back to app myapp://callback.

We are definitely not invoking the authentication twice.

The double callback is causing an error since one of them has already tried to complete the PKCE workflow and the second attempt fails as the code has already been redeemed.

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

8.0.21 SR4.1

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

No

Relevant log output

No response

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• Issue with Essentials.WebAuthenticator and multiple activities (#22017), similarity score: 0.71

Closed similar issues:

• WebAuthenticator crash with some browsers (#13302), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[dotnet-policy-service[bot]]

Hi @noorez. We have added the "s/needs-repro" label to this issue, which indicates that we require steps and sample code to reproduce the issue before we can take further action. Please try to create a minimal sample project/solution or code samples which reproduce the issue, ideally as a GitHub repo that we can clone. See more details about creating repros here: https://github.com/dotnet/maui/blob/main/.github/repro.md

This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[dotnet-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback to reproduce the issue but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

[noorez]

Updates:

We attempted instead of relying on the intent filters to setup a local host webserver on the application to listen for the callback from oauth login process. Despite not having the ability to switch back to the application after the authentication is completed (needed to close the custom tabs window with the X button), the local host server correctly received and handled the authorization_code without issue.

On the other hand, when we redirect to the custom protocol intent myapp://callback instead of http://127.0.0.1/callback the custom tab begins exhibiting the strange behavior of attempting to restart the authentication flow from the beginning (by going to the /SignIn page again..) even though no call from the application initiated a second call to that URL.