Our application uses OKTA. We have to login to the OKTA portal, which sends a code to our mobile device (via SMS or the OKTA app). This code is then entered into a prompt. If the code is valid, we are then able to go to our test application.
Does Loadrunner support the scripting and handling of applications that use 2-factor authentication as part of their login protocol? If so, can anyone point me to a guide/documentation that explains how this is handled?
Thank you!
Related
I'm working on a project that's trying to include microsoft sign in, in order to use information about the person that signed in.
I'm doing this as a node js app that's run from my local machine, and there is no webpage / web server involved.
Mainly wondering if it's possible to sign in with a microsoft account without having to use a browser, or getting a URL link to sign in with, and then a way for me to get the access token without needing a redirect link back to a page.
It sounds like device code flow might meet your requirements.
Documentation for device code flow: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
MSAL Node sample showing device code flow: https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples/standalone-samples
There is also username/password flow, but that is not recommended, and MSAL Node does not support it yet. https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
I just finished integrating DocuSign API into my C# MVC application. My MVC app is NOT .net core. So far I worked with OAuth Token Generator from the developer portal of DocuSign and hard coding the returned token.
Now I need to implement the oAuth token generation on the fly and
I need to do the Authorization Code Grant. But not sure how to implement it with C#. When I make a request to
https://account-d.docusign.com/oauth/auth?XXXXXX
from MVC app I am getting a cross domain error. Please advise how to proceed?
Once again I am using a regular MVC app and NOT Core. In the sample app is in Core and
that doesn't help me.
Any help is greatly appreciated.
thanks
Are you using latest Chrome? its default mode would have strict cookies and not allow an app launched from localhost to store cookies in other domains.
Another option is that you're using an iframe, that is not allowed for auth either.
I would suggest you install the VS Extension and add DocuSign to your app as a way of a shortcut.
Otherwise, may need to debug the issue, try a different browser, host your code somewhere or change the way you do auth.
Let's imagine the following:
I've developed a mobile app using Xamarin (iOS/Android compatible)
I want it to support OAuth2 + OpenID connect's authorization code flow with PKCE, so that the user's credentials are never stored on the device, but rather an access token is. The token grants access to an API used to make the whole mobile app function, meaning the mobile app is simply a front-end interface/UI.
Is my mobile app considered the "client application", or the "Resource owner"?
The third step makes it so hard for me to grasp this. If it's considered client application, how will following through the whole code flow, protect us from anything, as most of the things will be visible (Mobile apps are public clients, there is no back-channel)
If it's considered resource owner, then does that mean I'd have to whip out an entire dedicated back-end, separate from my API, separate from my Authorization Server, and just specific for the mobile app (it will be the "Client application")?
If someone could shine some light on this, please let me know. The title is not very correct, if it can be edited to better fit this question, I'd be very thankful.
Your mobile app is the client application - with a trust entry configured in the Authorization Server. PKCE works by the mobile app generating a runtime secret used in 2 messages:
The login redirect
An authorization code grant message
See steps 4, 7 and 8 from my article to understand PKCE messages.
Mobile OAuth involves integrating AppAuth libraries which is not easy, though you'll have the best security and usability once complete.
I have a sample Android app and article that you can easily run.
The behaviour on iOS is similar.
I have an OpenID Connect provider built with IdentityServer4 and ASP.NET Identity, running on let's say: login.example.com.
I have a SPA application running on let's say spa.example.com, that already uses my OpenID Connect provider to authenticate users through login.example.com and authorize them to access the SPA.
I have a mobile app (native on both platforms) that is using a custom authentication system at the moment.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
So I started by looking on the OpenID connect website and also re-reading the RFC6749, after a few google searches I realized that was a common problem and I found RFC8252 (OAuth2 for Native clients), also Client Dynamic Registration (RFC7591) and PKCE (RFC7636).
I scratched my head about the fact that it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised.
I disscussed the topic with some co-workers and we came out with the following set-up:
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Use an AuthenticationCode flow for both clients and enforce them to use PKCE.
Use a redirect_uri on the app associated domain say: https://app.example.com/openid
Make the user always consent to log-in into the application after log-in, because neither iOS or Android would bring back the application by doing an automatic redirect, it has to be the user who manually clicks the universal/app link every time.
I used AppAuth library on both apps and everything is working just fine right now on test, but I'm wondering:
Do you think this is a secure way to prevent that anyone with the right skills could impersonate my apps or by any other means get unauthorized access to my APIs? What is the current best practice on achieving this?
Is there any way to avoid having the user to always "consent" (having them to actually tap the universal/app link).
I also noted that Facebook uses their application as a kind of authorization server itself, so when I tap "sing-in with facebook" on an application I get to a facebook page that asks me if I would like to" launch the application to perform log-in". I would like to know how can I achieve something like this, to allow my users login to the SPA on a phone by using my application if installed, as facebook does with theirs.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
This is what OAuth 2.0 and OpenID Connect provides you. The ability to use single user identity among different services. So this is the correct approach .!
it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised
Correct. From OAuth 2.0 specification perspective, these are called public clients. They are not recommended to have client secrets associated to them. Instead, authorization code, application ID and Redirect URL is used to validate token request in identity provider. This makes authorization code a valuable secret.!
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Not a mobile expert. But yes, custom URL domains are the way to handle redirect for OAuth and OpenID Connect.
Also usage of PKCE is the correct approach. Hence redirect occur in the browser (user agent) there can be malicious parties which can obtain the authorization code. PKCE avoid this by introducing a secret that will not get exposed to user agent (browser). Secret is only used in token request (direct HTTP communication) thus is secure.
Q1
Using authorization code flow with PKCE is a standard best practice recommended by OAuth specifications. This is valid for OpenID Connect as well (hence it's built on OAuth 2.0)
One thing to note is that, if you believe PKCE secret can be exploited, then it literally means device is compromised. Think about extracting secret from OS memory. that means system is compromised (virus/ keylogger or what ever we call them). In such case end user and your application has more things to be worried about.
Also, I believe this is for a business application. If that's the case your clients will definitely have security best practice guide for their devices. For example installation of virus guards and restrictions of application installation. To prevent attacks mentioned above, we will have to rely on such security establishments. OAuth 2.0 alone is not secure .! Thats's why there are best practice guides(RFC68129) and policies.
Q2
Not clear on this. Consent page is presented from Identity Provider. So it will be a configuration of that system.
Q3
Well, Identity Provider can maintain a SSO session in the browser. Login page is present on that browser. So most of the time, if app uses the same browser, users should be able to use SPA without a login.
The threat here comes from someone actually installing a malicious app on their device that could indeed impersonate your app. PKCE prevents another app from intercepting legitimate sign in requests initiated from your app so the standard approach is about as safe as you can make it. Forcing the user to sign in/consent every time should help a bit to make them take note of what is going on.
From a UX PoV I think it makes a lot of sense to minimize the occasions when the browser-based sign in flow is used. I'd leverage the security features of the platform (e.g. secure enclave on iOS) and keep a refresh token in there once the user has signed in interactively and then they can sign in using their PIN, finger print or face etc.
I'm developing an application with Grails.
Im trying to implement an SSO-functionality. But I can't authenticate the users via windows session, because some of them has another windows passwort as the domain password.
(I retrieve the users via LDAP) So, how can I authenticate them?
Scenario should be following:
User goes to the Grails-Site
Popup appears where the users has to fill in with his credentials
After that, he has never to authenticate again...
Does anyone of you has some experience with it?
I think if you need SSO for many grails applications a good choice is to add saml support to your grails applications using this plugin and then build an IdP (there are many in many languages) and connect the IdP to your ldap.
SAML is standard and is the future.
If you need more info about saml check the saml entry at wikipedia. There you can find links to documentation and software.