A look at some of the common IAM challenges organizations face and suggestions for implementing a solid strategy for the new year.
For most organizations, the main focus of identity and access management (IAM) is securing access to digital services. This enables users and applications to access secured data correctly, according to the organization’s business rules. If, instead, security is done incorrectly, it can result in data breaches. These can lead to reputational damage or significant fines in some cases.
IAM is sometimes perceived to be a complex area of software engineering. Yet, when done well, IAM provides crucial capabilities that empower an organization and its people. IAM also plays an important role in enabling a modern, scalable and portable architecture. Let’s look at some of the common IAM challenges organizations face and suggestions for implementing a solid IAM strategy.
1. Form an Identity Team
Software is about people first and foremost. When getting started with modern identity and access management, or refreshing your existing implementation, start by forming a team with the following four essential roles. Each member should be a strategic thinker and ideally have some IAM knowledge or experience.
These aren’t full-time roles. Rather, think of them as the people to be informed when solutions are proposed. With their unique backgrounds, these experts can provide input on concerns like technical cost, prioritization, industry-specific regulations that must be met, or how to design a friendly and reliable login user experience. Business backing is especially important to ensure the identity initiative has a sponsor.
2. Produce an Identity Vision
People often think introducing an identity and access management architecture will have a major impact on applications, but this does not need to be the case. Rather than rushing to a technical implementation, focus initially on design thinking. An organization may consult identity specialists but must ultimately make its own architectural decisions.
The identity team should produce one or more high-level documents. This might also include an inventory of the current applications and APIs, summarizing good or bad security behaviors. This will often involve cross-department conversations to get input from various stakeholders. A results summary should clarify what needs improving and the business benefits.
The costs of auditing the existing security posture and creating these documents are only minor and will not adversely affect ongoing business deliverables. Some of the key objectives of the document should be to clarify requirements, identify risks and plan some tasks. The document should “think big” about the capabilities your next-generation security architecture will enable.
3. Document High-Level API Flows
The main requirement of the IAM framework is to secure data. Although this is typically stored in databases, data must be exposed to users in a controlled way. These days, this is usually done by APIs, which allow different types of clients to access the same data. APIs must apply business rules based on user attributes before allowing access to data. Therefore, the foundation of your security is the API message credential, which identifies users and their permissions in a particular context. As such, document a couple of end-to-end flows where message credentials are needed:
Your next-generation security architecture should follow a zero trust approach and secure calls to all APIs from external and internal clients. Use an unforgeable API message credential to deliver secure values to APIs so they cannot be altered. Lock down the message credential so that it has the least privilege possible.
4. Follow Security Standards
The modern API-first way to protect data in digital services is to use the OAuth 2.0 authorization framework. This was introduced in 2012, when API, JavaScript web apps and mobile apps were relatively new.
OAuth is centered on the API message credential, an access token and its use in end-to-end flows. The access token is issued by a component called the authorization server. The access token contains secure values and uses an unforgeable JSON Web token (JWT) format to protect its integrity. APIs only accept JWTs issued by the authorization server. The access token returned to applications enables least-privilege API access, rather than always granting the user’s full privileges. A simplified end-to-end security flow is shown here:
Since OAuth 2.0 was introduced, many other security specifications have been created that map to specific security use cases for organizations. Many of these specifications are highly intricate, requiring much effort to implement. The authorization server is provided by security specialists who continually add support for new standards. The authorization server can be viewed as a specialist API the organization hosts right next to its own APIs.
The more subtle benefit of OAuth is its scalability. Difficult security is externalized from applications and APIs. Improved security is often enabled by reconfiguring the authorization server, with zero code changes. The security design patterns used by OAuth are straightforward for many people across an organization to learn. They also provide a common security vocabulary when discussing identity topics.
Many authorization servers have only limited support for standards. Therefore, the identity team should choose the authorization server wisely to provide the organization with up-to-date and future-proof security capabilities.
5. Design Onboarding
One of the early decisions to make with an IAM is which data to store against user accounts. It is common to migrate the core identity attributes of existing users to the authorization server using its user management APIs. By doing so, many core identity concerns, such as GDPR, user onboarding and decommissioning, and credential storage are handled in a single place.
The following example shows one possible migration of user attributes to the identity data for existing users. Avoid migrating volatile fine-grained business permissions that change often. These are best stored in the business data to help ensure that APIs and the authorization server can be deployed independently.
Also, design for future users. The authorization server will provide out-of-the-box options to manage self-sign-up. One basic option is to enable users to populate a form and then provide proof of ownership of an email address.
More generally, the process is to authenticate the user and then create a user account record. In some use cases, an administrator may need to pre-provision users. This can also be automated using the authorization server’s user management APIs.
6. Design Access Tokens
Before implementing API security, design the payload of access tokens for one of more APIs. This should use scopes and claims to lock down the token. In the following example, a scope of “sales” is used to restrict the access token privileges to those for a sales context. It should also be possible to issue user attributes from any data source as access token claims.
Design access tokens in a scalable way. Keep scopes fairly high level so that they work for multiple APIs. This “access token contract” should remain stable. In systems that use many fine-grained permissions, avoid issuing all of them to access tokens to eliminate the need for access token versioning.
In some older architectures, a user would log in to a large application and a cookie would be used across many business areas. A leaked message credential had the user’s full privileges. OAuth instead promotes designs where the scope of access to APIs is restricted by the business area. Single sign-on is then used to navigate to an app for a different business domain. This design provides better security and helps to ensure more modular codebases that multiple teams can work on.
Finally, JWT access tokens are intended for APIs. Internet clients should instead receive confidential access tokens that do not reveal sensitive data. The preferred way to achieve this is to use the phantom token pattern, where an API gateway receives confidential tokens and then forwards JWT access tokens to APIs.
7. Design User Experiences
Password-based logins used to be the mainstream option, yet they have many security weaknesses and a poor user login experience. Modern alternatives such as passkeys will soon become the norm, combining strong cryptography with a simple user experience. Passkeys can also use the same account recovery options that password logins use.
The authorization server enables you to offer users multiple ways to log in. This lets you present additional options to users, such as logins with external identity providers or digital wallets. When required, you should be able to implement bespoke authentication methods and screens using the authorization server’s SDK.
When changing a user’s authentication method, it is essential that APIs continue to receive the existing user identity in access tokens so that business data is updated correctly. The process of always resolving logins to the same user account is called account linking and is another feature provided by the authorization server.
8. Choose Security Components
At a minimum, an organization needs to choose an API gateway, an authorization server, and APIs need to use a JWT library. But not all authorization servers have the same capabilities. It is common to get started and then find that you cannot issue the correct access tokens or that a particular type of authentication has reliability issues.
In the early days of your IAM journey, you should focus on portable implementations to keep your organization’s identity options open. Choose an authorization server based on your designs. Using portable code lets you switch to an improved authorization server later without invalidating any design or coding work already completed.
Another essential design factor should be the portability and capabilities of your backend hosting. Cloud native platforms such as Kubernetes provide leading-edge infrastructure security that can be combined with OAuth to further protect data. A popular deployment for optimized performance is to run a containerized authorization server next to containerized APIs.
Finally, ensure that your IAM solution and general architecture can scale to multiple regions. In some industries, you may need to meet regulations where user transactions are stored in the user’s home region. The IAM design should help to enable this. One option is to include a region claim in access tokens to allow an API gateway to reliably route API requests to the user’s region.
9. Review Implementations
To integrate OAuth, one helpful approach is to choose a couple of strong developers to create a demo app and demo API. These are easy to change without introducing risks into flagship apps. Later, they can serve as reference implementations for other teams.
At its heart, the OAuth implementation code for APIs and frontend clients is very simple. APIs use a JWT validation library to verify access tokens, after which APIs implement authorization using the claims in the access token. Clients run a code flow to redirect to the authorization server, where the user authenticates. In both cases, only a small amount of code is needed.
The technical lead should review technical choices to ensure that they are portable. Avoid using nonstandard flows offered by some authorization server providers. Also avoid vendor lock-in, where libraries are used that only work for one particular authorization server. If API or web security frameworks are adopted, ensure they support the OAuth standards you will use.
Developers must also follow separate best practices for APIs, web apps and mobile apps. For example, security experts recommend that browser-based apps use the latest, strongest cookies as API message credentials, rather than making access tokens available to JavaScript. Developers should run a secure local setup that follows these practices so that security is widely understood and any reliability issues are ironed out.
Some work is needed to ensure productive development setups so business delivery is not impeded. Setups where developers run a single “component under development” usually works best. For example, API developers can test with mock access tokens, or web developers can run just a frontend app whose cookies are issued by deployed token-handler APIs.
10. Review Operational Quality
Although the basics of OAuth integration are straightforward, it is also a highly distributed architecture. Developers must work with OAuth protocol messages, including error responses. Implementations must use solid error handling and logging so that apps deal resiliently with expiry and misconfiguration.
Also, consider visibility and control. Compliance stakeholders may want to see audited identity events, which the authorization server should publish. Furthermore, design auditing of API access for especially sensitive data. In some setups, an entitlement management system can enable additional security behaviors, such as changing authorization behavior at runtime.
The authorization server must also be managed at multiple stages of the organization’s deployment pipeline, such as dev, staging and production. This includes upgrades with new configuration settings and troubleshooting of any production incidents. Planning for fast problem resolution is essential since the authorization server is a critical component.
Summary
Identity and access management is an architectural topic based on the separation of concerns philosophy. A robust IAM strategy requires design thinking and solid engineering. These ingredients will help enable a modern, scalable architecture. A token-based architecture enables many types of current and future secured connections, which benefits the business.
Start with designs, and then choose and deploy security components. Avoid committing to vendor solutions yet. Then, plan tasks and follow an iterative approach to implement your IAM strategy. As you integrate, review results and ensure that your technical choices are meeting your business requirements.
At Curity, we produce many standards-based identity resources for organizations. When designing your IAM strategy, you can read our online resources to learn about security design patterns, regardless of which IAM solution provider you choose.
