Identity and Access Management Primer

This article provides an entry-level explanation of Identity and Access Management (IAM) concepts. Practical advice is provided on implementing IAM for small businesses, startups, or other organizations with a shoestring budget.

Startups and Digital Solutions

Startup companies often begin with an original business idea then deliver many software applications and APIs. These apps use sensitive data that is not always owned by the startup company. Thus, they must secure access to the data.

Security Challenges

Small companies often struggle to deliver a good security implementation that addresses the OWASP Top 10 API Security Risks. With limited resources, it's challenging to estimate costs and organize team members while addressing the following requirements:

• Avoiding data leaks and cyber attacks
• Meeting compliance and regulatory requirements
• Integrating security features in a simple and scalable manner

These are architectural requirements that need an architectural solution. Your security should only need designing once and should then be easy to grow.

Security Standards

Security standards for modern apps are based on the OAuth 2.0 family of technologies, which provide the best capabilities. The technology provides great connectivity with other systems and can be integrated into most stacks:

• OAuth 2.0
• OpenID Connect

OAuth provides a mechanism to control which parties can access which information. Below, we will describe the recommended architecture in terms of data. When done correctly, this provides a technically simple solution.

Security Architecture

At a minimum, startups should use the following components in their security architecture. Your apps are described as 'clients' in OAuth terminology, and they interact securely with APIs.

These apps outsource the difficult security work to two types of components, both of which are implemented by security experts:

• The Identity Server provides an implementation of OAuth standards, dealing with security details, including authentication and token issuance.
• Certified Security Libraries trigger authentication and verify received tokens.

Clients

Within apps, users authenticate at the Identity Server to obtain an access token. There are multiple variations or 'flows' for this process, each with its own security nuances. OAuth flows are initiated when security libraries call Identity Server endpoints using standards-based messages.

After authentication, the Identity Server issues tokens that control which data can be accessed and which operations can be performed on that data. This 'delegation' can be automatic or can involve approval by the end-user.

Access Tokens

Next, access tokens are used as a message credential when calling APIs. The following approach is the most secure way to manage them:

• Internet clients receive short-lived access tokens in a lightweight opaque reference token format.
• The reference token is a pointer to the security state stored in the Identity Server, which will be forwarded to APIs later on.
• APIs receive digitally signed JSON Web Tokens (JWTs) containing the security state, then use this data to authorize access to resources.

Reverse Proxy

Since the Identity Server connects to sensitive data sources, it should not be directly exposed to the Internet. Instead, security experts recommend hosting the server behind a simple reverse proxy, such as an NGINX Ingress or a Cloud API Gateway.

The reverse proxy's main architectural role is to swap incoming reference tokens for JSON Web Tokens to retrieve the security state from the Identity Server and forward it to APIs.

This requires the below introspection capability, and the proxy may also perform some basic token validation. It is common for the proxy to then securely cache results for future requests with the same access token.

These days, a reverse proxy usually already exists in your API infrastructure. So, the above behavior does not require any new systems. Curity provides tutorials on setting up reverse proxy introspection for various providers:

• NGINX Phantom Token Module Integration
• Azure API Management Integration

API Token Validation

After introspection, the reverse proxy forwards the incoming request to the API, updating the HTTP Authorization header with the JWT. The API must then cryptographically verify the token's digital signature on every request before using the token data.

APIs must receive security state in a digitally verifiable manner, as opposed to unverifiable plain data that could be exploited. The API must also follow JWT Best Practices to avoid potential vulnerabilities.

If digital verification succeeds, the API trusts the scopes and claims in the token. These are then processed into a Claims Principal object in memory. The API then uses this object to check if the caller is allowed to perform the requested operation on the requested resources.

API Authorization

The two types of data that APIs use for authorization are scopes and claims. The first of these is a high-level privilege and the second of which is used for more fine-grained access control. The API can, if required, combine the two types of data to enforce access control, as in the below example, which filters orders to only those the user is authorized to access:

function getOrders() {

  if (!this.claimsPrincipal.hasScope("orders_read")) {
    throw forbiddenError("The caller has insufficient scope");
  }

  const customerNumber = this.claimsPrincipal.getClaim("customer_number");
  if (!customerNumber) {
    throw forbiddenError("The caller did not provide a customer number");
  }

  return this.repository.getOrders(customerNumber);
}

Within some business domains, APIs must meet complex rules. Therefore, the Identity Server must be flexible enough to issue the scopes and claims needed.

Microservices Authorization

The above design pattern requires only simple code in the APIs, and scales well to a microservices architecture, where access tokens are forwarded to downstream services. In some cases, it can be useful to generate a new token for the downstream service, with updated/reduced privileges:

Identity Server

The Identity Server is the central security component, dealing with many core areas:

• Handling OAuth 2.0 and OpenID Connect messages for many flows.
• Providing a secure and friendly login experience for end-users.
• Capturing user consent when applicable.
• Storing secrets such as passwords and certificates.
• Issuing confidential tokens to clients, and storing scopes and claims for APIs.
• Auditing security-related events and the privileges granted.

Getting Started

To get started with OAuth security in your own applications, take a look at Application Guides, which contains many API, web, mobile and API gateway examples, in various technologies. OAuth involves a separation of concerns, though the application code is usually only simple, once understood.

Curity Identity Server

Curity provides a full featured IAM system, with comprehensive support for many standards, the most important of which are OAuth 2.0 and OpenID Connect. The implementation is also easy to extend in the crucial places, by configuring the Admin UI, and you can go deeper via plugins when required.

There is a free community edition targeted at developers and startups, with extensive features. See the FAQs Page for product details, then get up and running via the getting started tutorials. You can then start using authenticators in your user facing apps, and claims in your APIs.

Conclusion

Here are the key components you need to implement a secure architecture correctly and to outsource the difficult security work:

• An Identity Server that supports customizing scopes, claims, and authentication
• A Reverse Proxy located in front of APIs and the Identity Server
• APIs that authorize requests using digitally verifiable claims
• Certified libraries that implement lower-level security for APIs and Clients