CODEWITHSUNDEEP
.netwinformsoauth-2.0webbrowser-controlconstantcontact
raleigh5
raleigh5

Reputation: 1

.NET WebBrowser control does not receive OAuth2 Redirect URL

This is a .Net WinForms application. It uses a webbrowser control in performing an OAuth2 process. In this scenario, once a User grants agreement for our app to access their Account( on Constant Contact ), the redirect URL will contain an authorization code which we can use to acquire an access token. But the redirect navigation never takes place. So we do not receive the URL containing the authorization code. The webbrowser does not navigate from the "Allow/Don't Allow" page. When looking at this in Fiddler. When the User clicks "Allow", the Response header does include the code. But Fiddler also shows the session being aborted when SendingResponse. Which, i presume, is why the only further feedback we get from our webbrowser control is "_javascript:void(0)".

This the Response Header( from Fiddler ): CODE response

HTTP/1.1 302 Found
Date: Sat, 14 Dec 2019 17:05:41 GMT
Content-Security-Policy: referrer origin
X-Frame-Options: SAMEORIGIN
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
**Location: https://www.vinnow.com?code=wL9Iu2J6xpnmT7joclc4lgb4dtVF__12345**
Content-Length: 0

These are the associated Session Properties:

SESSION STATE: Aborted. 
Request Entity Size: 129 bytes. 
Response Entity Size: 0 bytes.

== FLAGS ==================
BitFlags: [IsHTTPS, ClientPipeReused, ServerPipeReused] 0x19
**X-ABORTED-WHEN: SendingResponse**
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 58424
X-EGRESSPORT: 58425
X-HOSTIP: 208.75.122.17
X-PROCESSINFO: testctct.vshost:22196
X-RESPONSEBODYTRANSFERLENGTH: 0
X-SERVERSOCKET: REUSE ServerPipe#457

I would like to know if there is a way i can determine which side aborted the session( client / server)? And why it is getting aborted?

I've tried this process using numerous configurations for the webbrowser. Always the same result. Even tested using "webbrowser2" so i can trap any navigation errors. There were none. Same result. If this process is executed via regular browser, or via Postman, it completes successfully.

There is an alternate OAuth2 process which, instead of returning an authorization code, returns an access token. But that access token is short lived and has no refresh token. That particular process completes successfully using same webbrowser and same procedure.....User Login.....User Allows...redirect to provided URL.

Upvotes: 0

Views: 601

Answers (1)

Jeff Tasi
Jeff Tasi

Reputation: 1

The issue occurs because the WebBrowser control uses an outdated Internet Explorer engine, which may not handle OAuth2 redirects properly. I recommend using WebView2, which is based on the modern Edge engine and fully supports OAuth2 authentication.

I am the author of Bee.OAuth2.WinForms, which simplifies OAuth2 login and correctly handles the redirect URL. This library provides an alternative solution for integrating OAuth2 authentication in WinForms more reliably.

https://www.nuget.org/packages/Bee.OAuth2.WinForms/

var options = new TGoogleOAuthOptions()
{
    ClientId = "your-client-id",
    ClientSecret = "your-client-secret",
    RedirectUri = "http://localhost:5000/callback",
    UsePKCE = true
};
var client = new TOAuthClient(options);

// Open the login interface, let the user sign in, and retrieve user information after authentication.
var result = await client.Login();  
var userinfo = $"UserID : {result.UserInfo.UserId}\r\n" +
               $"UserName : {result.UserInfo.UserName}\r\n" +
               $"Email : {result.UserInfo.Email}\r\n" +
               $"RawJson : \r\n{result.UserInfo.RawJson}";

Upvotes: 0

Related Questions