An introduction to OAuth 2.0 from a Salesforce perspective to establish the foundations of OAuth 2.0. Discusses the key concepts of Authentication and Authorization and distinguishes the two. Also discusses Open ID connect.
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
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!
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.
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
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
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.
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.
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.
Oauth is a vast topic.
“In the context of Salesforce”
GOAL of the session is to understand the fundamentals.
“Single Sign On”
As the Force.com platform evolves, technologies related to integrations or single sign on solutions continue to change rapidly.
Understanding how different applications can securely identify themselves to each other is key to building robust and secure application.
Using passwords to login to a secure website or application is still the common method to “authenticate” users.
“Authentication” and “Authorization” are two distinct concepts.
IAM (Identity and Access Management) is one of the growing challenges in the Salesforce ecosystem.
What if the app is hacked?
Prevent users from revealing their passwords to the server or 3rd party systems.
Instead login using your Google, Facebook, Twitter, Salesforce or LinkedIn etc. credentials.
Best example is facebook game.
“Client” – The Application attempting to access the user’s account. The user has to permit it to do so first.
“Resource Server” – The server that hosts resources and user information.
“Authorization Server” – The server that contains protected information. Generally same as the Resource server.
“Owner” – The person who needs to give access to their account (User!)
Talk about connected apps with LinkedIn, Google or Fitbit
Call back URL (localhost v/s https)
Scopes
OAuth policies
Trusted IP Ranges
Scopes are for fine tuning the client application’s access to Salesforce on the user’s behalf.
Most of the times u don’t see this as u use tools which abstract this.
End goal is to get the access token
Password is sent as part of the OAuth request.
Therefore this should not be used unless absolutely necessary due to risks with exposing the password.
Used by applications that work without requiring user interaction to actively give authorization.
