JWT vs. Opaque Tokens

Re:JWT vs. Opaque Tokens by xvinci on Thursday September 29, 2022 @08:49AM (#33019833)

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).

[ Parent | on HN ]

Re:JWT vs. Opaque Tokens by ffo on Thursday September 29, 2022 @09:01AM (#33019988)

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.

[ Parent | on HN ]

Re:JWT vs. Opaque Tokens by mooreds on Thursday September 29, 2022 @12:15PM (#33022745)

> 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.

[ Parent | on HN ]

Re:JWT vs. Opaque Tokens by magicalhippo on Thursday September 29, 2022 @09:12AM (#33020130)

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/op... (jwks_uri element)

[ Parent | on HN ]

Re:JWT vs. Opaque Tokens by gboone on Thursday September 29, 2022 @09:01AM (#33019986)

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

[ Parent | on HN ]

Re:JWT vs. Opaque Tokens by xvinci on Thursday September 29, 2022 @11:03AM (#33021704)

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).

[ Parent | on HN ]