- The flow can be used in circumstances where a client secret can't be protected, for example in a mobile or desktop application, or client app running in a browser, such as a SPA
- Identity is based on the same-origin policy (redirect_uri must match one of the Callback URL values in connected app)
- The flow is sub-optimal from a security perspective in many scenarios, as tokens are transmitted in URL. This means they are accessible to the browser and stored in browser history, which is frequently synced across devices and susceptible to attack. It's advisable to ensure that access token validity is short and refresh tokens aren't used to reduce the risk of such attacks
- Prior to 2017, this flow was recommended as best practice for mobile and native applications, however the current recommendation is to implement the more secure Authorisation Code with PKCE flow described below in contexts where an out of band POST can be made
- The Salesforce "User-Agent" flow is an adaptation of the OAuth 2.0 Implicit Grant flow where Salesforce acts as the authorisation and resource servers. Some security counter-measures (e.g. tokens and sessions being returned in URL hash fragments rather than query string parameters) have been implemented to improve security. A connected app is needed to support this configuration
- Salesforce Mobile SDK implements the User-Agent flow, so apps developed through this framework (including Mobile Publisher apps) will authenticate in this way
Documentation
Reference Implementations
This Flow in Context
