Active Directory has been the dominant standard for IT directories, even if it isn't the prettiest tree in the forrest. It's younger sibling ~~Azure Active Directory~~ Entra ID is a big player in cloud based Identity Providers (IdP). Unsurprisingly it behaves differently than the gold standard KeyCloak

JWT expectations

A Json Web Token (JWT) payload is a very losely definded JSON object with various claims. There is only a minimal consent of properties":

{
  "iss": "https://where-it-came-from",
  "audience": "https://where-it-should-be-valid",
  "iat": "DATE/TIME -> issued at",
  "exp": "DATE/TIME -> expiry",
  "scope": "space separated list of scopes",
  "email": "user's email"
}

The whole thing is (un)defined in RFC7519, sufficiently loose, so anyone can claim to be standard compliant and nothing is interoperable (just like ical). There is a list of known claims, but RFC7519 states: "None of the claims
defined below are intended to be mandatory to use or implement in all
cases, but rather they provide a starting point for a set of useful,
interoperable claims."

To ease validation of signatures, one can use an URL .../.well-known/openid-configuration which provides a number of needed properties:

• various endpoint URLs for authentication and token exchange
• issuer: The value corresponding to the iss property in a JWT
• jwks_uri: URL to read the public key to validate signatures
• scopes_supported: what scopes does the API support

Azure - same but different

When you setup Domino for JWT you need a series of specific conditions. The interesting parts from the documentation:

• One of the JWT's "aud" (audience) claims must match the Domino Internet Site's host name
• JWTs must contain a "iss" (issuer) claim matching the "issuer" returned from the OIDC provider's .well-known/openid-configuration endpoint
• JWTs must contain a "scope" claim that includes "Domino.user.all"

When you follow KEEP's how to configure Azure AD you will find a set of pain points, in no specific order:

• You can't remove claims you don't need
• Azure AD will not issue a scope claim, but an scp claim
• The aud claim is fixed to the "Application ID URI"
• The iss claim in a token does not match the issuer property from well-known/openid-configuration
• The jwks_uri URL does not return an alg property for the algorythm (nor did I find any way to request an Elliptic-curve signer)

So there's tons of fun to be had with Azure ~~Active Directory~~ Entra ID

We use a multitude of applications per day. Each of them captures some level of attention and interaction. Alan Cooper coined the term Application posture, with the mainly used application being the sovereign application. I personally like the term primary posture application better and will use it in this post

Being primany

Since users spend most of their time in it, there's a willingness to become "senior intermediate experts". Shortcuts are learned, workflows get shared and a deeper understanding is desired. Depending on the nature of your work, very different application are your primary

• for a graphic desiger it might be GIMP or Inkscape
• a vlogger spends lot of time in OBS
• The controllers spend their days in spreadsheets
• The sales manager in CRM
• Operations is fond of ERP
• eMail and chat are strong contenders too
• the Scrum master lives in Jira, while developers on the command-line and IDE

Primary posture by association

To cover anything else, aggregators were used. Trailblazer here was the Lotus Notes Client: One did everything in Notes, the main job and all the auxiliary and transient would be there. This consistency was attempted to recreate using portals and intranets (for inspiration what intranets can achieve, head over to The Nielsen Norman Group).

Auxiliary applications

You need to complete a task fast and want effortless results. An auxiliary posture helps with that. Adding an appointment in a calendar, booking a ride share, filing tax returns.

Auxiliary applications with a primary posture

One's primary application is another's auxiliary. This is a huge problem especially for bespoke applications. Typically they are comissioned by departments who will use them in "primary posture" (e.g. the leave management system gets commissioned by HR). The leave administrator will happily learn all bells and whistles, while mortal users are irritated by the complexity. I recall working on a leave management system where the initial application form had over 30 fields to cover all eventualities. We were able to convince the application owner to take a 2 form approach: the initial form had: coming, going, type of leave and optional "on behalf". 2 buttons were offered: "more" and "submit". "More" would lead to the 30+ fields form. We monitored usage for 6 month. Not a single time the larger form was submitted.

Multiple front-ends

To avoid the primary auxiliary trap, a clear API that separates UI from business logic helps. It allows to build smaller front-ends that are auxiliary in nature but don't compromize integrity. OpenAPI is your friend