Patrik,
I'm not going to spend a lot of time arguing on the topic. Basic Auth is widely considered insecure and is not advised. OAuth 2.0 is generally considered the industry standard at this time. Simple googling will return the same answers.
Also, you mention browsers and no need to create HTML forms for login, but the OP was talking about APIs, not HTML pages. So, it is safe to assume this will be called as part of a remote process, or by another existing web application that has some sort of login form already.
Brian May
Profound Logic Software
Global Customer Lifecycle Principal
http://www.profoundlogic.com<
http://www.profoundlogic.com/>
<
http://www.profoundlogic.com/>
937-439-7925 Phone
877-224-7768 Toll Free
[Profound Logic Logo]
________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Patrik Schindler <poc@xxxxxxxxxx>
Sent: Saturday, April 12, 2025 5:45 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Different approaches to expose RPG program outside of ibmi
Caution: This email originated from an external source. Please do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Brian,
Am 11.04.2025 um 21:07 schrieb Brian May <bmay@xxxxxxxxxxxxxxxxx>:
Glad to provide a few without going deep into the weeds on a Friday afternoon.
Thanks!
1.
Basic HTTP Authentication sends usernames and passwords in plain text. This makes them inherently insecure and susceptible to interception or eavesdropping. Even when HTTPS is used, which many IBM i shops that are new to APIs don't, the fact that the credentials themselves aren't encrypted means that if the HTTPS encryption is broken the credentials are compromised.
Https is standard for quite a while. Sending credentials as POST is likewise "insecure". A very weak argument against basic auth.
How many conversations to we have on the midrange list about people running old TLS versions?
I'm aware. But, how many of them relate to reenable them to regain compatibility? How many of them revolved around the possibility that an actual attack was staged because of old crypto?
Don't get me wrong, I don't intent to advocate outdated crypto. Just making a point here. And, how is this related to basic auth?
2.
Basic Auth does not have a means of revocation or expiration.
For the client side, authentication is discarded, once the browser (window?) is closed. I admit, I have not yet taken time to learn the background. With my current understanding, the worst what can happen is that a user can't be "forced out" unless he closes his browser window.
On the server side, you can't do much about it. With self-made methods of authentication (Cookies), you can have them expire after a given time, to force re-authentication. Not very user-friendly, IMHO. You could force an immediate re-authentication by invalidating the server side idea of the user's cookie.
In practice, I'm not sure how much said points matter. The OP was asking about exposing something to an external user. So it's not an automatism, but a human on the other end, facing a browser window. Browsers can save credentials and users opt do to so, I presume. No matter if basic auth or something else.
In most cases, usernames and passwords are created and never changed due to the hassle of changing things on the consumer and provider sides. This means if they are compromised, a bad actor could have access to the system for long periods of time before being caught.
3.
Most consumers of APIs that use Basic Auth store the passwords in plain text on their systems, exposing your system to being compromised.
Again, this is not something inherent to basic auth but how it's implemented on the server side. If you apply the same logic of saving credentials in a rarely touched/remembered plain text file and use this with a HTML form presenting username and password to the user, you're facing the same issues.
On the plus side, authentication presentation to the user with basic auth is handled by the browser. No need to develop HTML versions of "enter username/password", or fiddle with cookies. Easier to implement, albeit less flexible in terms of "slamming the door".
All in all I fail to recognize your proposed inferiority of basic auth, compared to something you didn't even elaborate on.
:wq! PoC
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
