The document provides a comprehensive overview of OAuth and its implementation with Salesforce, covering authentication vs. authorization, OAuth 2.0 protocols, connected apps, and various OAuth flows. It explains the significance of tokens, client IDs, client secrets, and scopes in securing user data, along with demonstrations of integration. Additionally, it introduces OpenID Connect as a solution for authentication and discusses identity and access management in Salesforce.

1. OAuth with Salesforce -
Demystified
calvin.noronha@bluewolf.com, @calvin_nr
Calvin Noronha, Technical Architect at Bluewolf, an IBM company

2. Agenda
Introduction
Authentication v/s Authorization
Authorization - OAuth 2.0
Connected Apps
Tokens, Client ID and Client secret
OAuth scopes
OAuth flows
Demo – 1
Authentication - OpenID Connect
OpenID providers
OpenID Protocol
OpenID response with ID token
Demo – 2
Identity and Access Management Designer Certification
Q&A

3. Introduction

4. Authentication v/s Authorization
Pic1: https://i.imgur.com/y6dBO1Y.png
Pic2:https://media.licdn.com/mpr/mpr/AAEAAQAAAAAAAAnMAAAAJDgxMTA4ODRkLWRiYzItNDZkYS05ZDI2LTY3MDFkNmM1NWNhMA.jpg
Authentication Authorization
Who you are?
Example: Checking into a hotel
at the front desk
What you can do?
Example: Hotel key card gives
access to room, gym and pool

5. Authentication
 Authentication is a process of identifying a user based on a set of verifiable credentials such as
a username and password.
 In a client-server paradigm, a server validates the identity of a client either by itself or by
forwarding the request to a trusted 3rd party provider.
 Authentication determines if you are really who you say you are.
 Identity Management

6. Authorization
 Authorization determines if a user has permission to access resources on the server post
authentication.
 During Authorization, the system verifies the access of an authenticated user and can:
Grant access to protected resources
Deny access
 Authorization cannot occur without Authentication
 Access Management

7. Authorization

8. What is OAuth?
You may have seen options to login to websites using your Salesforce or social media
credentials.

9. An open protocol to allow secure authorization in a simple and standard method from web,
mobile and desktop applications.
• (Official definition from OAuth.net)
What does this mean?
• Basically allows a user’s information to be used by a 3rd party service without exposing the user’s
password.
OAuth 2.0

10. Why OAuth 2.0?
 Security – Can you trust a 3rd party application with your password?
 End users can authorize 3rd party applications with a click of a button.
 OAuth can work securely with SSL so data transfer is protected.
 Access to the resource server can be revoked easily.
 As a developer, you no longer stored passwords inside source code!

11. Roles in an OAuth flow

12. Enter Tokens
 “Tokens” do the actual heavy lifting in OAuth 2.0
 Used instead of usernames and passwords to grant access to specified resources for a
specified duration.
 Three types:
• Access – Short lived token which allows the application to access user data. In Salesforce, this is your session ID.
• Refresh – Long lived token which can be used to acquire a new access token. Can be revoked.
• ID token – This is related to OpenID Connect which we will review a bit later.

13. Salesforce and OAuth 2.0
 Salesforce provides extensive support for OAuth 2.0
 Support began since Winter’11!
 Around eight types of OAuth “flows” are supported by Salesforce as of Nov 2017.
 You can easily access Salesforce API’s such as the REST API or Chatter API’s using OAuth.

14. Connected App
 This is a special kind of Salesforce App that allows us to access Salesforce API’s using OAuth
2.0.
 Connected Apps do the following:
• Authenticate
• Provide Single Sign On
• Acquire access tokens
 You can provide the following information:
• Redirect URL, Scope etc.
 After configuring the Connected App, you will receive the Client Id and Client secret.
 Control user access with Profiles and Permission sets.

15. Connected App

16. Client ID and Client secret
 Any application that works with OAuth generally needs 2 pieces of information.
 Client ID – This is a public identifier for your application.
• Should be unique across all clients.
• Best to be non-guessable.
• Example: Salesforce -
3MVG9d8..z.hDcPK2PZTmDxggApSo.Cdd2H7ME9w6Yp6AUgEJeeCdkvXVLfpnFialOG.JQLmPFWxhSwcxV_A7
 Client Secret – This is a secret value known only to the application and authorization server.
• Should be used only in the web-server flow.
• Never include this in a mobile or browser based app as it cannot be protected.

17. OAuth Scopes
 Scopes provide selective enabling of
access to a user’s account based on
required functionality.
 In Salesforce, scopes control the types
