Authorization is the process of evaluating if a user or an application can access a specific resource.
CYM-Identity allows you to control which resources applications can access.

Example

You have two different applications :
  1. an ecommerce site
  2. a support portal for your customers to create & manage their cases
From a security perspective, you would like to separate the access between the two sites. Meaning that the eCommerce site cannot access the Cases API and data.
Below is a simple diagram of what this authorization would look like
authorization delegationauthorization delegation
To accomplish this separation and authorization, you'll use oAuth2.
oAuth2 does a little more than this. You can read the oAuth Introduction section to find out more.

oAuth Scopes

CYM-Identity allows you to use the oAuth2 scopes to enforce authorizations on applications.

Applications

When you create an application, you can assign it a set of scopes which gives it the access to all APIs which accept these scopes. This is the main way to grant access to applications. Any requests with other scopes will be rejected by the Authorization Server (Realm).

API authorization

There are three patterns for protecting Resource Servers and APIs. Each one of them has different levels of control done at CYM-Identity level.

No control (Hands off)

No Authorization Server ControlNo Authorization Server Control
  1. The application requests the Authorization Server for access on behalf of the user
  2. The Authorization Server forwards the request to the Salesforce Community to authenticate the user (and get consent in case the application is not admin approved)
  3. The Salesforce Community returns the user with the consent to the Authorization Server
  4. The Authorization Server returns an access_token to the application
  5. The Application makes an authenticated request to the Resource Server.
    1. The Resource server has to read the access_token and validate it. If the access_token is a JWT, this step must fail since the audience will be different from the Resource Server.
    2. The Resource server will have to somehow understand if the application has access.
  6. The Resource Server returns a response to the Application
In this pattern, CYM-Identity Authorization Servers (Realms) do no specific processing to help protect the Resource Server. It's up to the resource server to understand and process the request. This is a decentralized pattern.
With this pattern, the Resource Server can take the access_token it received and use it against other resource servers. Potentially gaining access that it's not supposed to have.
It's a weak security pattern.

Audience controlled authorization

Audience Restricted AuthorizationAudience Restricted Authorization

Pre-requisite
The Resource Server registers specific scopes that applications must hold BEFORE receiving an access_token
Flow
  1. The application requests the Authorization Server for access on behalf of the user, specifying the Resource Server as the audience of the request. (using the audience request parameter)
  2. The Authorization Server forwards the request to the Salesforce Community to authenticate the user (and get consent in case the application is not admin approved)
  3. The Salesforce Community returns the user with the consent to the Authorization Server
  4. The Authorization Server returns an access_token to the application
    1. The Authorization Server verifies that the application holds the required scopes to receive an access_token. If it's not true, an error will be returned to the application.
    2. An access_token is generated with the audience restricted only to the Resource Server
  5. The Application makes an authenticated request to the Resource Server.
    1. The Resource server has to read the access_token and validate it. The audience of the access_token will match the Resource Server
    2. The Resource server will have to read the scopes and further authorize the request to the appropriate data.
  6. The Resource Server returns a response to the Application
In this pattern, CYM-Identity Authorization Servers (Realms) will block requests that do not match the scope policy for the Resource Server. This stops the flows early on and therefore do not require the Resource Server to act.
The Resource Server cannot take the access_token and replay it on other resources since it's properly audience restricted

Resource controlled authorization

Resource Restricted AuthorizationResource Restricted Authorization

Pre-requisite
The Resource Server registers its protected resources with the Authorization Server. Each Resource can have different scopes. In addition, it can also specify a max_age which controls the timespan since the last user authentication
Flow
  1. The application requests the Authorization Server for access on behalf of the user, specifying the Resource as the audience of the request. (using the resource request parameter)
  2. The Authorization Server forwards the request to the Salesforce Community to authenticate the user (and get consent in case the application is not admin approved)
  3. The Salesforce Community returns the user with the consent to the Authorization Server
  4. The Authorization Server returns an access_token to the application
    1. The Authorization Server verifies that the application holds the required scopes to receive an access_token. If it's not true, an error will be returned to the application.
    2. The Authorization Server verifies that the last authentication of the user happened before the max_age.
    3. An access_token is generated with the audience restricted only to the Resource Server
  5. The Application makes an authenticated request to the Resource Server.
    1. The Resource server has to read the access_token and validate it. The audience of the access_token will match the Resource Server
    2. The access_token will also have a reference to the resource. Meaning that a malicious application cannot replay the access_token to gain access to a different resource on the same Resource Server
    3. The Resource server does not have to read the scopes. It can further authorize the request to the appropriate data using other parameters (sub, ...)
  6. The Resource Server returns a response to the Application
In this pattern, CYM-Identity Authorization Servers (Realms) will block requests that do not match the scope and max_age policy for the Resource Server. This stops the flows early on and therefore do not require the Resource Server to act.
The Resource Server cannot take the access_token and replay it on other resources since it's properly audience restricted