Summary: WSO2 IS 5.11 has been installed and configured with FIDO as a local authenticator for a service provider. As a user on an Apple device attempting to log into a service provider using the FIDO local authenticator, the user is immediately redirected to a failed login attempt page.
According to Safari Web Inspector attached to the user's device, the fido2-auth.jsp [1] generates the following error message:
User gesture is not detected. To use the WebAuthn API, call 'navigator.credentials.create' within user activated events.
Apple requires that WebAuthn API calls originate from a user gesture [2]. fido2-auth.jsp attempts to call the WebAuthn API through an onload [3] event which causes the aforementioned error message.
Questions: Would an appropriate workaround be to have a "retry" button on this page that explicitly calls the WebAuthn API through a user gesture and , upon onload failure, disable the automatic form submission in talkToDevice() [4] so the user can use the "retry" button? Has WSO2 identified another path for users using Apple devices to perform FIDO authentication?
References
[1] - https://github.com/wso2/identity-apps/blob/master/apps/authentication-portal/src/main/webapp/fido2-auth.jsp
[2] - https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/
[3] - https://github.com/wso2/identity-apps/blob/master/apps/authentication-portal/src/main/webapp/fido2-auth.jsp#L43
[4] - https://github.com/wso2/identity-apps/blob/master/apps/authentication-portal/src/main/webapp/fido2-auth.jsp#L182
This issue is caused by Safari requiring user actions to initiate the webauthn flow. Since other browsers don't mandate the same, we don't face this issue in any other browsers.
So, to address this issue, WSO2 Identity Server has added a proceed button to the authentication page for Safari users. So, Safari users can now click on this button to initiate the webauthn flow.
Related
I'm at the step where you link the Google account where the NEST devices are authorized in these instructions, I build up the URL with the project ID from the device access console and my newly created OAuth 2.0 Client ID then visit the resulting URL (https://nestservices.google.com/partnerconnections/etc....).
It shows my two NEST devices, I slide them on, click next and consistently get:
You can’t sign in because sent an invalid request. You
can try again later, or contact the developer about this issue.
along with Error 400: redirect_uri_mismatch
The instructions do mention:
you may get a warning screen that states Google hasn't verified this app. If so, to continue, click the Advanced option and then click Go to Project Name (unsafe).
But there is no "Advanced option" on this screen.
I've verified that the Smart Device Management API is enabled and that the Smart Device management scopes have been added to the project,
Any ideas?
I have a web-app built with the AWS Amplify framework. I rely on Cognito Hosted UI w/ identity federation for registration and login. In reviewing the registrations for my app, I noticed that it got 70+ registrations, but of these only 12 went on to create user profiles. I tested creating an account and signing in through each identity provider (Amazon, Google, Facebook) as well as through standard signup with an email and password. I never had any issues.
I started testing more heavily on mobile and eventually I started to encounter the an error. I plugged my mobile device into my laptop, navigated to chrome//:inspect and checked the network tab and JS console. Only when my chosen identity provider required an OTP code, I noted that I was getting invalid_request and invalid_grant errors on after I input the code and continued with sign-in, even though registration seemed to work (I say registration seemed to work because I received AWS credentials in the initial response and amplify-signin-with-hostedUI was set to true in localStorage. Also, when I open the AWS Console and go to Cognito, I can see that I've been added as a user in my User_Pool).
If I refresh the browser at this point, it seems a new request is sent off to /token, but it comes back with a 400 error with the invalid_grant message.
I kept poking around and eventually found something interesting. There are three tabs involved in the login process, and I think this is somehow messing things up. On mobile, when I try to register or login with the Cognito Hosted UI, I am first met with the Federated Identity Provider buttons and email/password page.
First I got to my website (Tab One). Then I click sign-up and the Hosted UI page pops up (Tab Two). I select one of the login methods (Amazon, Google, Facebook, or Email/Password). If the selected method requires no OTP, I'm golden. I'm redirected to my web app and the app works fine. If my selected method requires an OTP, a new tab opens (Tab 3) which asks for the token. At this point, I can see in Chrome devtools that an error occurs on this tab (Tab 3).
After plugging in the OTP code and clicking sign-in, I'm redirected, as expected, back to the my web-app, but this redirect occurs in the original tab (Tab One), however with a query string added to the URL (/?code=). If I click the view tabs button, I see that the Hosted UI tab (Tab Two) is still open and still has the Cognito Hosted UI buttons/username+password page open. Not sure if that's important.
Now on Tab One with my web app, I don't immediately see any errors in Chrome devtools. But I can see that my app is unable to load. If I wait, it just loads and loads forever. If I refresh the page, then at this point I see a new request to /token fire off in the Network Tab of Chrome DevTools and it comes back with the 400 error invalid_grant response.
Has anyone else encountered this issue or found a resolution?
Thanks in advance!
I'm attempting to use Postman to "Get User Access Token" with Microsoft Graph API; however, my org recently enabled multi-factor auth and this call is now failing, stating:
"error": "invalid_grant",
"error_description": "AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access...
The Microsoft documentation for MS Graph API using Postman is very well written, but it is missing clear instructions how to pass in this second factor to the request.
The error points to https://login.microsoftonline.com/error?code=50076, but this just gives the same info.
I have the MS authenticator app which gives me this key/second factor; however, I don't know how to add this into the body/headers. I'm trying to find the specific key name for passing in the additional security token (I've tried things like 'token,' 'pcToken,' 'key,' etc.)
.
I was in the same predicament so here is what I did to solve it:
Firstly, I got the information from:
https://github.com/microsoftgraph/microsoftgraph-postman-collections/issues/4
You will need to use the OAuth 2.0 authorisation in Postman. Using the same GET request, go to Authorization -> Change the type to 'OAuth 2.0' then click 'Get New Access Token'.
From there, you can input your own details:
(replace [TenantID] with your own)
Callback URL: The redirect URL you stated in your app authentication.
Auth URL:
https://login.microsoftonline.com/[TenantID]/oauth2/v2.0/authorize
Access Token URL: https://login.microsoftonline.com/[TenantID]/oauth2/v2.0/token
Client ID: You're application's ID.
Client Secret: You're Applications secret that you set under the 'Certificates & secrets' section.
Screenshot
Username Password Authentication is not supported for MFA because MFA requires interaction. But there is no interaction if you need to use Username Password Authentication to sign in.
See Username Password Authentication：
users who need to do MFA won't be able to sign-in (as there is no
interaction)
The answers above do not describe anything related to MFA by-passing via code.
MFA auth you need to use broker authentication where MS Authenticator app behaves as a broker.
If you integrate the proper libraries (ADAL, MSAL) your code will be able to interact with broker properly.
On Android and iOS, brokers enable:
Single Sign On (SSO). Your users won't need to sign-in to each
application
Device identification (by accessing the device
certificate which was created on the device when it was workplace
joined). We use Intune-managed devices for this purpose.
Application identification verification (is it really outlook which
calls me?). The way it works is when an application calls the broker,
it passes its redirect url, and the broker verifies it:
On iOS, the redirect URL is, for instance, ms-word://com.msft.com, the broker
parses and gets the appId (after the //) and verifies it's the same
as the appId of the calling app, which it knows (by the OS).
On Android the redirect URLs have the following form msauth://com.msft.word/.
To enable one of these features, the application developers need to set the UseBroker Boolean to true in the platform parameters. They also need to implement a delegate to react to the broker calling back the application as described in Platform parameters properties specific to brokers on Android and iOS.
Please refer to the MS docs for broker auth examples:
https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/leveraging-brokers-on-Android-and-iOS
https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-use-brokers-with-xamarin-apps
https://learn.microsoft.com/en-us/azure/active-directory/develop/brokered-auth
I am studying WSO2 API Manager. In the OAuth authorization code/implicit flow, after the user enter a valid credential in the login page. The user will be redirected to consent page like this.
When user click Approve, access token will be issued with all valid requested OAuth scopes. However in OAuth flow, application can request access to multiple scopes. Is it possible to configure/customize WSO2 API Manager consent page to present the user with the list of request scopes and allow user to choose which scope will be allowed (like Facebook) ? If it is possible please guide me to where I should look further.
Yes we do have identified this as valid requirement and created JIRA to fix this issue in upcoming identity server release. Once identity components release with this feature API Manager can use it and next API Manager release will have that. Once we have that feature you can do following changes in authentication endpoint app and get user consent for scopes.
/repository/deployment/server/webapps/ directory. You'll see the exploded directory authenticationendpoint. Then users can edit web.xml file in authenticationendpoint/WEB-INF directory and displayScopes parameter to true and save the file.
<context-param>
<param-name>displayScopes</param-name>
<param-value>true</param-value>
</context-param>
Once the change is done, you'll see an entry in the carbon log similar to Reloaded Context with name: /authenticationendpoint after a couple of seconds. The scopes will be displayed in the consent page afterwards.
Public JIRA to display scope description in oauth/oidc consent page
Thanks
sanjeewa
I am publishing a web application in WSO2 APP manager 1.0.0.After subscription, I am able to land on the login page of the application but once providing the credentials, blank page is seen.I would like to know if there are any configurations needed in the wso2 app manager for the server in which web app is running for invoking the web app properly.
When you say you were able to land on the 'login page' do you mean the login page of App Manager Login or the log in page of the Web App?
What are the errors/exceptions logged on the console?
If it is the App Manager log in page this could be related to incorrect service provider details recorded against the web application (Eg: incorrect Assertion Consumer URLs etc).
If you are referring to the Application's log in page, this could happen due to the App being secured with username/password.
When an App is secured, App Manager needs to send a JWT token as a HTTP header to the back-end Application once the user is authenticated.
In this case a few changes are required to be made in the App itself to support this.
The App should be modified to read the JWT token and identify the user and skip giving the login page.
The document [1] explains this in detail.
[1] https://docs.wso2.com/display/APPM100/Securing+Web+Applications+Using+JWT