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.
Related
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
I am very new to the concepts of SSO and Keycloak. I am trying to read the official documentation of Keycloak. In the "Supported Protocols" part (https://www.keycloak.org/docs/latest/securing_apps/index.html), the documentation talks about the two use cases of using OIDC like this:
"The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request."
What I do not understand is this: In the first paragraph it talks about an application making a request and in the second one it talks about a client. But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Thank you.
But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Yes exactly it. The reason for the differentiation is because there could be many applications more than just this one client. And the client, that the user is authed against may want to access all those other applications' data.
For example take the google ecosystem. Does google email have access to drive, and photos, etc... While it could out the box, it doesn't. You need to explicitly allow email "offline access" to those other applications, even though they are all part of the same platform.
Keycloak understands this and provides that terminology. But it is a bit confusing because this isn't the best way to think about it. Instead a better explanation is that there is just the user and service clients. The service clients all talk to each other and ask for a user's data. While a user may want their data by going straight to one application, other applications may want that user's data too.
Assuming you want to actually allow one service to ask for user data from another service, you want to be using something that supports authorization as a service and not just authentication. There are some examples of this, such as PolicyServer and Authress.
A little baffled by the Adobe Analytics Oauth integration. I have done many OAuth implementations with other providers in the past, and used the older versions of the Adobe Analytics API.
My company provides services to clients who use Adobe Analytics, we do not have an account of our own. In the past we just needed to be provided the user and shared secret and we were good to go. Now it seems that we need to have an integration created by an admin in the client company, and have them send us the client_id and client_secret securely. This does not grant us access instead it is the first step in requesting access. Once we have this information we can do an OAuth request, using a valid adobe id with proper access and then we will receive the token we need to request data.
With other OAuth integrations I have seen, the client_id and client_secret are not tied specifically to a given account, but rather to the application. In this case it seems we will need to have a new set of client_id and client_secret created for one application, for each account we need access to.
To clarify the use case.
I work for Define Media Group an Audience Development Consulting Firm
specializing in SEO.
Many of our clients are news organizations, for our purposes here,
lets say our client is the fictitious Newscor. Newscor uses Adobe
Analytics and has come to us to provide insight into how they can
improve their SEO performance.
As part of our analysis of Newscor we will need to look at the
Analytics data for all of the requests to their site from Googlebot.
We will use the Adobe Analytics Reporting API to retrieve this data
and perform our analysis.
In the case of a second fictitious company, Newscom, who instead used
Google Analytics, I built an application, I logged in with a Define
Media Group account to the Google API Console and generated a service
account for my application. This provided the client id and secret
needed for completing the OAuth process. Now I just need to have our
SEO contact at Newscom, access our page and complete the OAuth process
with his credentials and I will be able to complete the analysis on
his behalf. Very straight forward.
In the case of Newscor, I am stuck. I have asked my SEO contact at
Newscor to have a service account created and provide the client id
and secret. Instead he provided me his username and password. I told
him that was not what I needed and would not work, confused he has a
user account created for me, and again I have to inform him that this
will be useful, but is not what I need. I send over a link to the
Adobe documentation on how to create an integration account, before
following those directions I am sent a few other random strings of
characters in hopes that one of them will give me the data I need.
Finally, the integration account is created and the client id and
secret are pasted into an email and sent to me over SMTP, plain text
you know. Because users understand security and the complex side of
OAuth, so it is totally reasonable to have them sending client
secrets.
Yes the old credentials were also broken, I thought perhaps, a new API
based on a community standard would resolve that, instead it seems to
have made it worse. Instead of sending me one set of credentials he
has to send me two sets, the client id and secret and a username and
password for an adobeid. The idea behind OAuth as I understand it was
to entirely eliminate this and require that they send me no secrets,
but rather visit a secure page and grant me authorization through the
OAuth process, a familiar login and a few clicks, with secure exchange
of information. The OAuth client_id were between me and Adobe where I
was able to download that information through Adobe's secure website.
That same client_id and secret will be used when Newscom converts to
Adobe Analytics, or another client comes to us with an Adobe Analytics
account.
Avoiding third parties needing to exchange secrets is a primary reason that Oauth exists. Requiring exactly that exchange makes this less secure than a username and password alone.
Posting here, because that is where Adobe directs people to ask questions.
Is this really the way that the new Adobe API works for OAuth or is there something I am missing?
Does it seem reasonable to expect each client to generate a new application integration?
Does it seem reasonable to expect each client to generate a new
application integration?
Well this is just opinion, but yes, I do think it is reasonable to expect each client (Company) to generate their own application Integration.
FYI, the previous user/shared secret you are used to is also tied to an individual adobe analytics account, and is also something the client would have had to setup and provide.
In this case it seems we will need to have a new set of client_id and
client_secret created for one application, for each account we need
access to.
I'm not sure I understand what you mean by this. What exactly are you looking to do with your app? For example, if you are using the Adobe Analytics Reports API, you have the Integration credentials + Your own credentials and you can make Report requests with just that. You do not need credentials for any other user account.
Or, if you have a web interface, you have the option to have the users authenticate with their own credentials.
Overall, the Integration is the middle-man between the Adobe APIs and the user(s) requesting them. The users use their own credentials that they should already have.
Here is an example of it in action (press the login button at the top of the page): https://adobedocs.github.io/analytics-2.0-apis/
Under the hood, there is only one Integration setup, and any individual authenticates with their own Adobe ID login credentials, and what they can actually do within the app depends on what kind of permissions their Adobe ID has for that company.
Perhaps it would be easier to explain the flow if you provide example of what your app actually does?
We are developing an SPA - full client base javascript application and need to authenticate our users to get access to the internals.
As I found from the search we can outsource our authentication mechanism and use Google accounts for that. I learned from this site
https://developers.google.com/accounts/docs/OAuth2Login -
How to deal with Google API and mechanism for authentication.
In the short word, we need:
send request to google url with params to ask user to allow SPA use their personal data
in case of success we get a token from Google
we may use this token to get access to API we were asked and work with it.
This is described well and I understand it and have some JS code to make it happen.
What I do not understand.
I have an application with it's private data. I want use user's e-mail as the login, or user id (doesn't matter how to call it) to access app's internals, such as user's created tasks, user's profile, etc. So, to display user's created tasks in my SPA I need query database with the user's e-mail.
I imagine the next scenario:
user click Login with Google button
we obtain an token - this means user was authenticated successfully
we persist user and his e-mail to work with SPA
when user click Logout we clear all access data
Where should I persist this data?
In case of Forms Authentication I understand that we pass login/password to server and if they match the database we create Forms Ticket and store it in cookie.
Is there any similar case with Google's auth? If I'll store user's email in cookie I think that's not very good from security reason. If I'll save a token - I'm not sure why I need it and how to use it in my SPA, I'm not using any Google API after authentication.
Do you have any example case how do we build our process in similar cases?
Thank you.
If all you need is the user's email address, then you would be better off using OpenID instead of OAuth. OAuth provides access to a user's account and services, scoped to a specific resource or set of resources. OpendID is designed just for logging into a third-party service. You can then extract the user's ID and email address from the OpenID login. Note: The ID will always be sent but the email address has to be explicitly requested during authentication.
Google also supports a hybrid OpenID+OAuth scheme that lets you piggyback OAuth requests on top of an OpenID login if there is some resource you need to authenticate to. Take a look at the authentication document to get an idea of how both protocols work and which is better for your scenario.
Once you have the email address returned, you probably shouldn't persist it in a cookie. The normally recommended way to handle it is to add it as a session parameter. That way only the session cookie is stored on the client, and the server can use it find the values it needs. This answer has a good explanation of the differences and when you want to use sessions versus cookies.
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.