Securing IBM i APIs: Moving Beyond Basic Authentication

Last month, I had an eye-opening conversation with a development team lead who was in the final stages of completing a several months long project building his company’s first APIs for their IBM i. They were struggling with a few final bugs and some performance issues but he told me that their biggest concern was security. “We’re using basic authentication with IBM i credentials to authenticate API users” he said. “Doesn’t that leave us exposed?”   

Unfortunately, this is a conversation I’m having more and more frequently – and the answer is YES, you are exposed. As organizations move to leverage the power of API-enabling their IBM i systems, many are unknowingly implementing security practices that could leave their critical systems vulnerable. Basic authentication, while seemingly straightforward, creates significant security risks that could compromise your entire IBM i environment.  

The Hidden Dangers of Basic Authentication  

When you implement basic authentication for your APIs, you’re essentially sending IBM i credentials with every API call. This technique allows you to take advantage of the built-in security functions of the IBM i (private authorities, authorization lists, menu security, etc.) However, it also means that you are constantly sending native credentials to your IBM i across the wire. If you are providing access to your customers and partners, it means that those users are storing native credentials to your IBM i outside of your network in places over which you have no control. Even if you limit this access to your local network, there will be IBM i credentials stored on a variety of Windows and/or Linux servers that could be exposed if a machine on your network gets compromised. 

Some IBM i users are sending these credentials as base64 encoded messages, confusing base64 encoding with encryption. At rest, those credentials often end up stored in plain text in various locations across your network – in configuration files, application code, or even spreadsheets used to track API access.  

That means that native IBM i credentials – possibly with powerful system authorities – are now scattered across various systems outside your IBM i environment. And in many cases, these aren’t just any credentials. As one customer recently confessed, “We started with limited authority, but users kept needing more access. Eventually, we just gave them *ALLOBJ authority to make things easier.”  

Why IBM i API Security Often Relies on Basic Authentication  

There are several reasons organizations end up using basic authentication:  

1. It’s the default option in many native IBM i API tools  
2. It’s relatively simple to implement  
3. It leverages existing IBM i security infrastructure  
4. Development teams are under pressure to deliver APIs quickly  

While these reasons are understandable, they don’t justify the security risks. Your IBM i hosts your most critical business applications and data. Its security deserves better than “good enough.”  

Modern IBM i API Security Alternative 

The good news is that implementing robust API security doesn’t have to be complex. Modern authentication approaches provide significantly better security while actually improving the developer and user experience. Here are key approaches to consider:  

Token-Based Authentication  

Instead of sending IBM i native credentials with every request, modern APIs use encrypted tokens. These tokens:  

• Are encrypted so even if they are intercepted, they cannot be read 

• Can be quickly revoked if compromised  

• Can time-out 

• Provide very granular control over access permissions  

• Don’t expose system credentials  

• Can be automatically refreshed 

• Can be mapped to IBM i credentials  

OAuth 2.0 Integration  

OAuth 2.0 has become the industry standard for API authorization, and for good reason. It provides:  

• Separation of authentication and authorization  

• Integration with enterprise identity providers  

• No exposure of credentials to client applications 

• Third party verification of a user’s identity  

For example, if you wanted to integrate your IBM i data with your Salesforce application, you might use OAuth2 to allow the user to access your data using their Salesforce credentials. They would sign into Salesforce, Salesforce would provide them with an access token that would be sent to your application verifying who the user was. The access token could also identify what information to which the user should have access. 

API Keys with Rate Limiting  

For machine-to-machine communications, API keys combined with rate limiting can provide:  

• Trackable access per application  

• Protection against Distributed Denial of Service attacks (DDoS) 

• Notification of spikes in API use (including spikes due to poorly written API calls) 

• Throttling of API traffic 

• Simplified key rotation  

• Usage monitoring and analytics  

Making the Transition  

Moving beyond basic authentication doesn’t have to happen all at once. Here’s a practical approach we’ve used successfully with many customers:  

1. Start by implementing secure tokens for new APIs  
2. Gradually migrate existing APIs to modern authentication  
3. Implement monitoring and logging for all API access  
4. Establish key rotation and management procedures  

One manufacturing customer recently followed this exact approach. “We were nervous about changing our authentication method,” their lead developer told me. “But once we made the switch, we wondered why we hadn’t done it sooner. Our APIs are more secure, and our developers actually prefer working with tokens over managing credentials.”  

The Path Forward  

As APIs become increasingly critical to business operations, their security cannot be an afterthought. Basic authentication, while familiar, simply doesn’t provide the protection your IBM i systems need in today’s threat landscape.  

Consider these questions about your current API security:  

• Are you transmitting IBM i credentials across your network?  

• Do you have clear visibility into who is accessing your APIs?  

• Can you quickly revoke access if needed?  

• Can you control exactly what resources an API user can access? 

• Can you support the access methods required by your customers and business partners? 

• Are you meeting industry security standards?  

If you’re still using basic authentication, now is the time to plan your transition to modern API security. Your IBM i applications are too valuable to risk with outdated security practices.  

Want to learn more about securing your IBM i APIs? Contact our team at Eradani to discuss implementing modern API security that protects your critical systems while enabling seamless enterprise integration.