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