Application Security

Getting started with identity and access management: the new stack

Getting started with identity and access management: the new stack
Written by ga_dahmani
Getting started with identity and access management: the new stack

If your business is expanding, you may find that you offer many more software applications and APIs than you originally did, all of which are likely to use sensitive and personal data. This data must, of course, be protected. So where do you start and how do you make sure you get it right?

Security challenges to consider

judith kahrer

Judith is a product marketing engineer with a keen interest in security and identity. She started her working life as a developer and moved on to being a security engineer and consultant before joining the Curity team.

It can be challenging to deliver a good security implementation with limited resources that addresses all open web application security projects. Top 10 API Security Risks. There are many requirements to consider; These are some of the most important:

  • Avoid data leaks and prevent cyber attacks
  • Meet regulatory requirements
  • Integration of security features in a simple and scalable way

Architectural requirements like these necessitate an architectural solution that is designed once and repeatable across the organization. You need to ensure that the solution is scalable as your deployment grows so that the same patterns can be used and understood across many teams.

Safety standards are important

By using security standards designed and vetted by industry experts, you can set a high baseline for security. Modern application security standards are based on the Automatic authentication 2.0 family of technologies, providing good capabilities, including excellent connectivity to other systems and the ability to integrate with most stacks. OAuth provides a mechanism to control which parties can access which information.

Another necessary standard is Open ID connection, an identity layer that sits on top of OAuth. Allows verification of an end user’s identity based on authentication performed by an authorization server. It also allows clients to request and receive information about authenticated sessions and end users.

Creating a security architecture

For reference, a token-based security architecture is recommended. In a token-based system, your applications, “clients” in OAuth terminology, integrate with an identity server and communicate securely with APIs through a reverse proxy that acts as gatekeeper for the tokens. of access.

Relying on security experts to implement your system is recommended, and for tough security jobs, two types of components should be considered:

  • An identity server provides an implementation of the OAuth standards and handles the security details, including authentication and token issuance.
  • Certified Security Libraries enable authentication and verify received tokens.

You do not necessarily have to buy expensive products. Instead, you can start with free or open source implementations, such as the community edition from the Curity identity server.

A modern, mature security architecture consists of a few different elements, all of which work together for the benefit of your applications. Let’s take a closer look at how they contribute to identity and access management solutions.

Clientele

Applications use security libraries to integrate with the identity server for user authentication and to obtain access tokens. This process occurs in different ways, and each “flow” has its own security benefits, depending on the use case.

After the user is successfully authenticated, the identity server issues tokens. Tokens define what data the client can access and what operations the client or downstream APIs can perform on that data on behalf of the user. Depending on the requirements, the user may be required to explicitly consent to this “delegation” as part of the authentication process.

access tokens

Think of the access token as the entrance ticket to an API. Access tokens contain enough data for the API to perform proper authorization. There are two types of access tokens: Light Opaque Reference Tokens Y value-structured tokens.

In a secure architecture, Internet clients receive short-lived reference access tokens. The reference token points to the security state stored on the identity server. APIs receive tokens by value in the form of digitally signed JSON Web Tokens (JWTs) that already contain security state. The reverse proxy is in the middle.

reverse proxy

The reverse proxy, such as NGINX Ingress or a cloud API gateway, is the gatekeeper that prevents the identity server from being directly exposed to the internet. This is good practice because these components connect to sensitive data sources. The reverse proxy hides the internal structure and can also run plugins to perform security tasks, which can help keep API code focused on business.

One such security feature is authorization. Since every request goes through the reverse proxy, you can ensure that only authorized requests go through. As part of the application, you can perform basic token validation. Additionally, the reverse proxy can exchange incoming reference tokens for JSON web tokens that it forwards to APIs. This approach is called the Ghost token pattern.

In the ghost token approach, the reverse proxy uses the identity server’s introspection capabilities to retrieve a value representation of an access token. The reverse proxy commonly caches the results for future requests with the same access token.

A reverse proxy usually already exists in the current API infrastructure. Consequently, the old architecture does not require any new system but rather reuses existing solutions.

API token validation

After introspection, the reverse proxy forwards the incoming API request with a JWT access token that is digitally signed by the identity server. The API must validate the token before using the data in its payload. This must be done according to JWT Best Practices.

If the token is considered valid following the recommendations and best practices above, the API can trust the data received in the JWT. You can process “scopes” and “claims” into a main object in memory, which is central to authorization.

API Authorization

The content of the access token is the result of a contract between the identity server and the API. The API uses scopes and notifications for authorization; therefore, the identity server must ensure that the token contains all the data that the API needs for proper authorization.

Scopes are a high-level privilege, and claims provide more detailed data required for business authorization. In combination, they help the API determine whether the client and user can make the request. Study the following example:

Scope: orders_read -> Claim: account-nr : It instructs the API to search for orders for a given account-nr. The API requires the account number to be able to look up any order. The identity server ensures that the token contains the account-nr whenever the orders_read scope is requested.

The API can trust that the client has the right to request the scope on a token because the identity server’s JWT has been cryptographically verified. The API can simply check for the presence of the necessary scopes. The API can also ensure that a claim belongs to the user represented by the token and process the request accordingly.

Some industries require APIs to comply with more complex rules. Therefore, make sure your identity server is flexible enough to issue the necessary scopes and claims to meet these requirements.

Microservice authorization

Using a design pattern like the one above requires only simple code in the APIs and is well suited to a microservices architecture, where each API acts as a separate service. By carefully designing the access token, it is possible to achieve a high level of contention for services.

APIs can forward access tokens to downstream services. Sometimes it can be useful to generate a new token for the download service with updated or reduced privileges.

identity server

The identity server is the heart of the security architecture. Handles OAuth 2.0 and OpenID Connect messages for multiple flows. As part of the flows, the identity server is responsible for authenticating clients and users. Consequently, the server stores secrets, such as passwords and certificates, and integrates with different data sources. Datasources are used to get attributes or store token data. The identity server is, after all, the component that issues sensitive tokens to clients and stores API-related scopes and claims.

End users interact with the identity server during authentication, which can use multiple factors and must also provide a modern and friendly user experience. This experience includes capturing user consent where appropriate. The identity server can be trusted to audit security events and grant privileges. By auditing scopes and claims, the identity server provides a secure record of who has accessed what data over time, based on compliance requirements.

In any software company, multiple APIs and clients will be developed, often with different security requirements. So choose a product that offers a rich set of customization and integration options. This includes support for various data sources and authentication methods, but also screen markup and enriched token issuance behavior. Remember that requirements may change. Therefore, the identity server must be flexible and capable of supporting future use cases.

The security architecture stands and falls with the identity server. Therefore, it must support high-availability upgrades and zero downtime to avoid any outages.

Key Components of Token-Based Architecture

To get started with a secure architecture for identity and access management, implement a token-based architecture with the following key components:

  • An identity server that is responsible for authentication and token issuance.
  • A reverse proxy that protects the APIs and identity server
  • APIs that are based on digitally verifiable authorization statements
  • Certified libraries that implement lower level security for APIs and clients

With a tool like Curity Identity Server Community Edition, you can easily create end-to-end secure solutions at no or low cost, freeing your teams to spend more time on core business functions.

main photo via Pixabay.

About the author

ga_dahmani

Leave a Comment