3 ms·

Unless I misread I consider this statement not true or contradictory: it has all the information the server needs except the signing keys, so the server does

by xvinci 4y ago

Unless I misread I consider this statement not true or contradictory: it has all the information the server needs except the signing keys, so the server doesn't need to store this information server-side. This means that users can get a token from your authorization server and use it in another without those servers needing to consult a central service. In order to not have to care about rotating keys, a typical Resource Server would fetch the public key from the SSO server. Not necessarily in real-time, but at least on a frequent periodic basis. It even says "except the signing key", which is half true, since the public key needs to be well.. public and available. Now this may be nitpicking but it comes with an important implication: Your jwt validating party needs to have network access to the SSO service (unless you want to provide keys for token verification yourself, which I do not recommend), which is not always a given, especially in hybrid setups (On-Prem + Cloud).

gboone 4y ago
Maybe it's about "can get" vs "should be allowed to get"? They can carry whatever so it's technically true, right?
- xvinci 4y ago
  It was more about the and use it in another without those servers needing to consult a central service. part. Unless you take care of key distribution yourself (like another poster wrote), this consultation of a central service has to take place to exchange key information (but not for additional authentication or authorization information).
ffo 4y ago
Well true, public keys would be better wording wise. One thing I just wanted to append to this here: > Not necessarily in real-time, but at least on a frequent periodic basis. Periodically fetching the keys is not really a best practice on its own. The consumer (RP) must be able to handle newly published keys at runtime. Since a JWT includes a KID it is recommended to lookup a local cache pre-filled from a scheduler while fetching new KIDs on demand.
magicalhippo 4y ago
Indeed. We validate Azure AD tokens for our native application. Not all of our on-prem installations have unrestricted internet access. So we have a task that periodically checks and downloads Azure's signing keys[1], so we can distribute them to our customers. [1]: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration https://login.microsoftonline.com/common/v2.0/.well-known/op... (jwks_uri element)
mooreds 4y ago
> In order to not have to care about rotating keys, a typical Resource Server would fetch the public key from the [authorization] server. Another option would to be prepackage N public keys with the resource server during deployment. This means there is absolutely no network access required, just filesystem access to the public keys. You want more than 1 so that you can rotate the signing keys if you need to, without redeploying said service. What is the correct value for N? I dunno, depends, but it's not hard to generate 100 public/private keypairs and then bundle up the 100 public keys into a deployment artifact. Is this as common as using JWKS? No, not in my experience. Is it possible? Absolutely.

by xvinci 4y ago

gboone 4y ago

Maybe it's about "can get" vs "should be allowed to get"? They can carry whatever so it's technically true, right?

xvinci 4y ago
It was more about the and use it in another without those servers needing to consult a central service. part. Unless you take care of key distribution yourself (like another poster wrote), this consultation of a central service has to take place to exchange key information (but not for additional authentication or authorization information).

ffo 4y ago

Well true, public keys would be better wording wise. One thing I just wanted to append to this here: > Not necessarily in real-time, but at least on a frequent periodic basis. Periodically fetching the keys is not really a best practice on its own. The consumer (RP) must be able to handle newly published keys at runtime. Since a JWT includes a KID it is recommended to lookup a local cache pre-filled from a scheduler while fetching new KIDs on demand.

magicalhippo 4y ago

Indeed. We validate Azure AD tokens for our native application. Not all of our on-prem installations have unrestricted internet access. So we have a task that periodically checks and downloads Azure's signing keys[1], so we can distribute them to our customers. [1]: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration https://login.microsoftonline.com/common/v2.0/.well-known/op... (jwks_uri element)

mooreds 4y ago

> In order to not have to care about rotating keys, a typical Resource Server would fetch the public key from the [authorization] server. Another option would to be prepackage N public keys with the resource server during deployment. This means there is absolutely no network access required, just filesystem access to the public keys. You want more than 1 so that you can rotate the signing keys if you need to, without redeploying said service. What is the correct value for N? I dunno, depends, but it's not hard to generate 100 public/private keypairs and then bundle up the 100 public keys into a deployment artifact. Is this as common as using JWKS? No, not in my experience. Is it possible? Absolutely.