This blog presents an integration topic from a project manager’s viewpoint: application level security and access. Are you managing integration projects? Were you ever mixed up in technical jargon that only a few specialists understand? Did you file tickets at various suppliers, which in the end bounced back to you? Then this blog may help you.
In this blog, you will find more information on application level security and access. A better understanding will help you to maintain overview, needed to drive a complex issue to a solution. Notions may be simplified here. Practical challenges are given. If you care, a lot more detail is available on the Internet.
Application level security and authentication for access
In a previous blog, (physical) connectivity was elaborated, notably: encrypted site-to-site VPN (on ‘transport level’). Reference was made that end-to-end authentication needs to be enforced on top of it, i.e. on application level. Also, reference was made of mutual TLS, as an alternative to the more permanent site-to-site VPN. Mutual TLS provides end-to-end authentication for access, as well as encryption.
Security
Integrations & API’s often convey sensitive information, when data-in-transit must be secured. This is where encryption comes in. The standard encryption protocol in use is TLS, historically known as SSL/TLS. TLS creates an encrypted communication channel, based on certificates. On application level, TLS implements encryption ‘end-to-end’, regardless of underlying physical connectivity (either secure or insecure). Double encryption however, both on transport level and on application level, is not uncommon. Needless to say, double encryption is harder to crack. The responsible security officer determines the required safety measures for the application at hand.
TLS encryption is also used by HTTPS, as an extension to the HTTP-protocol.
Authentication
Authentication is vital for integrations and API’s. Firstly, the application that exposes data needs to be authenticated, to avoid the calling application being fed with unintended or even malicious data. Secondly, the calling application may need to be authenticated as well, to avoid that any data ends up in the wrong place.
Access
Authentication for access can be realized in various ways.
- Basic Authentication is the simplest technique to access web resources. It provides a user name and password in conjunction with an HTTP-request. Base64 encoding applies, which is not providing sufficient confidentiality, like encryption or hashing does. Hence, Basic Authentication is typically used together with HTTPS. Please note: many security officers do not accept Basic Authentication and HTTPS for sensitive integrations.
- Secondly, applications can be authenticated through TLS certificates, used in connection with one-way TLS (for server authentication only) or mutual TLS (for client and server authentication, normally between 2 known parties).
Please note: one-way TLS is typically used for a client (laptop) to connect with a web server (website), part of the HTTPS protocol, to assure the client that the website is not a fake. - The classic way to authenticate a calling application is by user credentials. A vulnerable method on its own, but the vulnerability can be reduced by adding a token mechanism.
Tokens are not elaborated here, but will be covered by a subsequent blog (on authorization, OIDC, OAUTH, JWT). In the end, a short-lived access token is provided to the calling application, after validation according to the presented Client Id and Client Secret.
Authorization
Authentication is closely related to authorization. API’s may grant different rights to different applications, once properly authenticated. Authorization is a subject in itself.
Practical cases
What situations might occur in practice?
- Organizational.
When implementing TLS, take care to assign responsibilities on both sides: who is the data owner, normally responsible to request a certificate (CRT) with the Certificate Authority (CA); who needs to contribute to make a certificate request (CSR); who installs a (re)new(ed) certificate; what coordination between the two parties is in place?
If one side does not act, communication will fail.
- Design.
The architect and security officer decide on how to authenticate, either by Basic Authentication, through TLS, by token, or by (API) keys. It is important that both sides use compatible TLS versions: at least TLS 1.2 or higher, or preferably TLS 1.3. Older applications may not support beyond TLS 1.0 or TLS 1.1, whereas newer applications may require at least TLS 1.2.
Verify the design with the security officer before starting implementation.
- Realization.
Expect throughput time (weeks easily), due to alignment of separate tasks and possible issues along the way.
While implementing VPN, the need for connectivity on TEST environments may be felt, not to block integration development. Consider temporary shortcut solutions over the Internet, e.g. by using access credentials and whitelisting of the calling IP-address.
- Operations.
Assign responsibility for monitoring the expiry of TLS certificates and for timely renewal. Support organisations of both parties must be informed how to act.
- Challenges.
Specialists know how to perform separate tasks, but may lack overview. Documented working procedures avoid dependency on individuals. The use of certificates comes with a maintenance burden. That’s one reason to implement tokens, because they cater for automatic renewal.
Summary
Application level security and authentication for access are key to successful integrations. The technology is well known, but you may encounter challenges. This blog provides an overview, to assist you in overcoming such challenges. In due course, related topics will be covered by subsequent blogs.
CTA
Want to dive deeper into application-level security, token-based authentication, or authorization models like OAuth and OIDC?
Reach out to our integration experts directly at to discuss your specific integration challenges.
