Salesforce Identity & Access Basic Terms

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

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.

Authentication

Users are authenticated to who they say they are.(Through Client Id and Client Secret )

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

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.

Consumer Key

A value used by the consumer to identify itself to Salesforce. Referred to as the client_id in OAuth 2.0

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.

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.

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.

Authorization

Apps are authorized to access resource.(Through Acess Token).

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

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.

In which OAuth flow is the Implicit Grant used?

In the User-Agent OAuth flow

Which OAuth flows allows the 'Use Digital Signatures' ?

JWT Bearer Token or SAML Bearer Assertion flow

My Domain

My Domain allows you to define your own domain name within the Salesforce domain (for example, https://companyname.my.salesforce.com). 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.

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.

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).

Which OAuth flow can be used for renewing tokens issued by the web server or user-agent flows?

Refresh Token Flow

Which OAuth flow does not require you define a connected app?

SAML Assertion flow

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.

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.

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 Force.com 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).

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.

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.

startURL

This is the URL where you want the user to be directed when sign-on completes successfully. This URL can be absolute, such as https://yourInstance.salesforce.com/001/o 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.

logoutURL

This is the URL where you want the user to be directed when they click the Logout link in Salesforce. The default is http://www.salesforce.com

ssoStartPage

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.

In which OAuth flow is the Authorization Code grant used?

Used in the Web Server OAuth Flow

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.

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.