Good question. Maybe Javier can add a comment here.

Hi, I answered my own question. I downloaded the jose4j library, got the key info from the jwks endpoint, and was able to validate the signature that way. I do have a couple of questions: Isn't it possible to create a valid signature using those well know values, and thus spoof a RSA256 JWT? How do we create/enforce password policy in gluu? That is, how do we do things like create expiration dates on profiles, keep track of number of consecutive incorrect logins (and reset these on successful login), create a cool off period after a number of incorrect logins, etc. I assume this happens in custom scripts.

Also answered my own question number 1: "The JWT spec also defines a number of asymmetric signing algorithms (based on RSA and ECDSA). With these algorithms, tokens are created and signed using a private key, but verified using a corresponding public key. This is pretty neat: if you publish the public key but keep the private key to yourself, only you can sign tokens, but anyone can check if a given token is correctly signed." So I guess that, if the payload is not signed with the private key, it will not properly verify with the public key. Still need to know about my second question on password policy. Thanks!

Password policy can be stored as an attribute of the user data, so it requires a custom authentication script. What the exact policies you want to implement. The ones we hear most often are - Lock account after 3 bad logins for x minutes - Require change of password every x number of days - Password complexity / strength requirements Also, where does the password need to be written. Just in the Gluu Server?

Hi Michael, We have the possibility of all of these policies. Currently password policy is dictated by the customer, and they can choose from these: Maximum number of login attempts, before the user account is locked Maximum number of login attempts, before the user account is temporarily locked for ten minutes Maximum number of login attempts, before the user account is temporarily locked for fifteen minutes Maximum number of login attempts, before the user account is temporarily locked for five minutes Notify user that failure of login attempts will cause the user account to be locked (after a certain number of attempts) Passwords should have both digits and letters Maximum expiration age of passwords Maximum history records of password used for duplicate check when changing password Minimum required password length Currently we are not implementing a password complexity check, but that would be something we would want as well. For password reset we are employing captcha I think we would want some of the password data to be stored in a database, such as previous password history - we might want to poll and propagate changed info to LDAP, or perhaps we would just change it in LDAP. Not sure at this point.