User Agent Flow

User Agent Flow in Salesforce | The Developer Guide

User Agent Flow (Mobile App Integration)

A simple flow for clients that don't need to include global secrets (such as distributed apps) but can be trusted with per-user access tokens. This flow is recommended if you are building a mobile or desktop application and can distribute your application to anyone. Therefore, this type of application is not considered secure with respect to client secret storage as the source code of the application is open to all users and the client's secret can easily be exposed.  

Requirements:

  • Browser - for token requests, authentication/consent, and token redirection 
  • The client can protect the access token. 
  • Current safety measures and mitigations beyond current specifications. 

dont miss out iconDon't forget to check out: Understanding Web Server Authentication Flow | Web App Integration

What else to know:

  • Recommended history for browser apps* 
  • Risks of this flow 
  • Access tokens in URLs can easily be leaked
  • In browser referrals 
  • From browser history 
  • No mechanism to encrypt and bind the access token to the client - access token injection is relatively easy via CSRF 
  • Refresh token not recommended 
  • But without these, silent re-authentication relies on third-party cookies 

*Current IETF recommendation is to not use this flow: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16 

  • Currently used by Salesforce Mobile SDK and Mobile Publisher 
  • Mitigations in Salesforce implementation 
  • Tokens/sessions in URL hash fragments (no query string parameters) 
  • Programmatically removing token callbacks from browser history recommended 
  • Session ID returned (using the hybrid_token option) for re-authentication without third-party cookies. 

OAuth 2.0 User Agent Flow

  • This flow is recommended if you are building a mobile or desktop application and can distribute your application to anyone. Therefore, this type of application is not considered secure with respect to client secret storage as the source code of the application is open to all users and the client secret can easily be exposed. 
  • This flow is used when an external system application needs to log into Salesforce using Salesforce credentials. Once the user logs in, we need to allow the external application to retrieve Salesforce data (scopes defined in the connected app). 
  • In this flow, the external application simply passes the client ID, the user's login page opens, and the user authenticates himself and gets an access token and a refresh token. 
  • External applications can use the refresh token to obtain a new access token when it expires, avoiding the user from logging into Salesforce again. 
  • In the user-agent authentication flow, the client app receives the access token as an HTTP redirect. The client app asks the authorization server to redirect the user agent to another her web server or accessible local resource. The server can extract the access token from the response and Send it to the client app. For security reasons, the token response is provided as a hash fragment (#) in the URL. Prevents the token from being passed to the server or other servers in the referral header. 

dont miss out iconCheck out another amazing blog by Mohit here: Understanding Web Server Authentication Flow | Web App Integration

Considerations for Choosing Implicit Grant Flow

  • Salesforce's implementation has been established for some time, avoiding custom alternatives for Mobile SDK apps. 
  • Multiple vulnerabilities are possible. 
  • Complications for cross-domain use cases when disabling/disabling 3rd party cookie support 
  • The current IETF recommendation is not to use this flow. 

 Reference: salesforcereader

Responses

Popular Salesforce Blogs