And what does it mean that they are in a "proprietary format"? I am reading about JWT refresh tokens and they are opaque tokens, but I don't understand the term.
2 Answers
A JWT has readable content, as you can see for example on https://jwt.io/. Everyone can decode the token and read the information in it. The format is documented in RFC 7519.
An opaque token on the other hand has a format that is not intended to be read by you. Only the issuer knows the format.
The meaning of the word already gives a hint:
opaque /ə(ʊ)ˈpeɪk/ adjective
not able to be seen through; not transparent.
Here's a quote from https://auth0.com/docs/tokens:
Opaque tokens: Tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage. To validate an opaque token, the recipient of the token needs to call the server that issued the token.
A "opaque JWT refresh token" is a contradiction as per definition above. What actually is meant here is, that in some JWT frameworks only the authentication token is a JWT, but as refresh token they use opaque tokens.
-
Thank you. I think what got me confused is the signature part, which is encrypted so not really readable per se. I've also found an excellent explanation here: https://community.apigee.com/questions/21139/jwt-vs-oauth.html – sloneorzeszki Dec 03 '19 at 14:22
-
2@sloneorzeszki In the [explanation](https://community.apigee.com/questions/21139/jwt-vs-oauth.html) you linked an `opaque token` is described as a random string that only serves as a pointer to server side stored information. This kind of token is described [here](https://openiddict.github.io/openiddict-documentation/guide/token-formats.html) as `reference token` whereas an `opaque token` might indeed contain encrypted information (only readable for the original issuer). So there are slightly different definitions of which we should be aware. – jps Dec 06 '19 at 15:29
-
Any example of how the Opaque Token looks like? – Dendi Handian Jan 21 '21 at 03:30
Here, the term "opaque" means the string (that serves as token) is like a reference (in OOPs), or pointer (in C), or foreign keys (in relational DBs). i.e. You need an external content to resolve it.
Simple versus Composite:
The string is a "simple" string, as opposed to JWS, where is "composite"; It has parts "inside" it.
Inside versus Outside:
You can extract a payload (with claims, etc) out of it without referring to an external server or storage, "outside" this string.
Since an opaque token is a simple string it is just a reference, hence, naturally, its format is entirely arbitrarily determined by the server that issues it (hence the term "proprietary format"). The token string is determined at the time of creation of the underlying (referred-to) content, i.e. when it is paired (associated) with the contents that this token (as the reference or foreign key) refers to.

- 2,750
- 2
- 22
- 36
-
So an opaque token can be literally even a random string or an Id integer, right? In other words, how is it generated/created? This Id might refence to another data inside Authorization Server database. For example, an `access_token` and/or `id_token`, correct? Knowing a `refresh_token` can generally eliminate the security of both `tokens`. Related: https://auth0.com/docs/tokens/refresh-tokens/use-refresh-tokens – Artfaith Feb 11 '21 at 05:04
-
It seems, I found the answer on the page: https://thehftguy.com/2019/01/02/the-difference-between-id_token-and-access_token-in-openid-connect/ In other words, the `access_token` and `id_token` can be literally everything, but current days, **both** are usually a `JWT`. – Artfaith Feb 11 '21 at 05:56