This is the 2023 implementation that use the SysCert model pattern.
A describing video is available here: https://youtu.be/lKE2Heyc8h0
The central points are the model pattern:
Use the SysCert.ecomdl merge file to get this into your model
The text below is for the older implementation we did 2022 - to allow javascript clients with a JWT authenticate access to Rest-api's in the turnkey application
(this is still good and ok - but the new SysCert based solution is superseeding this , and is more generic in every way)
Normally you log into the Turnkey site manually - and the application has a auth-scheme set up. But if you want to allow api login with arbitrary jwt token via rest call - and if you in that case want to be able to verify a sent in bearer token as being valid concerning a set of criteria's and if so then accept the user... Read on.
On turnkey rest commands add Authentication header with value "Bearer yourjwttoken".
We will unpack the JWT, try to find a SysExternalJWTDefinition object that match on Kid (short for KeyIdentity) and Aud (short for Audience and this is an identifier specific for the login you did).
The JWT is similar to the older xml based format SAML and SAML2.
If found we will use the values from attributes Modulus and Exponent (that you must find at the place your key was created like maybe https://accounts.google.com/.well-known/openid-configuration, these always end with well-known/openid-configuration) to verify the validity of your key (we will check that it is a valid key by using the certificate details you provided in Modulus and Exponent, among the claims we will only check that it has not expired).
Here are the keys for Azure AD: https://login.microsoftonline.com/common/discovery/v2.0/keys
If the key was valid and not expired we take the email field from the key - or name if email is not present - and send it to the Method SysExternalJWTDefinition.AcceptAndTransformUserName(user:string;audience:String):string
SysExternalJWTDefinition.AcceptAndTransformUserName you can do any additional clean up of name to make it match the pattern you have in SysUser.Email - or return a empty string if you do not want to allow this user access.
if we get a non empty string from AcceptAndTransformUserName we will lookup (not create) a SysUser with this name - and we will mark the user as logged in (ie - a cookie will be placed in the header so that subsequent calls to Get/Post etc will be logged in calls).
Letting external programs call you via Javascript will require you to configure cors - read more here
See also Connecting javascript SinglePageApplications to Turnkey (SPA)