Web server flow (In OAuth spec terms, Authorization Code Grant) tends to be used for web applications where server-side code needs to interact with Force.com APIs on the user's behalf, for example DocuSign:
Tokens are sent directly from the Authorization Server to the OAuth Client app, providing a high level of security.
User-Agent flow (Implicit Grant) ...
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 ...
A session ID identifies a user using the UI or an API/integration tool. It has a set time to live and may be manually expired by explicitly logging out. It may also be tied to a specific IP address, if configured. Session ID values are valid across all APIs, including SOAP and REST endpoints.
Access Tokens are used by Connected Apps and other OAuth-enabled ...
Sessions expire based on your organization's policy for sessions. Basically, as long as the app is in active use, the session won't expire. Once the session is logged out, the timeout has elapsed, or it is otherwise expired (e.g. an administrator expires all sessions for the Connected App).
There's no way to know how long it will be until your session ...
Just want to update this answer with the latest process, this is built referencing the Google Service Account oAuth instructions (look at REST code) (credit to Jai-Singh for original Salesforce code):
Set up an app in Google's Developer Console. Make sure the API you want to use is turned on for this App.
You will need the "scope" URL for the specific ...
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 ...
As I know:
Session Id: SessionId is obtaines when use login from web interface or does a soap api call. A session is bind by user login time and activity and expires after if user remain idle for specific time.
AccessToken: Access token is a part of standard OAuth flow. It allows to do operation on behalf of user which authorize a connected app or other ...
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 ...
In my experience, the bullet points you've highlighted are pretty much on-target. What I would add is that both NamedCredentials and CustomApplications, make the assumption the OAuth provider (the idP) has a publicly accessible Social or other major API along the lines of Facebook, Google, Twitter, etc where you can import a token or some other credential to ...
In the Enterprise edition I am using, to find the client id and secret for an existing app, I had to go to Setup > App Manager > Down Arrow next to app name > View > look under 'API (Enable OAuth Settings)'.
This was very confusing as you'd think you could go to Setup > Connected Apps > then click on the App name to see it... but nope, it wasn't there. ...
to either Login or test depending on if in production or sandbox
request.setEndpoint('https://[login | test].salesforce.com/services/oauth2/token');
You also need to put the parameters in the body or as URL params and not header
As of Winter '17 there are new JWT methods baked in to Apex.
One hoop you have to jump through is getting your key from Google into a Java keystore (JKS) file. Some general info on getting a JKS file is in the Salesforce docs.
The following creates keystorefile.jks with a certificate named google_cloud, and password notasecret (what Google exports), which ...
If you want to see/change the OAuth details then you need to go to Setup > Create > Apps and select your app from the Connected Apps section, rather than using Setup > Manage Apps > Connected Apps which is what it sounds like you are doing at the moment.
This will only work in the Org that you created the Connected App in, any Orgs that make use of ...
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.
From the Salesforce OAuth JWT Flow documentation (hidden):
A JWT OAuth 2.0 bearer assertion request looks at all the previous approvals for the user that include a refresh_token. If matching approvals are found, the values of the approved scopes are combined and an access_token is issued (with "token_type" value "Bearer"). If no previous ...
It's correct that you cannot perform a Client Credentials grant, but headless authentication, scoped to a user, is pretty easy. You can accomplish this with the OAuth 2.0 JWT Bearer Token Flow
Create a Connected App
Generate an X509 Cert and upload the cert to the Connected App
Set the connected app policy to Admin approved users are ...
JWT Token: SF will issue the token for you. When your code uses the named credential to call your 3rd party service, SF will send the newly issued JWT token to your 3rd party service as a bearer token (a type of access token).
JWT Token Exchange: SF will issue a JWT and send it to the external authorization service. The authorization service will exchange ...
After much trial and error. I think this may be due to simple mis-configuration of the Connected App.
Check the Scopes closely. For my trailhead app I needed the api, web, refresh_token scopes. I had omitted one of these. Obviously the scopes required will vary for the app, but at a minimum we need these 3.
Scope parameter docs: https://help.salesforce.com/...
The SFDX URL can be used to authenticate to the Salesforce CLI without needing any JWT Token or using the browser to key in the credential.
In fact it is the easiest way to authenticate through CLI. Let me explain how salesforce CLI authenticates today.
The first time when you log in via the CLI, you go to the salesforce login screen and key in credentials (...
Refresh flow uses application/x-www-form-urlencoded content type, not application/json, with a body of the form
Here's a test I just ran, with credentials removed, and formatting added:
$ curl -d 'grant_type=...
I now have this working for the specific case of connecting back to Salesforce from Salesforce. So essentially it is a port of the Java sample code to Apex. So it appears that Apex's RSA-SHA256 is indeed equivalent to Java's SHA256withRSA.
Steps to get this to work were also:
Create a certificate via Setup -> Security Controls -> Certificate and Key ...
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 ...
The different endpoints are used for different authentication flows, this is all covered in the REST API documentation.
The /authorize endpoint is used for the Web Server OAuth Authentication Flow and User-Agent OAuth Authentication Flow.
The /token endpoint is used for the Username-Password OAuth Authentication Flow and the OAuth Refresh Token Process.
Support have come back with:
confirmed with R&D that this is not a BUG rather a security update
that is introduced in Winter'15 release
affected customers will need to adjust their integration's to not rely
on a guest session ID
This might not be what you're looking for, but I felt like I should float the idea out there anyways.
One good restrictive OAuth Scope is: Provide access to custom applications (visualforce). With this scope, all regular api calls will fail, and you can restrict access to just the few visualforce pages that you want that user/profile to have access to. ...