Bringing enterprise-scale continuous access management to the Auth0 authorization server ensures least-privilege access to your APIs and applications. By extending zero-trust principles with continuous access management, you can protect your organization against a variety of risks that arise from attackers or insiders performing unauthorized requests against your APIs and applications protected by Auth0. The SGNL platform brings centralized, continuous access management to your heterogenous application environment.
What is Auth0
Auth0 is a robust developer friendly standards based (i.e. OAuth2, OIDC) authentication and authorization server for API’s and applications. Although Auth0 can operate as an Identity Provider by itself, the Auth0 server supports other enterprise identity providers such as Okta, Azure AD, SAML IDPs, OIDC IDPs, and Ping Identity. Developers use Auth0 to quickly add authentication and authorization capabilities to their applications.
Continuous Access Management
Continuous access management is the combination of methods, technologies, and business processes used to manage access to applications, infrastructure, or data. Continuous Access Management uses a dynamic and real-time authorization check for every request made by a user, device, or application to a resource provider (e.g., Application, Microservice, Database).
Continuous Access Management for Auth0
Auth0 supports coarse-grained authorization (i.e. RBAC), but developers may require advanced authorization logic that can be externalized to a scalable authorization API such as the API provided by SGNL. Here are some reasons why implementing continuous access management for Auth0 protected API’s and applications make sense:
- Adopt a least-privilege strategy for your protected Auth0 APIs and Applications - It is common to see audit findings that demonstrate over-provisioned permissions accumulated over time on applications and APIs. Role-based access control (RBAC) is commonly used to allow access to APIs and applications, but the burden of managing these roles and associated permissions on all resources tends to introduce unwanted risk and complexity.
- Control authentication and login flow - Halt the Auth0 login flow based on authorization decisions made using business context. By leveraging SGNL, a developer can easily check advanced authorization policy to determine whether the Auth0 server should allow the login/OAuth 2 flow to continue. This provides a level of security that extends authorization to the authentication flow itself and helps thwart authentication or session attacks. You can also combine this with the continuous access evaluation profile (CAEP) integration for events such as session revocation, and developers are now capable of implementing a real-time layered security approach.
- Simplification of policy management - SGNL simplifies the creation, management, and auditability of enterprise authorization policies. By using the SGNL policy builder, a developer can pick and choose reusable policy snippets to build a human readable policy. See the sample human readable policy in the How Does SGNL Work section.
Using SGNL For Auth0
SGNL provides continuous access management by building a dynamic graph of sanctioned enterprise activity through continuous data ingestion from systems of record. With SGNL, access control is enforced consistently and easily across all protected services, control points, infrastructure, applications, and data using human-readable policies. By integrating SGNL with the Auth0 authorization server, you can externalize API and application access management to a scalable and centralized modern platform, minimize security exposure, and implement a truly least-privileged approach to securing your Auth0 protected applications.
Business Data Driven Continuous Access Management - Any changes recorded in an organization’s business systems (e.g. Jira, Salesforce, Workday) of record are automatically and rapidly reflected in the Auth0 post-login flow access decisions without changing local Auth0 configuration.
Real-time Audit and Comprehensive Reporting - With SGNL, all access decisions are logged centrally with the policies that contributed to the decision to grant or deny access.
Centralized Human-Readable Policies - Human-readable policies using reusable snippets enable organizations to scale policies without losing manageability and consistency across the application ecosystem. SGNL allows you to create reusable snippets, and reuse them in multiple authorization policies. This allows for easier maintenance, time savings, and broader coverage for an authorization policy.
Consistent Authorization Decisions Across all APIs and Applications - SGNL provides the same access decisions consistently across front end frameworks (i.e. React, Angular) and backend end APIs because they are based on centrally managed policies. Access is enforced front to back and back to front.
Contextual Authorization Decisions - Any access decision is determined considering the context of the request coming from the Auth0 authorization server which keeps the original request context intact.
See the example Auth0 Request Context JSON document for more details.
With SGNL, you can externalize access management for your Auth0 protected application or API to provide consistent, fine-grained decisions that are based on human readable policies, which are based on the dynamic data in your systems of record.
Solution Approach
The solution consists of a sample React (single page application), Auth0 post-login action (see how actions work), the SGNL access service API, graph directory, data ingestion adapters, and human-readable policy used for making authorization decisions. An Auth0 post-login action is configured to send authorization requests to the SGNL access service via the SGNL REST API as part of an Auth0 login flow. The SGNL access service responds to the post-login action with allow or deny decisions considering the context of the authorization request sent by Auth0. For example, context may consist of the principal making the request, the application being accessed, the HTTP verb (e.g. POST, GET, PATCH), and the action (e.g. access, update, create, custom action, etc.). If the request is denied, the post-login action returns a denial to the Auth0 authorization server which stops the OAuth 2 authorization request flow (will not return authorization code) and redirects to the sample React application with a customized error message. Since the entire authorization request flow is stopped, the client single page web application does not issue a subsequent token request to get the access and id_tokens. In this post, you will see an example of a post-login flow action that authorizes a user using the SGNL access service API.
Logical Diagram Of Solution
How Does SGNL Work
SGNL continuously ingests data from systems of record to a central graph directory via resilient and performant data ingest adapters. This data includes identity data, such as users and groups, and any relevant data required to define access policies, such as CMDB, ITSM cases, tickets from JIRA, or customers from a CRM. Applications or protected systems (i.e. API gateways, application servers, web servers) make authorization calls via control points (a.k.a policy enforcement points) to the SGNL policy engine. The policy engine calculates an authorization decision (allow or deny) and returns the decision to the control point or application.
In this post, we use Auth0 itself as the identity provider and user system of record. Jira is the service management system of record. The Jira issue assignee and issue status dictates whether or not a user is authorized to access the sample Auth0 React single page application.
Once the system of record data sources (Auth0 and Jira) are set up, administrators can quickly author and manage human-readable policies based on the ingested data for granting or denying access to applications, APIs, servers, and sensitive data.
This post uses a simple React single page application provided by Auth0 as an example. This application uses the auth0-react SDK for making calls to the Auth0 authorization server. Optionally, this same application may use the SGNL Node.js SDK, to make additional in-application authorization calls to the SGNL access service.
An example of a real human-readable policy for managing access to the example React Application
This policy checks if the principal is an authenticated Auth0 principal and has a valid Jira issue assigned with a status that is “in-progress”. If this policy matches, then the SGNL access service returns allow, otherwise the response will be denied and the Auth0 login flow is halted by the Auth0 authorization server.
Sample Request Flow
The request flow from Auth0 to SGNL is straightforward. When a user authenticates with Auth0, a request is sent from the Auth0 authorization server to the SGNL access service API (REST). The policy engine evaluates the applicable authorization policy and returns an allow or deny to the Auth0 custom post-login action. If the response is a deny, the post-login action sets a deny status via the Auth0 PostLoginAPI.
- An application (e.g. React single page application) makes an authorization request to the Auth0 authorization server.
- Once Auth0 performs coarse grained authorization and authentication, it instantiates the Auth0 post-login action and sends an authorization query to the SGNL access service.
- (A) If the policy decision is allowed, the SGNL access service sends the allowed response back to the Auth0 post-login action. (B) If the policy decision is denied, the SGNL access service sends the deny response back to the Auth0 post-login action.
- (A) If the post-login action receives an allow, then it allows the login flow to continue. The Auth0 authorization server then sends an authorization code back to the application. (B) If the post-login action receives a denial, then the Auth0 authorization server halts the login flow and sends a 302 redirect with an error message and description.
- If the application receives an authorization code from the Auth0 server, the application then makes a request to the Auth0 server’s token endpoint to retrieve the access and id tokens for the user.
- The Auth0 authorization server returns both the access and id tokens to the application.
Auth0 Post-Login Action Sample Code
The following code snippet is an example implementation of the Auth0 custom action for calling the SGNL access service API. This is the function the Auth0 authorization server calls for every protected API or application request. The request context is passed in the function’s request parameter.
You can download the full Auth0 post-login action Node.js example from the SGNL examples repository.
Code snippet from The Auth0 post login flow
/**
* Handler that will be called during the execution of a PostLogin flow.
*
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {
const axios = require("axios");
// Create an instance of Axios HTTP client
const sgnl_api = axios.create({
baseURL: event.secrets.sgnl_url,
timeout: 1000,
headers: { Authorization: event.secrets.Token },
});
// Output requested resource to log for debug
console.log("URI: " + event.request.query.redirect_uri);
// Call SGNL access service API
await sgnl_api
.post(event.secrets.sgnl_url, {
principal: {
id: event.user.email,
},
queries: [
{
assetId: event.request.query.redirect_uri,
action: event.request.method,
},
],
})
.then(function (response) {
console.log(
"SGNL policy decision: " + response.data.decisions[0].decision
);
// Deny access if SGNL policy results in a deny.
if (response.data.decisions[0].decision == "Deny") {
api.access.deny(
`SGNL Authorization: Access to ${event.client.name} is not allowed.`
);
} else {
// Success
}
// uncomment for debug purposes
// console.log(response);
})
.catch(function (error) {
console.log(error);
});
};
Responses
Access Allowed
If the post-login action allows the authorization process to continue, Auth0 continues with the authorization request flow to the sample React application and subsequent request to the OAuth token endpoint (with the authorization code), to retrieve the access and id tokens. Here is a sample response containing the access and id tokens back to the sample React application:
{
"access_token": "{Access token string.}",
"id_token": "{ID Token string.}",
"scope": "openid profile email",
"expires_in": 86400,
"token_type": "Bearer"
}
Access Denied
If the post-login action calls the deny method for Auth0’s PostLoginAPI, then the Auth0 authorization server sends a redirect (HTTP 302) to the sample React application callback URL with an error in the query string.
Example redirect to client application.
http://localhost:3000/?error=access_denied&error_description=SGNL%20Authorization%3A%20Access%20to%20My%20App%20is%20not%20allowed.&state={Random state parameter String}
Note: It is important to always use an OAuth 2 state parameter. The state parameter is primarily used to mitigate against cross site request forgery (CSRF) attacks. See this Auth0 github page for more information.
Configuration
For steps to install, test, and configure the post-login custom action visit the SGNL examples Git repo’s readme file.
Conclusion
Using SGNL for managing access to your APIs and applications, especially high-risk APIs and data - organizations can reduce risk, security administrators can minimize authorization logic complexity, and teams can centralize access management policy in a single platform for making complex, consistent, and continuous authorization decisions.
Schedule time with a SGNLer to see how all this can work in your context.