Why Secure Authentication Matters in Progress OpenEdge?

2025 05 02 · 11 min read

Enterprise-grade applications require more than just functionality – they demand robust user authentication to safeguard access and ensure data integrity.

This document provides a walkthrough of implementing a secure login and registration system using Progress OpenEdge. Get to know practical techniques like environment-based configuration, hashed passwords and JWT tokens.

Project Objectives

The following objectives define the core components implemented to build a secure and scalable user authentication system in a Progress OpenEdge application.

Progress OpenEdge Module’s Key Elements

To meet modern security standards, a full-featured authentication module built in Progress OpenEdge wasdesigned to securely manage user registration and login.

The implementation incorporates the following key elements:

Environment Variables

For robust security and adaptable configurations, this project employs environment variables managed through .env files. Environment variables are fundamental for defining the application’s runtime environment (development, production, etc.). By storing sensitive data like passwords, API credentials, and JWT secret keys in .env files, we prevent direct exposure within the code. This approach is critical for maintaining security across different deployment environments and ensures that configuration details are easily adjustable without modifying the application’s source.

Why JWT?

JSON Web Tokens provide a stateless authentication mechanism perfect for distributed systems.

Key benefits:

Key security features:

Processes in Diagrams

Registration Process

Login Process

Diagrams illustrate the main objectives and flow of the User Registration/Login feature.

Sequence of actions:

Implementation Challenges in Progress OpenEdge Authentication

Building a secure authentication system in Progress OpenEdge presents several technical and practical challenges, from cryptographic implementation to library limitations and error handling.

Impact and Benefits of the Authentication Implementation

Implementing this feature enhances both the security and usability of the authentication flow in the Progress OpenEdge application.

Main outcomes:

Core Security Components

1. Password Security

Salting & Hashing Flow

User Password → Get Salt From environment variables → SHA-256 Hash → Store (Hash)

PasswordHash

2. Password Validation

This method securely verifies a user-suplied password against a stored hash using SHA-256 and a salt retrieved from an environment variable.

MatchPassword

3. JWT Generation

Token Creation

This method (login) authenticates a user, generates a JSON Web Token (JWT) with user details and a 2-hour expiration, and returns the token which is later set within cookie. It uses a secret key from an environment variable for signing.

login method

Using values from JWT payload

This ABL code snippet demonstrates how to parse and validate a JSON Web Token (JWT) using the third-party library. It retrieves claims (data) from the validated token and displays them. It also includes error handling for invalid tokens.

JWT payload Expand source

4. Environment Variable Security

It is crucial to recognise that the .env file contains highly sensitive data, including API keys, database credentials, and cryptographic secrets.

Under no circumstances should this file be uploaded to any online repository or shared publicly.

Sample .env

Environment variables

Retrieving Environment Variables in ABL

OS-GETENV()

Key Code Snippets

1. Format Response

This ABL method (FormatResponse) streamlines HTTP response creation: it builds a JSON response with a given status code and body, optionally adds a JWT cookie, and writes the response, reducing boilerplate code.

Important to mention:

HttpOnly: This prevents client-side JavaScript from accessing the cookie. This mitigates the risk of cross-site scripting attacks, where malicious scripts could steal the cookie and compromise the user’s session.

SecureOnly: This ensures the cookie is only sent over HTTPS connections. This prevents the cookie and the JWT it holds from being intercepted by attackers on insecure networks.

FormatResponse()

2. Registration Handler

This ABL method handles user registration: it parses JSON, creates an account, and returns an HTTP response (201 for success, 400 or 500 for errors).

HandleRegister()

Imitating registration Front-end with Postman:

It is important to note that plain text passwords are being sent in this request. Therefore, HTTPS must be used to encrypt the data and prevent credential exposure during transit.

No email provided error handling ex.:

3. Login Handler

This ABL method handles user login: it parses JSON credentials, authenticates, generates a JWT, and returns an HTTP response (200 with token, 401 or 500 on errors).

HandleLogin()

Imitating login Front-end with Postman:

It is important to note that plain text passwords are being sent in this request. Therefore, HTTPS must be used to encrypt the data and prevent credential exposure during transit.

User not found error handling ex.:

4. Creating Account

This method creates new Account records from a ttAccount temp-table, assigning a unique ID and transferring data.

createAccount()

JWT Authorisation & Access Control

This utility class handles JWT-based authentication.

It reads the token from the request cookie, verifies its signature and expiration using the JwtParser class, and returns the decoded user claims.

JwtGuard()

If the token is missing, invalid, or expired, it throws an AppError, which results in an Unauthorized (401) response. This effectively determines whether a user is logged in.

JwtValidation

Once the claims are returned, role-based access control can easily be applied. For example, to allow access only for admins:

Role validation

This makes JwtGuard a clean and centralised way to both authenticate users and enforce role permissions across protected endpoints.

To log out we simply clear out the Cookie by setting its expiration to zero:

Log out

Authentication Flow in Action

1. Logging In as a Regular User

The user logs in with valid credentials but has a non-admin role (e.g., “role”: “user”). A JWT token is returned and saved in a cookie.

2. Attempting To Access /account as a Regular User

This protected endpoint is restricted to admin users. When the non-admin user tries to access it, the server checks the JWT claims and responds with:

3. Logging In as an Admin

The user logs in again, this time with admin credentials. A new JWT token is issued and stored in the cookie.

4. Accessing /account as an Admin

This time the JWT contains the correct admin role. The request is allowed and the server responds with a list of accounts.

5. Logging Out

The user sends a request to the /logout endpoint, which clears the cookie by setting it with an expired timestamp.

6. Attempting to Access /account After Logout

Since the JWT is now expired or missing, the next request to /account is rejected.

Need help implementing secure authentication in your OpenEdge application?
The Progress OpenEdge team is here to support you – whether you are planning a new architecture, modernising legacy logic, or integrating authentication with external systems. Contact us today to get expert guidance tailored to your goals.