Salesforce Identity & Access Certification (Winter '18)


Terms in this set (...)

Security Assertion Markup Language (SAML)
Security Assertion Markup Language (SAML) is an XML-based protocol that allows you to transfer user information between services, for example, from Salesforce to Microsoft 365. Apps use this information to authorize users and enable single sign-on. Salesforce supports SAML for single sign-on into Salesforce from a corporate portal or identity provider.
OAuth 2.0
OAuth 2.0 is an open protocol used for single sign-on to allow secure authorization between apps. OAuth authorization flows describe the options for implementing OAuth in Salesforce orgs.
OpenID Connect
Open ID Connect is an authentication protocol based on OAuth 2.0 that sends identity information between services. With OpenID Connect, users can log in to another service, like Gmail, and then access their Salesforce org without logging in again.
My Domain
My Domain allows you to define your own domain name within the Salesforce domain (for example, My Domain makes it easier to manage login and authentication and allows you to customize your login page. Salesforce requires My Domain if you want to use Lightning components in Lightning tabs, Lightning pages, or as a standalone app.
Connected Apps
A connected app integrates an application with Salesforce using APIs. Connected apps use standard SAML and OAuth protocols to authenticate, provide single sign-on, and provide tokens for use with Salesforce APIs. In addition to standard OAuth capabilities, connected apps allow Salesforce admins to set various security policies and have explicit control over who can use the corresponding apps.
App Launcher
The App Launcher gives your users easy access to apps that they use most often. Users go to the App Launcher to launch Salesforce, on-premises, and connected (third-party) apps without logging in again (referred to as single sign-on). The App Launcher displays tiles that link to the available apps. Salesforce admins can make the App Launcher the default landing page when users open Salesforce.
Identity License
The Identity license grants users access to Identity features. The App Launcher is available to all Lightning Experience users. Salesforce Classic users must have the Use Identity Features permission to get the App Launcher.
Identity licenses are included with all paid user licenses in Enterprise, Performance, and Unlimited Editions. Ten free Identity user licenses are included with each new Developer Edition org. You can also purchase a standalone Identity-only license.
External Identity License
An External Identity license grants Identity features such as the App Launcher and single sign-on to external users. With External Identity, you can give your customers and partners access to your org through an external identity community.
The license is included with all paid user licenses in Enterprise, Performance, and Unlimited Editions. Ten free External Identity user licenses are included with each new Developer Edition org.
Identity Provider and Service Provider integration
An identity provider is a trusted provider that lets you use single sign-on (SSO) to access other websites. A service provider is a website that hosts apps. You can enable Salesforce as an identity provider and define one or more service providers. Your users can then access other apps directly from Salesforce using SSO. SSO can be a great help to your users—instead of having to remember many passwords, they only have to remember one.
Salesforce Identity Connect
Identity Connect integrates Microsoft Active Directory (AD) with Salesforce. User information entered in AD is shared with Salesforce seamlessly and instantaneously. Companies that use AD for user management can use Identity Connect to manage Salesforce accounts.
Two-Factor Authentication
With two-factor authentication enabled, users are required to log in with two pieces of information, such as a username and a one-time password (OTP). Salesforce supports user-defined OTPs and OTPs generated from software or hardware devices.
This is the page to which the user should be redirected when trying to log in with SAML. The user is directed to
this page when requesting a protected resource in Salesforce, without an active session. The ssoStartPage should be the
SAML identity provider's login page.
This is the URL where you want the user to be directed when sign-on completes successfully. This URL can be absolute,
such as or it can be relative, such as /001/o. This parameter
is only used in SAML 1.1. In SAML 2.0, the start URL is the page the user attempted to access before they were authenticated.
This is the URL where you want the user to be directed when they click the Logout link in Salesforce. The default is
When is My Domain required?
-Single sign-on (SSO) with external identity providers
-Social sign-on with authentication providers, such as Google and Facebook
-Lightning components in Lightning component tabs, Lightning pages, the Lightning App Builder, or standalone apps
Consumer Key
A value used by the consumer to identify itself to Salesforce. Referred to as the client_id in OAuth 2.0
Consumer Secret
A secret used by the consumer to establish ownership of the consumer key. Referred to as the client_secret in OAuth 2.0
Authorization Code
An authorization code is a short-lived token created by the authorization server and passed to the client application via the browser. The client application sends the authorization code to the authorization server to obtain an access token and, optionally, a refresh token.
Access Token
The access token is used by the client to make authenticated requests on behalf of the end user. It has a longer lifetime than the authorization code, typically on the order of minutes or hours. When the access token expires, attempts to use it will fail, and a new access token must be obtained.

In terms, the access token is effectively a SID or 'session ID', much like a session cookie on other systems, and should be protected against interception, for example by Transport Layer Security (TLS, aka SSL).
Refresh Token
The refresh token may have an indefinite lifetime, persisting for an admin-configured interval or until explicitly revoked by the end-user. The client application can store the refresh token, using it to periodically obtain fresh access tokens, but should be careful to protect it against unauthorized access, since, like a password, it can be repeatedly used to gain access to the resource server.

Since refresh tokens may expire or be revoked by the user outside the control of the client application, the client must handle failure to obtain an access token, typically by replaying the protocol from the start.
ID Token
OpenID Connect defines the ID token, a signed data structure that contains authenticated user attributes including a unique identifier for the end-user, the time at which the token was issued, and an identifier for the client application that requested the token.

The ID token is encoded as a JSON Web Token (JWT).
Users are authenticated to who they say they are.(Through Client Id and Client Secret )
Apps are authorized to access resource.(Through Acess Token).
Authorization Code Grant
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
Implicit Grant
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.

Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other
applications residing on the same device.
In which OAuth flow is the Authorization Code grant used?
Used in the Web Server OAuth Flow
In which OAuth flow is the Implicit Grant used?
In the User-Agent OAuth flow
Which OAuth flow can be used for renewing tokens issued by the web server or user-agent flows?
Refresh Token Flow
When should you use the Username-Password OAuth flow? What are things you can do to minimize risk when using this flow?
You should only use the username and password flow in situations where a user cannot be present at application startup, or with highly privileged applications.

In this instance, you should carefully set the API user's permissions to minimize its access as far as possible, and protect the API user's stored credentials from unauthorized access.
Which OAuth flow does not require you define a connected app?
SAML Assertion flow
Which OAuth flows allows the 'Use Digital Signatures' ?
JWT Bearer Token or SAML Bearer Assertion flow
Callback URL
Depending on which OAuth flow you use, this is typically the URL that a user's browser is redirected to after successful authentication. As this URL is used for some OAuth flows to pass an access token, the URL must use secure HTTP (HTTPS) or a custom URI scheme