× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



To be honest, I feel the post below actually makes my point rather better that I have been able to - I mean talk about over engineered! It literally says it's non-trivial to implement a token refresh mechanism, which is mostly only there because stateless tokens can't be revoked. Part I also cites the only real benefit of JWTs is scaleability, but at the kind of scales we're dealing with, a database lookup of a token is trivially insignificant. It then goes on to talk about refresh tokens and access tokens being stored in a database, which means it's no longer stateless anyway. So, you'd end up with having to implement JWTs, over which you'd then have to add a layer of encryption to give you secure JWTs (which is itself non-trivial) then on top of that you have to come up with a convoluted token refresh system (or give up and use a third-party library). What benefit does all this give you over using a simple stateful solution where you store opaque tokens on the server? In fact, such opaque tokens have all the benefits of JWTs (including limited lifetime if required) yet can be immediately revoked if compromised and invalidated when a user signs off.

Unless you require interoperability with other systems, the only potential benefits I see of JWTs are perhaps federated login, where you need to validate a token generated elsewhere, or where you are scaling to the size where you truly need a stateless solution for performance reasons and the additional engineering required to overcome the downsides of being stateless and clear-text makes sense.

When I looked at JWTs I fell for the hype initially and went so far as to implement them, but I came to the conclusion that if you're developing a standalone web app, and it's not going to be scaling to the heights of Facebook and Zoom, then JWTs have no benefit at all and only downsides. I ended up generating secure random opaque tokens and storing them in a file on the server.



________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Charles Wilt <charles.wilt@xxxxxxxxx>
Sent: 20 April 2021 22:53
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: JWT (was: Upcoming Spring 2021 RPG enhancements)

Useful reading (this is part 2, can skip part 1 if you have a basic
understanding of JWT and user sessions)
https://supertokens.io/blog/the-best-way-to-securely-manage-user-sessions

<tl:dr>
Rotating refresh tokens with short-lived access tokens
- Access tokens are short-lived and refresh tokens are long-lived.
- When a new refresh token is obtained, the old refresh and access tokens
are invalidated on the backend and removed from the frontend. Doing this
properly is not straightforward. Please see “Notes for Implementation”,
discussed later.
- If the user voluntarily logs out, the access and refresh tokens are
revoked and cleared from the frontend.

Charles


On Tue, Apr 20, 2021 at 3:11 PM Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

Tim,

Not sure why you think they can't be invalidated...

Every JWT should have an expires tag with a limited lifetime..

Charles

On Tue, Apr 20, 2021 at 2:38 PM Tim Fathers <tim@xxxxxxxxxxxxx> wrote:

I know what they are, in fact I even wrote a MariaDB implementation of
them, but I decided against using them in my app for the reasons I mention
in my reply to Jon, namely, they cannot be invalidated. I get that the
federated identity might be useful, but I don't think applications of the
kind of scale we would run on an IBM i generally warrant the need for a
stateless solution, especially not at the expense of not being able to
invalidate tokens that might be being abused.

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of
Charles Wilt <charles.wilt@xxxxxxxxx>
Sent: Tuesday, April 20, 2021 5:37:26 PM
To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: JWT (was: Upcoming Spring 2021 RPG enhancements)

On Tue, Apr 20, 2021 at 9:35 AM Tim Fathers <tim@xxxxxxxxxxxxx> wrote:

I'm curious as to why you'd want to use JWTs (unless you're having to
consume them somehow), their use case seems to be fairly limited and not
particularly suitable to systems of our scale.


Huh? I don't understand where you'd get that idea.

JSON Web Tokens (JWT) are an open, industry standard RFC 7519 method for
representing claims securely between two parties.

The rest of the world uses JWTs to among other things secure the APIs they
are building. The API is one side and the other is your selected identity
provider.

While nodejs web-services on the i could validate them, IWS or other RPG
ones currently can not.

Charles
--
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.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
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.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


--
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.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.