I was wondering if it was possible to login to different salesforce environments (Sandboxes, scratch orgs, production env, etc) using either Apex/LWC/Aura (or anything that I can make a quick action to). For example, I have a list of credential records, with the username and password, and I would like to have a login button that creates a separate tab that can automatically redirect to that specific instance and log in.
Currently, if a user wants to login to a particular instance, they have to either go to test.salesforce.com or login.salesforce.com (depending on if it's a sandbox or production) manually, then copy the password and username in. The ideal situation is to have a login button that can do this automatically from the record page where the username and password is located.
I think previously this could have been accomplished through the URL, but salesforce has recently patched this out due to security concerns. Is there another good way to do this?
It sounds like you're trying to solve two specific challenges:
Your users need to be able to manage very high volume of credentials.
You need authentication to survive password resets.
The clear solution, in my mind, is to use the OAuth Web Server flow to execute initial authentication and then store the refresh token that results from this flow. This token survives password resets, and may be used more or less indefinitely to create new access tokens - which users can then use to log in via a frontdoor link.
There's an out-of-the-box tool that does this already: the Salesforce CLI. You can authenticate orgs to its toolchain, name them, and subsequently access them with a single command (sfdx force:org:open). Users that prefer a GUI can access the exact same functions in Visual Studio Code.
If you're hellbent on doing custom development to handle this use case, you can, but you need to be very careful of the security implications. As one example, you could implement an LWC + Apex solution that executed the relevant OAuth flows against orgs and stored the resulting data in an sObject, then allowing users to click a button to generate a new access token and do a one-click login.
But... if you do this, you're storing highly sensitive credentials in an sObject, which can be accessed by your system administrators and potentially other users who have relevant permissions. That data could be exfiltrated from your Salesforce instance by an attacker and misused. There's all kinds of risks involved in storing that kind of credential, especially if any of them unlock orgs that contain PII or customer data.
One of the two best answers for that (the other one being 'pure Apex' and relatively more complex) is using Flow.
"You can use a login flow to customize the login experience and integrate business processes with Salesforce authentication. Common use cases include collecting and updating user data at login, configuring multi-factor authentication, or integrating third-party strong authentication methods.enter image description here"
"You can use login flows to interact with external third-party authentication providers by using an API.
For example, Yubico offers strong authentication using a physical security key called a YubiKey. Yubico also provides an example Apex library and login flow on GitHub. The library supplies Apex classes for validating YubiKey one-time passwords (OTPs). The classes allow Salesforce users to use a YubiKey as a second authentication factor at login. For more information, see yubikey-salesforce-client.
You can also implement a third-party SMS or voice delivery service, like Twilio or TeleSign, to implement an SMS-based multi-factor authentication and identity verification flow. For more information, see Deploy Third-Party SMS-Based Multi-Factor Authentication."
learn more here: enter link description here
Related
I have a scenerio not sure which grant type should I be using.
We have a current web application. User will require to login to the our existing web application. Once logged in, user need to click on a button to register himself or log in through identity server and send back a registered/logged-in userId (I think that is the openId). Once received that id, i can link this id to our existing user login table.
That depends both on the technology you're using to build your web app and the user experience you want to offer.
When you have no need for refresh tokens or you have a JavaScript application, the implicit flow is recommended. In that case all tokens are transmitted through the browser channel.
The hybrid flow is recommended for server-side web applications and native desktop/mobile apps and will also support things like refresh tokens so as to keep your users logged in across browser sessions. This flow uses the browser channel for the identity token and the back channel for access / refresh tokens.
These two grant types cover a lot of the more common scenarios for web apps but there are more to choose from or to take into account. I suggest you read up on that in the IdentityServer4 docs.
Everything I'm reading shows that in order for an application to use onedrive, it has to do the oauth2 thing to get credentials. But what if you're a batch process and don't have a web interface for your users.
Google's API has a special type of account called a service account where once you set it up, you can control access to everything from that one account, no need to interact with users. Does such a thing exist for onedrive?
App-only authentication doesn't require the user be prompted for credentials but it also isn't supported in 100% of scenarios. For example, the APIs need a user principle for creating special folders and resolving a user's personal site. Also, it is only supported for OneDrive for Business, not Consumer. Consumer always requires the user be prompted for initial authentication.
Another option would be to spin up a web service of some sort that handles initial user authentication, ie. a sign up page. With that, you can retrieve a refresh token for offline authentication and store it for the user. Every authentication from then on can be done using the refresh tokens, which doesn't require a user prompt.
I finally found this. It's the same basic idea as google's service account, but I think it's harder to use. But at least the concept is supported.
http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
In section 1.1 of RFC 6749, there are four roles: resource owner, resource server, client, and authorization server.
Does OAuth become redundant or unnecessary if the client and the resource owner are the same entity?
For example, I have a closed API and a front-facing web server. (The front-facing web server would be both the client and the resource owner.) I am trying to decide whether to switch to OAuth 2 authentication instead of using the current username/password authentication method. Is there any added security for moving to OAuth 2 if the API remains closed to third-party applications? (That is, no third-parties will ever have access to the API.)
Thanks!
In the case where the Resource Owner and Client/Resource Server roles coincide OAuth 2.0 may become less relevant from a security point of view, since one of the primary objectives of OAuth not to expose primary credentials of the user to the client becomes moot. That is also the reason why the so-called Resource Owner Password Credentials grant is considered to be a legacy/deprecated flow.
However, it may still make sense to follow the OAuth 2.0 pattern for a number of reasons:
the ability to leverage a standardized protocol through stock libraries and
frameworks without relying on custom code
the fact that in your case the Resource Server is still made strictly OAuth 2.0 compliant, dealing with Clients presenting access tokens, irrespective of what the Client/Resource Owner relationship/implementation is; this would make it easier to allow for 3rd-party client access in a future scenario
the fact that you concentrate verification of user credentials on a single path between Client and Authorization Server so each of your Resource Servers don't need to be bothered by checking user credentials individually, possibly dealing with different authentication mechanisms
and perhaps most importantly, also security-wise: once the user has authenticated through the Client using his primary credentials, the Authorization Server can issue a refresh token as well as an access token; the Client can store and use the refresh token to a new access token when the old one expires; this frees the Client from storing the primary user credentials if it wants to keep accessing the API for a long period of time without requiring explicit user interaction and authentication and makes the resulting system less vulnerable for leakage/loss of user credentials since the user credentials (password) are not stored in the Clients
If you have the following issue then you should use OAuth;
Let's say you a Gmail like web mail provider. Some of your users are using a third party app which logs in into your user's account and auto replies certain emails for you. Or you are Facebook like social network web site where some of your users use a third party app which analyzes your friend networks and prints a 2D graph for you. In this case your users are giving away their usernames and passwords. How would they prevent a certain third party app accessing their account after they gave away their username and password? Simply by changing their password. Now you have another problem; other third party apps won't be able to access the user's account. Then the user have to re-give away his password to other apps he trusts. Now this is problem too because it is not user friendly. OAuth is simply a temporary password that your user gives away to a third party app developer. He can revoke it whenever he wants without changing his own password.
Other than that OAuth is unnecessary. Just use a session cookie if you are not going to have third party app developers. It is a random string stored in user side. And on the server side will have whatever you want. Just look how PHP sessions are used and stored on server side. You can define their lifespan and refresh time automatically from php.ini.
I'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.
I am exploring the possibilities of a banking mobile HTML5 application. It will be contacting with the main server via RESTful API. Very often I hear that people are using OAuth in their mobile apps to access APIs. For example, SpringSource's html5expense demo app.
So I don't fully understand why bother? Couldn't the user just login in a standard way, receive a cookie with session id (or in case of Play framework, session data), that will be used to identify user when the app makes requests to REST?
Oauth is usually a lot more secure than most BASIC AUTH, or "logging in in a standard way" approaches (and OAuth is becoming more and more of a standard).
When you login, through most "standard" ways, the user enters his username & password, into the application, and username/password are then often either stored locally, or transferred to the application, to then potentially be relayed to a "main server" that for example provides the API. So the user will have to enter his very secret login information (e.g. for banking?), into a client, app or system he doesn't know or trust...
With OAuth, the user is directed to a login page of the owner of that API .. e.g. his bank for example, where he logs into the secure login page that he knows and is asked for his consent that the application "xyz" would like to access his data.... The application that has requested that access, is then given a token with which it can access the API without needing to know the username and password. That way the username/password is only entered once, at a location the user trusts.
Furthermore, the user could later log into and admit page .. (the bank app? or and admin frontend), and delete the given access right to the API, and so stop an application accessing his information, without having to change his password.
Beyond the effect of being actually safe, using something like OAuth, for a banking app also makes sense as it will give people more confidence if modern security techniques are applied. It makes it also feel safer.
If you are not going to publish your API to third party developers; there really is no reason to bother with OAuth.
The biggest reason OAuth exists is to enable integrations with your API without your users having to give out their username and password to a third party. Other reasons is that it makes it possible to put a time frame on third party access to resources, or to scope access.