I see you've discovered most of this for yourself, but I had this drafted, so I thought I'd post it also, in case it fills in any gaps.
From the docs on connected apps:
An application may be listed more than once. Each time you grant
access to an application, it obtains a new access token. Requests for
refresh tokens increase the Use Count displayed ...
Assuming you've done OAuth, the OAuth response includes an id field with an Identity Service URL - e.g.:
Packaging the connected app allows administrators who install the app to control which of their users can use the application.
Rather than the coarse ability to block or not block an app (seen in Setup -> Manage Apps -> Connected Apps Oauth Usage), you get the ability to control the security settings for the app in a more finely grained manner (seen in ...
In every case, as the app developer, you create a Connected App, obtaining a consumer key and secret for that app. Now users can use your app in any org. That's right - you don't need to create a Connected App (and obtain the key and secret) in each 'target' org - you're good to go.
So, Ryan Brainard, the Workbench author, created a Connected App for ...
An application may be listed more than once. Each time you grant access to an application, it obtains a new access token. Requests for refresh tokens increase the Use Count displayed for the application. You must grant access to your Salesforce data from each device that you ...
The User Agent (UA) and Web Server (WS) flows have two different security purposes. The main difference is that UA is used for untrusted clients, while WS is used for a server application; the WS uses a Client Secret (CS) as an extra authorization parameter to prevent spoofing servers.
The reason for this is that if a server is compromised, everyone using ...
The documentation has a bug in it. Following the documentation, your cURL command would look like this:
curl https://login.salesforce.com/services/oauth2/token -d "grant_type=password" -d
"client_id=XXXXXX.YYYYY_ZZZZZ" -d "client_secret=000099990000" -d "email@example.com" -d
It's missing the username= parameter. ...
Visiting https://nigel.stg.taluslabs.com/subscription/api/v1/accounts/ I notice that your site/service isn't certified with an ssl certificate signed by some verified certificate authority (CA). Salesforce will therefore not accept the certificate and you get the exception you're seeing. You can either switch to unencrypted http or buy a proper certificate ...
After hammering the login.salesforce.com endpoints today (and getting blocked a couple of times), I've established (at least to my satisfaction) that the OAuth interactions around granting access tokens and refreshing them do not count against the API limits.
More specifically, I've hit the following endpoints 1,000 times each today.
Are you copying your authorization code from browser redirect? Its getting URL encoded and hence its saying invalid authorization code.
Check if your auth code is ending with "%3D%3D" replace that with "==" .
This solved my problem plenty of times.
We can do this with Apps and Profiles in Salesforce.
Associate the custom Landing page(VF Page) to a Visualforce Tab (Create --> Tab --> New VF Tab)
Create an App and associate required Tabs to newly created App. (Create --> Apps)
Set the Default Landing page in the App settings.
Now go to Profiles (Manage User --> Profiles --> Custom App Settings)
Set the ...
First you need to create a remote Application .
Setup -->Create --> App-->Connected Apps-->Fill The Necessary Details --> mention CallBackURL as https://ap1.salesforce.com/services/oauth2/token ,Callback URL in salesforce is nothing but what Salesforce will callback with once the user authorizes access to his/her Salesforce account.
Provide callback url as ...
Edited to reflect the fact that Salesforce Mobile SDK is in play
The user can add a custom login host in the settings for their app (on iOS, from the home screen, Settings | Your App | Custom Host) and select it as the current login host.
So, the user can, in principle, add example.cloudforce.com as a custom host and select it for use. You can also add My ...
According to the docs:
The refresh token for the user-agent flow is only issued under one of the following circumstances:
The redirect URL uses a custom protocol.
The redirect URL is exactly
https://login.salesforce.com/services/oauth2/success, or on Sandbox,
The redirect URL uses the ...
Yes, there is some latency; the metadata for Remote Access apps (currently being renamed Connected Apps) takes a few minutes to propagate around the Salesforce servers. I always go make a cup of tea after creating or modifying a Connected App before I test it.
If its a non Web Java desktop application, will it be used as a background process or will always have user access.
a. If its a background process, then you should simply store the credentials in property file may be encrypted and decrypt it before you hit the salesforce apis..
b. If its a user access process, then leverage swing based JDialogbox to ask ...
Salesforce responds to OAuth errors with Standard OAuth 2.0 error codes which can be found in the final version of the OAuth 2.0 spec: RFC 6749.
In addition to the required error attribute, Salesforce will also generally provide the optional error_description attribute.
From the spec doc:
error: A single ASCII [USASCII] error code from the following:
My solution for determining the users email address is going to be to make a SOQL query to the sObject 'User' immediately after the OAuth flow completes. Is there something similar I can do for namespace prefix?
Yes, since Spring `16 you can query Organization.NamespacePrefix in SOQL.
SELECT NamespacePrefix FROM Organization
It's a bit more work, but you ...
It looks like the issue is in your call to retrieve the token. You should pass application/x-www-form-urlencoded data like so:
There is a PHP sample in the Force....
Instead of delegating to a human for credentials, you can use the Username-Password flow (where you securely store the credentials and a security token) - here's an example:
Authenticate with credentials stored on your server (the response will be JSON, not frontdoor.jsp)
$curl = curl_init();
CURLOPT_RETURNTRANSFER => ...
The solution provided by Ivo Rocha is nice but too complex for my case. When I thought deeper about my problem I found out that Apex REST services are not the best solution when you just need to pass their result to a VF page in the same org.
If you want your server to authenticate with some fixed credentials, then you have 2 choices.
You can use the OAuth2 username/password flow, this uses the OAuth infrastructure, but allows you to programmatically get an access token given a username, password (and possibly security token), this is a simple POST request to the correct URL with all the ...
You must use OAth login flow first to have REST access. There is a lot of good information out there about Salesforce OAuth login flow.
In order to make it programatically (Server to Server ), I think that the most efficient way is:
Set the current access_token to the request header you need to do.
Make the request trying to catch any exception.
Looking at the Partner WSDL, the soapAction for the login operation is the empty string.
<!-- .... -->
So you would think that it should be added to the request as such:
HttpRequest req = new HttpRequest();
See Signed Request Authentication.
a change been made to the Permitted Users field from "Admin approved users are pre-authorized" to "All users may self-authorize", or
when using "All users may self-authorize" and the access token was revoked by the administrator or a time limit was set on the token.
From the docs under Permitted User Value "All ...
A connected app is much like an "app" on Facebook. The actual app exists elsewhere, but authenticates with Facebook to retrieve database information (e.g. your friends, date of birth, and email).
Simply direct the user to the authentication service (such as https://login.salesforce.com/services/oauth2/authorize) with your connected app details, and the user ...
The JWT Authentication Flow can be initiaded using the usual OAuth2 Authorization Flow.
Setup the App, get the required client_key and client_secret Build > Create > Apps
Create a new Keypair using the Salesforce page Administer > Security Controls > Certificate and Key Management. Both the public and private key can (and should) be saved.
Short answer is yes. Salesforce can be Authentication Provider and Identity Provider at same time.
The main difference between Authentication Provider and Identity provider is -
Identity Provider : An identity provider is a trusted provider that lets you use single sign-on to access other websites. A service provider is a website that hosts applications. ...