Jeff Lombardo

Hi, There is also a problem in the provider URL. When constructed, the OpenID Connect configuration ask for the base provider URL to which it automatically add the /.well-known/openid-configuration suffix....

yes in fact, when constructed, the OpenID Connect configuration ask for the base provider URL to which it automatically add the /.well-known/openid-configuration suffix. Then the $wellKnown value is loaded with...

it works but the correct command is: `apk add --no-cache bash` There was a typo in @warthur1214 suggestion cause of two add

+1 on he remark here. Especially with the `reason` having `id`. It sounds like it should be `reasons` as JSON array of multiple `reason` pointing to the element to evaluate...

You should not encourage people to run their own cryptography.

Like you said yourself this guide is about explaining and implementing OAuth2/OIDC only. There are plenty of guides for the equivalent on the cryptographic front. By adding your own section...

`id` would have a sense if it relates to a specific `evaluation` but as JSON array preserves the order of the item, does it help to have a required `id`...

The OpenID Foundation lists certified Libraries. It is sad that you limit yourself to own implementation... using certified libraries still requires configuration and architecture to make it a production grade...

As provided through the link: - Copenhagen book set password policy guidance is: > Passwords must be at least 8 characters long. Do not set the maximum password length too...

MFA is good fallback (augment friction if assurance in transaction decrease). Now the core function should be around analytics of Authentication events.