1

I want to be able to login directly from my .net application's login (without having to use the user's security token). And I was wondering if it was possible to send my username and password to the salesforce OAuth endpoints via Ajax and then retreive the access token and other values without getting redirected to the salesforce page. And if it were possible how would I implement it? Since I'm a complete beginner when it comes to this so any help would be appreciated. And I'm not sure about this but wouldn't sending the username and password be a security risk? Or is there a way to protect these informations. And if someone wanted to clarify this a bit it would be great since I'm still looking around these solutions.

  • What is your use case? Are you trying to implement a SSO or you are trying to invoke APIs in Salesforce? – Jayant Das Feb 17 at 18:15
  • @JayantDas Well you could say both, since my application is based on only salesforce data. So for a specific user I need to get all his data to exploit it for the app. – dotname Feb 17 at 21:36
0

Using OAuth, you will need to redirect to Salesforce. Salesforce employs a number of login security features depending on the user's permissions and customization. For example, you can use the Lightning Login app, an SMS single-use code, an email single-use code, etc; if their browser is already authenticated, no code will be required and they may even log in automatically. The security token is only required if you use the SOAP login() call. Your app doesn't need to open a new window; you can just use a WebView (or similar) to perform the login action if you prefer to keep everything in the same window. However, the downside is that the user will likely need to use whatever 2FA is configured (e.g. one-time code).

0

Have you looked at Understanding the Username-Password OAuth Authentication Flow?

Per the warning on the page:

This OAuth authentication flow passes the user’s credentials back and forth. Use this authentication flow only when necessary. No refresh token is issued.

You cannot get a refresh token this way, though, so it can only be used to get a temporarily usable token and you need to submit user/pass each time you want that token (as far as I can tell from the docs).

Why is it that you want to avoid the Salesforce oAuth screen? FWIW the oAuth flow has become a standard for a reason.

You can also Google around for methods that enable opening the auth screen in a pop-up and sending the code back to the main window (all in the browser via JavaScript), so you don't have to navigate away.

  • I actually have, but as you said that flow is not advised so I'm looking for a way to implement what I said in a secure way and that flow isn't even an option for me since, like I said I don't want the user to have to input his security token, only his password and in the that flow you need both. It was requested I implement it this way and I think it's because in order to use the app you must be logged in so having the main page just be a button to get a pop up of the sf login isn't the best. Whether it s a redirect or pop up the issue is the same that's why I asked about ajax – dotname Feb 17 at 19:23
  • I think the terminology is misleading you: consumer key and consumer secret aren't the end user's key/secret. When you set up a connected app you get those two things. The only thing required from the user is their password and username. The way you'd implement this, then, means that they're sending their username and password to your server, your server makes a call to this endpoint with the payload described in step one of the link above. At that point it gets a token back that you use for subsequent API calls. – Tim Feb 19 at 2:10
  • What isn't clear to me is how permissions grants are done here since you aren't redirecting to Salesforce and they can't see the permissions you're requesting. It's easy to test this, though. 1. Setup a connected app 2. Make a request using the instructions above. 3. see what response you get back – Tim Feb 19 at 2:12
0

Storing passwords in an application is always risky from security perspective .The security token is a security feature which expires everytime password changes .You can learn about some of the security measures salesforce recommends here.

The other option that you could use is an oauth JWT based flow .

With this approach you will create a connected app for your application and register a certificate .You will get clientId and also the certificate private key.

Securely store the private key and the client Id in a secure DB and you can use only the username to generate a JWT based token based on the client Id and the certificate private key .

This way you don't have to ask for the password or even a security based token .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.