of resources available to an application.
Some of the scopes are:
api
chatter_api
full
id
refresh_token
web

18. OAuth access token request
Parameters:
 Code
 Grant_type
 Client_id
 Client_secret
 Redirect_url

19. OAuth response payload

20. OAuth Flows in Salesforce
 Web-Server flow
 User-Agent flow
 Username-Password flow
 SAML Bearer Assertion flow
 JWT Bearer Token flow

21. Web-Server Flow
 Used by web server applications which need to interact with Force.com API’s on behalf of a
user.
 These web apps run on a server where the code is not available publicly.
 Higher degree of security because the client secret is protected.
 Use when: You have a web application running on a server that can securely store the
consumer secret.

22. Web Server Flow
Diagram taken from: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_web_server_oauth_flow.htm

23. Other OAuth flows
OAuth Flow Use Case
User-Agent flow You have a client side mobile/browser application which cannot secure
the client secret.
Username-Password flow Used by applications that work without requiring user interaction to
actively give authorization.
SAML Bearer Assertion Flow A signed SAML 2.0 Assertion along with a digital signature can be used to
obtain an OAuth access token.
JWT Bearer Token Flow Server-to-server API integration uses JSON Web Token (JWT) to obtain
an OAuth access token.

24. Demo - 1
 Use the Web Server OAuth flow to integrate an external website on Heroku with Salesforce.
 Fetch and display recently modified Account records.
 The demo will comprise of:
 Quick walkthrough of the working solution
 Step by step explanation of the OAuth flow
 Understanding implications of OAuth scopes.
 Explanation of the how the solution was built along with config and code walkthrough.
 Built using:
 Heroku
 ForceTK library
 HTML, CSS, Bootstrap

25. Authentication

26. OpenID Connect
 OAuth 2.0 is great at providing Authorization. SAML is generally used for Single Sign On
authentication.
 OpenID Connect is a identity layer built on top of the OAuth 2.0 protocol.
 It allows the verification of an end user using authentication performed by the Authorization server.
 This is Authentication which is deeply integrated with Authorization.
 Salesforce uses it to authenticate users across orgs and providers.

27. OpenID Providers

28. Why not use OAuth 2.0 for Authentication?
 OAuth 2.0 was designed for Authorization and identity is out of its scope.
 Access token does not represent a user’s identity.
 OpenID helps to implement single sign on.
 OpenID Connect is OAuth Authorization + Authentication.

29. OpenID Connect Protocol
Diagram taken from: https://developer.salesforce.com/page/Inside_OpenID_Connect_on_Force.com

30. OpenID Connect response
Diagram taken from: https://developer.salesforce.com/page/Inside_OpenID_Connect_on_Force.com

31. Demo - 2
 Social Sign On into a Salesforce org using Google credentials with Google as the OpenID
identity provider.
 The demo will comprise of:
• Quick walkthrough of the working solution
• Understand how to easily set up an OpenID login to Salesforce.
• Understanding the role of the Authentication Provider.
• Explanation of the how the solution was built along with config and code walkthrough.

32.  Part of the Architect
designer certifications and
is required to complete the
“System Architect”
Certification, a prerequisite
for the Salesforce Certified
Technical Architect (CTA).
 Part of the
#JourneyToCTA
Identity and Access Management Designer Certification
 Authentication and Authorization related concepts with
Salesforce w.r.t to Single Sign On (SSO)
 Understanding of the various Salesforce Identity features.
 Knowledge of the different OAuth 2.0 flows.
 Covers related security features such as 2FA and high
assurance sessions.
 http://bit.ly/2gqrama

33. Further Reading
URL Description
http://sforce.co/2zypdaQ Learn more about Salesforce OAuth flows
https://oauth.net/ Official OAuth website.
http://sforce.co/2yKcNiB Certified Identity and Access Management Designer Certification.
http://www.decodingthecloud.com My blog.
http://bit.ly/2h4BSMf Access Salesforce API’s using JSForce.
http://bit.ly/2ivxRUC Access Google API’s using OAuth 2.0
http://bit.ly/2xispH1 A tutorial about integrating Salesforce and LinkedIn using OAuth
2.0
http://bit.ly/2y2j8r6 Access the Fitbit API using OAuth 2.0
http://bit.ly/2ivNxHe The actual OAuth 2.0 protocol.
http://sforce.co/2zypdaQ Best Salesforce article about OAuth 2.0
http://sforce.co/2iufb7s Identity and Access Management Trailhead trail.

34. Questions?

35. @calvin_n
r
http://bit.ly/2yv55ul