#linkedin
I have created an application on Linkedin so that my client can automatically publish articles from his website. Linkedin asks me to verify the company for which the application has been created.
So:
I generate a url in the company verification window
I copy the url and send it to the administrator of the page
My client (super admin) receives 'unauthorized Request' response.
Could you help me verify the company? Why if I follow the indicated steps the verification does not work?
Thanks in advance
Related
I'm a bit of a salesforce / web noob, but am testing out the customer 360 external identity licences, along with customer users. My main goal is to authenticate a customer user using OAUTH, get an access token, then use the Salesforce web APIs to access some relevant bits of info for the customer user. However I just can't seem to figure out how to get the customer user authenticated despite being able to do the same just fine for my personal admin user account.
I have the following setup:
a bunch of external identity licences
a profile with the external identity user licence assigned, with the API enabled setting checked.
a connected app setup with relaxed IP restrictions set, all users may self authorize set, OAUTH settings enabled, device flow enabled, and the full access OAUTH scope selected.
an end customer contact with an associated end-customer user, assigned to the external identity profile and thus external identity user licence.
And I'm POSTing to the test token endpoint (https://test.salesforce.com/services/oauth2/token).
I've tried two auth flows, password and device flow for IOT as I want to integrate this with a command line app (which the IOT flow is good for apparently), and while both succeed for my personal salesforce user credentials, they both fail for my test user account credentials.
The server response for the password flow is as follows:
{
"error": "invalid_grant",
"error_description": "authentication failure"
}
End-customer users don't appear to have a security token so I've just been using the password on its own. I can't seem to find a way to generate a security token for these types of users but suspect this could be the issue for this flow.
When trying the device flow the returned verification uri is always https://test.salesforce.com/setup/connect but attempting to login on this page as the customer-user fails with this error:
Please check your username and password. If you still can't log in, contact your Salesforce administrator".
I am definitely providing the correct customer user credentials here so have no idea why this fails.
Does anyone have any ideas on how to get this working?
#eyescream nudged me in the right direction so here's the solution for anyone in the same position as me.
Authentication of external identity customer users is not done using the normal OAUTH REST endpoints (https://test.salesforce.com/services/oauth2/token or https://login.salesforce.com/services/oauth2/token).
Instead you have to setup an experience cloud site, add your customer user profile to the sites list of member profiles, then authenticate using a site specific AUTH endpoint.
For example, if your experience cloud URL is https://sandboxname-companyname.instanceid.force.com, then your OAUTH token endpoint would be at:
https://sandboxname-companyname.instanceid.force.com/services/oauth2/token
Extra things to note:
customer user accounts cannot authenticate using the username-password flow.
the device flow for IOT (or command line apps) will return a verification URL that customer users cannot log in to (https://test.salesforce.com/setup/connect). You can instead use the experience site connect URL (https://sandboxname-companyname.instanceid.force.com/sitename/setup/connect)
I am having trouble understanding how to use oauth 2.0 with users.
I have an app that has users and companies (that users belong to). I want a user to authorize a third party app with their company or them.
I have stored my apps client_id, secret and redirect_url for that third party app.
The user is signed in to the app on the front end and has a button they can click to authorize with the third party app. This will redirect them to the third party website with the client_id and redirect_url. Once the user signs in to that site and has authenticated with the third party it will send a grant token to the redirect_url on my server.
This is where I am having problems. At this point on the server I have received a code that I can then use to get the token. But what the server does not know at this point is who the user was that started the flow. This means once I get the token I do not know who to associate the token with (either user or company).
How can I track which user is authenticating through the oauth 2.0 flow.
This is for sites like Quickbooks, Zoho, Facebook, etc.
Incase anyone stumbles onto this question in the future.
I have a React Front End hosted seperatly than my backend API server.
I was setting the redirect_url to go to an endpoint on the backend server which was an unauthenticated endpoint and where my problem was.
Now the user will go to the authorization url link on the third party. Once they authorize the redirect url will send them to an authenticated endpoint on my frontend react app where they will be signed in already. This page will pull the code from the url and send it back to the server like any other data request which is made by the user. Now on the server I have the code which I can process to get the token and I also now have the user and company to associate it with.
This also make so much more sense because I can have a nice display page showing the user what is happening and when they have been connected.
After completing the DocuSign's OAuth flow with my Docusign App I would like to add a webhook to the user's account using the Connect APIs.
What I managed to achieve so far is complete the OAuth flow, get the token and create a webhook on my OAuth app but instead I want to create it on the user's one.
I think it should be possibile since it's exactly what the DocuSign API explorer is doing: it first makes me follow the OAuth and then allows me to create a webhook on my account.
Am I missing something?
Your OAuth identity on DocuSign can be associated with one or more accounts. You create an account-wide webhook by specifying the account_id in the ConnectConfigurations: create call to end point POST /v2/accounts/{accountId}/connect
So some choices:
If your login has access to your user's account then you're all set.
When your user logs in to DocuSign you could create the webhook using his credentials.
You can also use Service Application authentication, but in all cases, the login used by your app needs permission for the user's account to add a webhook on that account.
Note: by "user" I am assuming that you mean someone who is sending out envelopes. We call that person the "sender." People who receive or sign envelopes typically don't have accounts. They're "recipients."
If you want to know when someone signed, you should add a webhook on either the sender's account or on the envelope itself when it was sent.
In my requirement, i have users in the IS. And I need to log into other applications by entering his user name and password. then the application should call the service provider which is defined inside IS and check whether the person who is trying to log into the application is actually authenticated user, then user name, email and user permissions also should be sent to the application as the response from the service provider.
I'm using OAuth2. Using Is 5.1.0.
Can anyone please guide me how to implement this
Can I check it with rest client tool like postman also?
I use OAuth2.0 of identityserver3 for SSO in company, I cannot understand how does the state parameter prevent the CSRF.
I have copied the attack flow as below:
1.Mallory visits some client's website and starts the process of authorizing that client to access some service provider using OAuth
2.The client asks the service provider for permission to request access on Mallory's behalf, which is granted
3.Mallory is redirected to the service provider's website, where she would normally enter her username/password in order to authorize access
4.Instead, Mallory traps/prevents this request and saves its URL(Callback Url)
5.Now, Mallory somehow gets Alice to visit that URL. If Alice is logged-in to the service provider with her own account, then her credentials will be used to issue an authorization code
6.The authorization code is exchanged for an access token
7.Now Mallory's account on the client is authorized to access Alice's account on the service provider
I can understand step 1 to step 4. But from step 5 I got some confusion. Accordding to my understanding, in step 5 Alice visit the Callback Url when she is logged-in, and then the server just use the authorization code to access the OAuth service provider to get an openid and access token in backend, and then Alice's browser just executing login with Mallory's account and access token.What is the relationship with Mallory's browser?
Could you explain it in detail please? Thank you for taking time to read my word!
I think steps 3 and 4 are not quite right. I've edited your example to show how I think the attack works.
1.Mallory visits some client's website (e.g. https://brilliantphotos.com) and starts the process of authorizing that client to access some service provider using OAuth (e.g. Acebook - as brilliantphotos.com allows its users to post pictures to their Acebook page)
2.brilliantphotos.com redirects Mallory's browser to Acebook's Authorisation Server requesting a redirect back to itself once auth is done.
3.Mallory is redirected to the Authorisation Server, where she enters her Acebook username/password in order to authorize access.
4.After successful login, Mallory traps/prevents the subsequent redirect request and saves its URL(Callback Url with an auth code related to Mallory) e.g.
https://brilliantphotos.com/exchangecodefortoken?code=malloryscode
5.Now, Mallory somehow gets Alice to visit that URL (maybe as a link on a forum post...) note that Alice may already be logged-in to brilliantphotos.com with her own account.
6.Alice clicks the link to brilliantphotos.com and the authorization code is exchanged for an access token (access to naughty Mallory's account). If Alice is logged in then brilliantphotos.com could conceivably associate Alice's account with the newly minted access token.
7.Now if Alice continues to use the brilliantphotos.com website, the client may inadvertently be posting pictures to Mallory's account on the service provider (Acebook).
If a state parameter was maintained by brilliantphotos.com then Mallory's state code would be bound to her browser but not Alice's. Therefore brilliantphotos.com would not be able to correlate the state code with Alice's browser session when Alice clicks on the malicious URL.
Besides iandayman's already great answer, you can also get some inspiration from this blog post, or at least you can take a look into its illustration.
PS: Credit goes to original blog author.