nginx: [emerg] unknown “tls1_3_early_data” variable

If you’re getting this error message doing nginx -t or otherwise,
for instance if you’re copy/pasting Mattermost’s nginx configuration,
know that the line is

instead of

I’m not sure but I’m guessing nginx developers renamed that variable, I’m just not sure when that happened. $tls1_3_early_data must have worked some time ago, but on my nginx version it doesn’t and I have to use the $ssl_early_data variable.

see also
nginx ssl early data
mattermost’s nginx configuration

Keycloak Client Passwords are insecure by default

And the maintainers refuse to change that, responding with bureaucratic measures and general ignorance.

When you have an UUID string, example “192c1916-de80-4003-a01b-b2eaf97a1721” first of all those aren’t 128 bits.
You have a representation of those 128 bits and a very limited set of characters 0123456789abcdef, so you represent those 128 bits in only 16 characters of 256 possible, effectively reducing the bit-“strength” to 128/(256/16)=8 bits. And of course you know how many characters 8 bits are, exactly 1.

So now you have 32 characters that can only have the state of [0-9a-f] each. How long does it take to brute force 32 characters with 16 possible values per character?

Keycloak client passwords are insecure by default and that maybe be because of laziness, which I first assumed, stupidity, which is quite common or by design.

Vue and Keycloak do not have a proper JS client that works with mobile native

There are currently 2 packages to integrate keycloak-js with your Vue 3 WEB app.

https://github.com/dsb-norge/vue-keycloak-js
and
https://github.com/baloise/vue-keycloak

But each have their quirks and issues.

If you want to use keycloak in a native app, none of these work.
There is keycloak-ionic and someone created a repo https://github.com/marchalb/qkeycloak to showcase a modified version of dsb-norge/vue-keycloak-js and keycloak-ionic, but that also isn’t working.

So the current state for OIDC client apps is: NOT FUNCTIONAL

OIDC fails the K.I.S.S. principle. It is so complicated that no one has managed to write something that works for every scenario.
Mobile and Web are some very common scenarios, why is there nothing that provides this functionality?

I think it’s better to abandon OIDC, since all that’s left are commercial offerings and the open source ones don’t work properly,
and write your own auth package, which may not be as sophisticated but at least it will work for you and your needs and you know what it’s doing.

Golang get openid-connect userinfo

It might not be news to you, but this will explain a little bit about Go, making http requests and parsing the result.

OpenID-Connect (oidc) is an identity protocol, you could call it an Oauth2 dialect. It manages your users per realm, well not the protocol but the server does.
Every oidc idp (identity provider aka server) should support the oidc discovery feature.
What is a good OIDC IDP? Keycloak for instance, because it’s free.
Essentially it’s a well known URI that provides information about this IDP or this IDP’s realm in JSON.
The “.well-known/openid-configuration” is appended to the IDP.
To see a live one you could navigate to https://connect.icod.de/auth/realms/testrealm/.well-known/openid-configuration

It lists all the endpoints this server handles and supported grant types and much much more.

I’ve been working with websockets lately and faced the challenge that websockets don’t support passing HTTP headers,
so I had to log in with the token my frontend received by the IDP. And for security reasons this had to be the raw token, not the parsed subject field, because it’s not cryptographically protected.
This means I had to ask the IDP if the token I had received was valid and extract the subject from it.

The below code is the 1st version of how I did it.
It queries the openid-connect discovery document, since the structure was unknown to me, I decoded the response body from the request into a map[string]interface{}.
However in retrospect, I could’ve defined a struct with only the single requested variable in it:

Then this userinfo endpoint is queried with the Accesstoken passed as a Bearer token in the Authorization header.
The result is decoded into the UserInfo struct instance and returned by the function.

I use spew, which is a very helpful tool to display the content of the returned variable.