urwnd (urwnd) asked a question.
Hi all,
We've encountered a problem where although other main browsers work perfectly, Okta oAuth authentication doesn't complete when using MS Edge (v86.0.622.63). By "doesn't complete" I mean where there are a number of redirects back and forth and the final redirect doesn't happen, so Edge just sits there, waiting - eventually the client app times out. I can't find any information on this issue apart from coming across a discussion on a different site where someone said that when they disabled PKCE, Okta Authentication in Edge worked as expected.
I did find that installing the Okta plug-in for MS Edge resolved the problem (didn't disable PKCE or change any settings there), but I'd like to know if there is an official standpoint on this, either from Microsoft or from Okta. The latest documentation from the Okta site says that the latest version of MS Edge is supported, but is that with or without the Okta plug-in? Should Okta single sign-on work in Edge without the plug-in?
Thanks for any of your thoughts, comments, or redirects.
[Update 02 December 2020]
We've discovered, using the developer tools in MS Edge that at the point that the MS Edge browser comes to the forefront and opens a new tab which is directed to the okta authentication URL, the console shows the error message:
Not allowed to launch '<<Custom URI>>://authorize?code=5NcOJIJ6wft_lKTf4ig4UJ5Tw1AGFPXMhTUNTm2JcOM&state=2lNI1XN8rY3-Hrvytv9TH5jD5CxG52umvhNZU4eRbh8' because a user gesture is required.
However, after re-enabling the Okta browser plugin this error doesn't appear. The tab quickly opens and closes after which point the VFM application successfully logs in as per normal/expectations.
Hi Edward,
Does this happen with all applications, or just certain ones? If just certain ones, what sign-in method are they using?
Thanks!
Tim
Okta, Inc.
Hi Tim, thanks for your response.
Our main application is Veeva Vault which is web-based, so all users do what they need to within a browser on the web. However, we have a client application called Vault File Manager which enables users to download and upload files from the Veeva Vault web application.
Users are able to sign into Vault using Okta/saml, and they are able to sign into Vault File Manager (VFM) which uses the following technologies:
Sign On Method: OAuth 2.0/OpenID Connect
Application type: Native
Grant Types: Authorization Code, Refresh Code
Client Authentication: PKCE
The problem occurs when the user is:
Using MS Edge;
Not signed into VFM but need to be.
When the user wants to download a file, they select an option in the Vault (in the browser) which fires up VFM on the client machine. VFM detects the user and prompts the them that they are going to be logged in using their Identity Provider. MS Edge is then opened and in a new tab and the Okta sign on takes place. VFM should eventually get logged in, but it doesn't, it times out waiting for a response. This doesn't happen with Firefox, Internet Explorer, or Chrome - in these browsers, the sign on works successfully.
Detailed Reproduction Steps:
- User logs in to Vault web app using Okta (browser based, using Edge).
- User tries to login to our client app (VFM) using the same Okta user. (VFM is a windows exe).
- Our VFM app makes a request to the '/authorize' endpoint.
- New tab opens in default browser (the default browser in this case is MS Edge).
- The new browser tab doesn't show a login screen since Okta user has already signed in to Okta (browser URL bar just shows the /authorize request) - this is all fine and as expected. From this point:
The expected result:
- Okta '/authorize' endpoint returns an access token.
The actual result:
- No response from the '/authorize' endpoint (not even an error response). The result is that VFM is not logged in (it times out after 2 minutes).
Hacky workaround:
- User logs in to Vault web app using Okta
- In a different browser tab, user logs out of Okta before logging into our VFM app with the Okta user (this of course defeats the purpose of single sign-on).
- User tries to login to VFM using the same Okta user.
- VFM makes a request to the '/authorize' endpoint.
- New tab opens in default browser (in this case Edge)
- Login screen is displayed in browser since Okta user is signed out.
- User enters credentials
- Access token is returned
- VFM is logged in successfully.
In this (hacky) scenario the VFM application successfully elicits a response. The normal single sign-on process works in other browsers, but not in MS Edge, so Edge is the odd one out here. Installing the Okta plug-in resolves the problem, but my query is: Is this a recognised workaround to a recognised problem?
Thanks for all your help!
Ed.
MS Edge Version 86.0.622.63 (Official build) (64-bit)
[Update 02 December 2020]
We've discovered, using the developer tools in MS Edge that at the point that the MS Edge browser comes to the forefront and opens a new tab which is directed to the okta authentication URL, the console shows the error message:
Not allowed to launch '<<Custom URI>>://authorize?code=5NcOJIJ6wft_lKTf4ig4UJ5Tw1AGFPXMhTUNTm2JcOM&state=2lNI1XN8rY3-Hrvytv9TH5jD5CxG52umvhNZU4eRbh8' because a user gesture is required.
However, after re-enabling the Okta browser plugin this error doesn't appear. The tab quickly opens and closes after which point the VFM application successfully logs in as per normal/expectations.