Documentation:Authenticate with a jwt: Difference between revisions

Authenticate with a jwt

Latest revision as of 15:27, 10 February 2024

This is the 2023 implementation that uses the SysCert model pattern.

A description video is available here: https://youtu.be/lKE2Heyc8h0

The central points are the model pattern:

x

Use the SysCert.ecomdl merge file to get this into your model.

This pattern allows you to:

Generate your own certificates with your own CN name
Import public key part of external certs
Generate JWT tokens
Generate SAML2 tokens
Validate JWT tokens
Validate SAML2 tokens

The text below is for the older implementation we did in 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 supersedes this and is more generic in every way.)

Normally you log into the Turnkey site manually - and the application has an auth-scheme set up, but if you want to allow API login with arbitrary jwt token via rest call - and if you want to verify a sent-in bearer token as valid concerning a set of criterias and if so, then accept the user... Read on.

On Turnkey rest commands, add an Authentication header with the value "Bearer yourjwttoken".

We will unpack the JWT. Try to find a SysExternalJWTDefinition object that matches on Kid (short for KeyIdentity) and Aud (short for Audience and this is an identifier specific to 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. (You must find these 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 unexpired, we take the email field from the key - or name if the email is not present - and send it to the Method SysExternalJWTDefinition.AcceptAndTransformUserName(user:string;audience:String):string

SysExternalJWTDefinition.AcceptAndTransformUserName - you can do any additional cleanup of the name to make it match the pattern you have in SysUser.Email - or return an empty string if you do not want to allow this user access.

if we get a nonempty string from AcceptAndTransformUserName, we will look up (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.

This page was edited 90 days ago on 02/10/2024. What links here

@@ Line 1: / Line 1: @@
-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.
+This is the 2023 implementation that uses the SysCert model pattern.
-On turnkey rest commands add Authentication header with value "Bearer yourjwttoken".
+A description video is available here: https://youtu.be/lKE2Heyc8h0
-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 central points are the model pattern:
+[[File:2023-03-20 12h54 32.png|none|thumb|x|246x246px]]
+Use the SysCert.ecomdl merge file to get this into your model.
-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 [https://accounts.google.com/.well-known/openid-configuration 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).
+This pattern allows you to:
+* Generate your own certificates with your own CN name
+* Import public key part of external certs
+* Generate JWT tokens
+* Generate SAML2 tokens
+* Validate JWT tokens
+* Validate SAML2 tokens
-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):string
+==== The text below is for the older implementation we did in 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 supersedes this and is more generic in every way.)
-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.
+Normally you log into the Turnkey site manually - and the application has an auth-scheme set up, but if you want to allow API login with arbitrary jwt token via rest call - and if you want to verify a sent-in bearer token as valid concerning a set of criterias and if so, then accept the user... Read on.
-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).
+On Turnkey rest commands, add an Authentication header with the value "Bearer yourjwttoken".
-[[File:2021-02-18 16h42 36.png|none|thumb]]
-Letting external programs call you via Javascript will require you to configure [[Cors|cors - read more here]]
+We will unpack the JWT. Try to find a SysExternalJWTDefinition object that matches on Kid (short for KeyIdentity) and Aud (short for Audience and this is an identifier specific to 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. (You must find these at the place your key was created - like maybe https://accounts.google.com/.well-known/openid-configuration. These always end with [https://accounts.google.com/.well-known/openid-configuration 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 unexpired, we take the email field from the key - or name if the email is not present - and send it to the Method <code>SysExternalJWTDefinition.AcceptAndTransformUserName(user:string;audience:String):string</code>
+<code>SysExternalJWTDefinition.AcceptAndTransformUserName</code> - you can do any additional cleanup of the name to make it match the pattern you have in SysUser.Email - or return an empty string if you do not want to allow this user access.
+if we get a nonempty string from AcceptAndTransformUserName, we will look up (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).
+[[File:2021-02-28 22h13 20.png|none|thumb|416x416px]]
+Letting external programs call you via Javascript will require you to configure [[Cors|Cors - read more here.]]
+'''See also:''' [[Connecting javascript SinglePageApplications to Turnkey (SPA)]]
+[[Category:Security]]
+{{Edited|July|12|2024}}