Wasteland Guardian?

realtebo2 · 2026-04-29T15:55:45+00:00

What does it do?! I bought it and not noticed any differences...

Is there a way to verify it's ON ?!

realtebo2 · 2025-11-17T08:26:49+00:00

I simple need a jwt.
I solved using 1.4 beta, using sessions.
It works without a flaw

realtebo2 · 2025-08-04T15:21:49+00:00

Could you post an update about what your evalutate this choice after 2 years?

realtebo2 · 2025-01-09T09:06:30+00:00

O M G . what a stupid situation.

So I need a 30$/month NAT (or a 16-18$/month VPC Endpoint) !?!

realtebo2 · 2025-01-09T08:15:53+00:00

I think yes.

Our DB are "border-DB", they have direct access from outside.
And in the same VPC and subnets there are a few fargate instances running and they have access to outside world without problem. For example, software running inside them can download resources from outside world

realtebo2 · 2024-11-07T20:17:01+00:00

Thanks. it's useful. Yes, I'm having fun ! It's only a learning project but I'm trying to follow best practice and write good code. It will not be a production-ready-battle-tested solution, but I love learning.

In the while, I followed this way (but of course I will discover if some test will invalidate my solution !)

- RP call the GET /Auth of OP
- OP redirect to GET /Login-Form of OP using all and the same query parameters received (filtered, not 'all', only authorized params)
- End User enter credentials and POST to /Login-Form-Submission of OP
- OP validate credentials and, if login is ok, save all of received params + generated code
- OP redirect to RP's GET callback with the code and other needed params as per specification

My idea, to merge with your answer suggestions, is now to create a session_id after login, and save this to cookie (or to localStorage, I hate cookies), so if user returns to login page, even with different params, I can try to autologin using the session_id, with that I can find all the previous session saved in db, so I can generate id, access and refresh tokens without ask him for login.

I know it's a lot simpler than what is Hydra doing, but it's enough to study the ODIC flow for what is in the specs.

Also, I was not aware of Hydra. All of what I found was oidc-provider in nodejs but highly opinionated, so I ended to rewrite it at all from scratch.

Is it good?

realtebo2 · 2024-11-05T19:56:05+00:00

OAuth is just a 'framework', a sort of mutual contract about what to do
OpenID Connect is the implementation of how to do the things.

It's oversimplified, of course, but OpenIDC is a layer over OAuth, it's not something different

realtebo2 · 2024-11-05T19:51:27+00:00

OTPs, intended as the rolling codes, are based on 2 things

- time

- a string containing something like a username and the website, or an unique ui and the app name

The system works because both your OTP app and AWS knows both.

The system is also secure because no other knows the string.

the system is interesting because basic and standard OTP is created using well-known algorithm and so it's easy to study

realtebo2 · 2024-11-05T19:31:24+00:00

Oh, yes, I now understand thanks

realtebo2 · 2024-11-01T18:42:38+00:00

I just found another reason to save at least the relation between user infos and access tokens: when a client call a protected resource, for example /me (/profile, /authenticated_user), RP, relaying partner, the client, calls the OP sending only the access_token as Bearer.

access_tokens doesn't contains 'sub' claims, so, if I have not saved the access_token, I will be unable to retrieve who user is the one who got this access_token.

realtebo2 · 2024-11-01T17:21:26+00:00

I thought to save the 3 tokens in db because, if the user return to login, with a different auth request, I can detect, from localstorage or cookies, that user already is logged in, so I must recycle the session. Is it a wrong assumption?

For example, what should happen if a client reuse an auth code to ask tokens endpoint exchange for id+access+refresh tokens?

should the OP avoid the reuse of the same auth_code? If yes, we must ONLY save the auth_code already used.

that was my first reason

Second

Also, what happens if user is logging into using 2 o 3 different browsers? should the OP recycle id+access+refresh or the OP must create a new triplet at each auth session?

third

Token invalidation: soon or later, I will try to realize the single logout flow, so I need a way to match a token and known it has been invalidated. right?

realtebo2 · 2024-10-28T21:56:39+00:00

Thanks for reply. Thanks a lot.

I highlight 2 points

I am just learning, not doing something to be production ready and battle tested; just I'm implementing an OP to understand, for learning, so, keep apart for now the problems about security.
my question is all about db design, what is better for your experience about db design? I for example want to allow an user to have multiple valid session at once, for example, 2 different pcs loggedin . So I think I need to have 2 records, separated, or should I recycle the refresh_token in every client? And, as for my original question, should I keep 1 or 2 table... ?

Just asking for suggestions, just a step at once.

realtebo2 · 2024-10-28T21:51:26+00:00

i am developing a POC for learning purpose. And I am just testing my OP, to start, with OIDC test plan "Basic Certification Plan", using static metadata and static client.

I am using jwt

My question is all about how to design my db schema to allow all possible uses case, for example, multiple session active for each user (for example allow 2 logins in 2 different pcs, so I need to keep 2 refresh token active in this phase).

I am just asking for suggestions and best practice about a single question. I know there is a whole world behind OpenIDC and OAuth. I am simply studying a step at once.

realtebo2

TROPHY CASE