1. Scott Wells Avatar Scott Wells
  2. Illuminated Cloud
  3. IlluminatedCloud
  4. Issues

Allow oAuth (optionally) in place of username/password login

Issue #159 resolved
Chris Peterson created an issue

Keeping up with password policies and API security tokens can be a pain! Why not let us configure a connection to an org via oAuth, and use the refresh token from that to generate sessions as needed?

This could also be helpful for organizations that opt-in to API whitelisting.

Comments (29)

  1. Scott Wells repo owner

    I think this is a great idea and something I've had rolling around in my head for a while as well. Let me get through the remainder of the deployment/retrieval enhancements and Lightning components support and I'll revisit this one.

  3. Peter Lin

    The Spring '17 caused one of my sandbox not being able to change my email in my user record. So I have no way (even I wanted to create a new sandbox, the new one will be a old Winter '17) to get a security token, so I have no way to connect to this sandbox using IC. I hope that I can use OAuth 2.0 soon in IC.

  4. Scott Wells repo owner

    Peter, right now OAuth isn't on my short list. I do plan to fix #298 where invalid passwords are causing a retry storm and subsequent lockout, but that doesn't seem to be your concern. I'm not sure I follow why you're not able to change your security token, though. Are you saying that the email address associated with your sandbox org user is not one to which you have access? Assuming so, is that not something you could ask an admin to fix? Not trying to punt on the original question about OAuth, but trying to see what option(s) might exist to allow you to get IC working with this org again until I do add OAuth support. Alternatively, could you ask for the org to be configured not to require security tokens for your account and/or source IP address(es)?

    Please let me know whether any of these are options for you. I'll be curious to know more about the situation...

  5. Peter Lin

    Hi Scott, I found a walk around. i.e. I created a new user to receive a token as I am the admin of the org.

    Background: When Admin A create a new sandbox, only Admin A's email on the user record will be the same as Production. Everyone else's email on their user record will be changed by changing @ to "=" and appending @example.com to the end of the email, e.g. john@apple.com will be changed as john=apple.com@example.com.

    The issue is this.

    When Salesforce upgraded my sandbox to Spring '17, a changing email link they sent was asking a verification code which have sent to john=apple.com@example.com. This is not the same way in Winter '17 and previous versions. For Winter '17 and previous versions, I only need to click the link from Salesforce. No verification code is asked. So I have no way to know the verification code sending to the non-existing email. So I have no way to receive the token.

    As I am the Admin, I have more options... :)

    2017-01-10_151155.png

  8. Scott Wells repo owner

    Yeah, I've been looking into exactly that. You don't get it automatically with the SFDX implementation, though that did force me to start incorporating OAuth notions such as access and refresh tokens into IC. However, for the OAuth being requested here, you do need to present the login screen to the user and capture the resulting tokens whereas in SFDX that happens via the CLI either due to a login or due to scratch org creation. Oddly the most "challenging" part here is the login screen because there's not a great cross-platform way to launch a native browser and capture the resulting OAuth info. I could do it using Java/Swing components, but I'd need to make sure that those simplified browser components can successfully render Salesforce's OAuth login screen. Anyway, at this point I'm mainly waiting for SFDX to gel a bit to see whether this will even be as interesting an enhancement at that point assuming I support SFDX config. My guess is that it will be for logging into sandboxes and prod orgs conveniently.

  10. Doug Ayers

    As a consultant where I need to log in to handful of different client orgs each day, often needing to spin up a handful of new projects each week to various sandboxes for different clients too, it would be an efficiency for me to enter the oauth username/password once and rest of the time IlluminatedCloud leveraged refresh tokens. I wouldn't have to go get the security tokens each time.

    Certainly not a mission critical feature request, but definitely keep in the "nice to have" wishlist.

    Thanks!

  11. Scott Wells repo owner

    Good to know. Still trying to understand how the existing SFDX progress relates to this. As it is I'm already supporting OAuth authentication for SFDX connections, though SFDX takes care of ensuring that the access token is always valid. However, it didn't in its initial incarnation so I do already have refresh token handling implemented but disabled. As noted above, the biggest challenge is providing a proper login screen from Java/Swing.

    Definitely still on my list, but somewhat waiting to see how SFDX affects this overall...

  12. Eric Alexander

    @RoseSilverSoftware - Not sure if it matters but the GIT integration in IntelliJ does present a popup for oAuth or something. Maybe the functionality is there but not well documented? At least when I set up the new laptop and went to set up git in IntelliJ I got the popup from GIT asking me to log in.

  13. Scott Wells repo owner

    Ah, interesting. I'll take a look and see if it's something I could reuse. If so, this would actually be pretty simple to implement on top of the changes I've already made for SFDX. Thanks for the lead, Eric!

  14. Eric Alexander

    Cool. Not sure if I even have the correct path or sequence of event correct. I just remember seeing the popup and having to log in. Sorry I cannot provide exact steps to reproduce at this time.

  15. Lennox McKenzie

    If this works it would be fantastic and very welcome news. I'm still in the market for an IDE with OAuth support for Salesforce. I gave Welkin Suite a try and that product does have an OAuth option, but I'm torn. I much prefer the integrated development experience with IntelliJ and Illuminated Cloud. Looking forward to the outcome here.

  16. Scott Wells repo owner

    One way or the other I do plan to support it. I just need to work through the details. Worst-case scenario I can just host my own form instead of trying to host the server's OAuth login form. It's not ideal, but the alternative is saving credentials with IC anyway. There are enough people who want this...myself included!...that it's more a matter of when rather than if. Right now finishing up SFDX support is ahead of this on my list (and is frankly a pre-req since that already brings storage for OAuth access and refresh tokens in IC's config), as is finishing up a few IC 2.0 things that are already in-flight. Then I'll circle back around and take a close look at this. I'll post an update here when I dive into this for real.

  18. Scott Wells repo owner

    FYI, I know how I'm going to support this now. I'm going to use the sfdx executable to facilitate the OAuth login as it already integrates well with the host system's native browser and stores/manages the OAuth access/refresh tokens properly.

  19. Peter Lin

    Hi Scott, Could you also keep the traditional username+password+token login as an option for non-DX org when you add support for OAuth login?

    Thank you! Peter

  20. Scott Wells repo owner

    Oh yeah. I couldn't remove that. It would break all existing users. In the end it'll support username/password+token, OAuth via SFDX CLI for traditional orgs, and OAuth via SFDX for scratch orgs.

  22. Patrick Watkins

    Hi Scott, Just to echo the comments on API Whitelisting (which is something that EVERY org will soon find that they should have turned on once they realize how exposed their orgs are without it), essentially a username and password login flow is completely blocked when that feature is enabled. The only way to whitelist is through a connected app: https://help.salesforce.com/articleView?id=security_control_client_access.htm&type=5

    Otherwise you have to give that user permission to "Use any API" (a permission that shows up when this feature is turned on). The bad thing about THAT is that it then goes a step further and for that user doesn't even enforce the connected app policies. So there's not a good happy middle ground. This essentially forces us to turn off the feature in dev sandboxes with no data, turn it on, but grant every developer a permission set to "Use Any API" on full and partial sandboxes and then of course just do neither in prod since you really don't have any reason to be connecting Illuminated Cloud to prod except in special circumstances where you just need to do a metadata search (which we are moving to using sfdx for instead anyway).

    This really becomes an issue for people trying to move to API whitelisting and the worst part is we have hardly any way to even realize what the impact will be before turning it on because the direct username password login flow used by tools like IC shows up with no identifying information anywhere in places like loginhistory (just says "other apex api").

  23. Scott Wells repo owner

    This is obviously a VERY old enhancement request, but I wanted to let watchers know that I'm actually implementing this as part of the work for #1184. As expected, OAuth support will be provided via the SFDX CLI, though it will be very tightly integrated into IC as if it were implemented as a first-class feature.

  26. Oleg Rikkers

    Does "IC2's support for SFDX development against non-scratch orgs" mean we can develop LWC against regular orgs as well? I saw in the video you are able to pull those, but wasn't sure if dev work is supported.

  27. Scott Wells repo owner

    Oleg, you can actually do that now even without these changes. You do need to have a package.json that pulls in the LWC dependencies, but you can snag one from an SFDX LWC project.

  28. Scott Wells repo owner

    A new test build has been attached to #1184 with pretty much full OAuth support. I hope to release this build officially this week, but there are some potential Salesforce CLI issues that I'd like to see through one way or the other first if possible. Instructions for how to use the test build are included in #1184.

  30. Log in to comment
Assignee
–
Type
enhancement
Priority
minor
Status
resolved
Component
Project Configuration
Version
2.0
Votes
9
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!