Secure API Authentication for IBM i: Protecting Your System While Enabling Integration

Our previous security blogs explored how IBM i systems are often isolated from enterprise security architectures and discussed implementing technologies like Okta for Multi-Factor Authentication. Our last blog focused on the vulnerabilities inherent in using Basic Authentication and the reasons to replace Basic Authentication with more modern authentication methods. Today, I want to focus on a critical aspect of IBM i security that’s becoming increasingly important as organizations expand their integration needs: secure authentication specifically for APIs. 

The API Security Imperative

APIs have become essential integration points as IBM i systems become more connected – integrating with web applications, mobile apps, partner systems, and cloud services. However, these same APIs can create significant security vulnerabilities if not properly protected. 

I recently spoke with a customer who had just completed building their first set of APIs for their IBM i system. When I asked about their authentication approach, they explained they used basic authentication with IBM i credentials to authenticate API users. This approach, while common, creates serious security risks. 

The Problem with Basic Authentication for APIs (Review from our previous blog)

Basic authentication, where API calls include IBM i credentials in every request, presents several critical vulnerabilities: 

1. Credential Exposure: IBM i credentials are sent with every API call. Even when using HTTPS, these credentials are still transmitted repeatedly, increasing the risk of exposure. 
2. Credential Proliferation: Any application using these APIs must store IBM i credentials somewhere. These credentials often end up stored in plain text in configuration files, application code, or credential stores outside your control. 
3. Over-privileged Access: Many organizations grant these API credentials excessive system authorities to make development easier. I’ve seen numerous cases where credentials with *ALLOBJ authority are floating around on various systems – a significant security risk. 
4. No Granular Control: Basic authentication doesn’t easily allow for limiting what specific API endpoints or operations a client can access. 
5. No Revocation Mechanism: If credentials are compromised, you must change passwords, potentially breaking many integrations simultaneously. 

Modern API Authentication for IBM i

Fortunately, there are better approaches to securing your IBM i APIs. Let’s explore the most effective methods:

Token-Based Authentication

Token-based authentication addresses many of the limitations of basic authentication. Instead of sending credentials with every request, the client authenticates once and receives a temporary token that grants specific access permissions. 

Key benefits include: 

• Tokens have limited lifespans, minimizing the window of vulnerability 
• Tokens can be easily revoked without changing underlying credentials 
• Tokens can carry specific permissions and limitations 
• Native IBM i user credentials are never stored on client systems

Implementing token-based authentication for IBM i APIs requires a secure token generation and validation system. Eradani Connect simplifies this by providing built-in support for industry-standard token generation, validation, and management. 

API Keys with Rate Limiting

For machine-to-machine communications, API keys provide a valuable and safe authentication mechanism. Unlike tokens that expire quickly, API keys are long-lived credentials specifically created for API access. 

When implementing API keys, make sure to: 

• Generate cryptographically secure random keys 
• Implement rate limiting to prevent abuse 
• Enable quick revocation and rotation of keys 
• Log all API key usage for audit purposes 
• Store keys securely using proper encryption 

A well-implemented API key system also allows you to monitor for unusual patterns of activity and automatically throttle or block suspicious requests. 

OAuth 2.0 Integration

OAuth 2.0 has become the industry standard for the most robust API security. It provides a framework for authorization that separates the authentication process from the API access itself. 

With OAuth: 

• Users authenticate with an identity provider they already trust 
• Your API receives tokens that verify the user’s identity and permissions 
• No credentials are ever shared directly with API clients 
• Permissions can be highly granular and easily audited 

While OAuth implementation is more complex than simpler authentication methods, it provides significant security benefits and aligns with enterprise identity management strategies. 

Implementation Considerations

When implementing secure API authentication for IBM i, consider these key factors: 

1. Transport Layer Security: Before focusing on authentication methods, ensure proper transport security is in place. All API communications should use HTTPS with modern TLS protocols (TLS 1.2 or higher) and secure cipher suites. 

2. Token Storage and Management: If implementing token-based authentication, carefully consider how tokens are stored and managed. Tokens should:
   • Be stored in memory rather than persistent storage 
   • Include appropriate expiration times 
   • Contain only necessary information 
   • Be validated on every request
3. Authorization Implementation: Authentication (verifying identity) is only half the equation – you also need authorization (controlling what authenticated users can do). Implement proper authorization checks within your API layer to enforce access controls based on the following:
   • User identity and roles 
   • API endpoint accessed 
   • Operation performed 
   • Time of day or other contextual factors
4. Monitoring and Logging: Implement comprehensive logging of all API authentication activities. This should include:
   • Authentication attempts (successful and failed) 
   • Token issuance and validation 
   • API key usage 
   • Authorization decisions

These logs should integrate with your enterprise security monitoring systems for visibility and alerting. 

Real-World Implementation Example

One of our manufacturing customers recently transitioned from basic to token-based authentication for their IBM i APIs. They integrated their IBM i inventory system with their e-commerce platform and initially implemented basic authentication with IBM i credentials. 

After reviewing their security architecture, we identified the risks in their approach and helped them implement a token-based solution with Eradani Connect. The implementation: 

1. Created a secure token service for generating and validating JWTs (JSON Web Tokens) 
2. Modified their API gateway to validate tokens instead of checking credentials directly 
3. Implemented proper token lifecycle management with appropriate expiration times 
4. Added comprehensive logging of all authentication and authorization decisions 
5. Connected this logging to their enterprise SIEM (Security Information and Event Management) system

The result was a significantly more secure integration architecture with better visibility and control, all without any changes to their core IBM i applications.