Should two JWTs still be considered equal if their claims/headers are in different orders? - jwt

If I have two JWTs, where their set of claims and headers are the same but the order they are stored in json is different, should they be considered equal?
Clarification:
I am aware that as a user of JWTs you should not need to compare them, but that is not what I am doing.
Say we have some jwt library, and you have some object that represents a JWT in it's decoded form. If we create an encoded JWT from our decoded JWT and then apply it to some function that returns once again the decoded JWT. Do we consider the two decoded JWTs to be equal if the order in which the claims or headers are stored in some collection has changed due to the decoding process?
Thinking more about this, perhaps it is wrong to store the headers and claims in a collection which has some notion of order? Using something like a set makes this problem disappear?


Depends on what you mean by 'different'. If the claims are the same then they are the same in the sense that the information transferred is equal. But if they both have the same signature then at least one will be invalid.
Also you shouldn't need to compare JWT claims at all. If you're storing the token and comparing the token given then you should revisit why you're using JWT over something like session.
JWT is designed to be independent. Because JWT tokens are claims based authentication the validation is done against the signature, not against anything on the server.

Related

can we hash the JWT and save the hashed version in local storage since it is not safe to put the jwt in local storage?

since it is not safe to keep the JWT in local storage because of CSRF or XSS attacks so i am wondering is it possible for example to create a hash function that can hash the JWT and keep the hashed version (useless) in local storage? and we create also a decode function that decode the hashed JWT and return the correct JWT whenever we need to use it.
it seems something manageable to me could there be any possible flaws or issues related to this technique?

That is pretty pointless to hash the JWT.
A better approach is to use the BFF pattern as described in these two resources
alert‘OAuth 2 0’; // The impact of XSS on OAuth 2 0 in SPAs
The BFF Pattern (Backend for Frontend): An Introduction

What is the use of these Keycloak endpoints?

What are the use of these keycloak endpoints?
issuer: "http://localhost:8180/auth/realms/dev",
authorization_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/auth",
token_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/token",
introspection_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/token/introspect",
userinfo_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/userinfo",
end_session_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/logout",
jwks_uri: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/certs",
check_session_iframe: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/login-status-iframe.html"
I know that on the token_endpoint I can get an access token, but I have no idea about the rest. I can see the data if I open the links but I have no idea when to use any of these in my java application.

issuer - realm that issues an access_token
introspection_endpoint - checks validity of an access_token
userinfo_endpoint - accepts access_token & returns info about current logged user, that is clarified in MAPPER of client
end_session_endpoint - forces an access_token invalidation
More information about KeyCloak endpoints you can find on baeldung (parts 5.1-5.5)

Check OIDC discovery spec: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
issuer
REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.
authorization_endpoint
REQUIRED. URL of the OP's OAuth 2.0 Authorization Endpoint [OpenID.Core].
token_endpoint
URL of the OP's OAuth 2.0 Token Endpoint [OpenID.Core]. This is REQUIRED unless only the Implicit Flow is used.
userinfo_endpoint
RECOMMENDED. URL of the OP's UserInfo Endpoint [OpenID.Core]. This URL MUST use the https scheme and MAY contain port, path, and query parameter components.
jwks_uri
REQUIRED. URL of the OP's JSON Web Key Set [JWK] document. This contains the signing key(s) the RP uses to validate signatures from the OP. The JWK Set MAY also contain the Server's encryption key(s), which are used by RPs to encrypt requests to the Server. When both signing and encryption keys are made available, a use (Key Use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. Although some algorithms allow the same key to be used for both signatures and encryption, doing so is NOT RECOMMENDED, as it is less secure. The JWK x5c parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate.
registration_endpoint
RECOMMENDED. URL of the OP's Dynamic Client Registration Endpoint [OpenID.Registration].
scopes_supported
RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] scope values that this server supports. The server MUST support the openid scope value. Servers MAY choose not to advertise some supported scope values even when this parameter is used, although those defined in [OpenID.Core] SHOULD be listed, if supported.
response_types_supported
REQUIRED. JSON array containing a list of the OAuth 2.0 response_type values that this OP supports. Dynamic OpenID Providers MUST support the code, id_token, and the token id_token Response Type values.
response_modes_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 response_mode values that this OP supports, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. If omitted, the default for Dynamic OpenID Providers is ["query", "fragment"].
grant_types_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Type values that this OP supports. Dynamic OpenID Providers MUST support the authorization_code and implicit Grant Type values and MAY support other Grant Types. If omitted, the default value is ["authorization_code", "implicit"].
acr_values_supported
OPTIONAL. JSON array containing a list of the Authentication Context Class References that this OP supports.
subject_types_supported
REQUIRED. JSON array containing a list of the Subject Identifier types that this OP supports. Valid types include pairwise and public.
id_token_signing_alg_values_supported
REQUIRED. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. The algorithm RS256 MUST be included. The value none MAY be supported, but MUST NOT be used unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow).
id_token_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT].
id_token_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT].
userinfo_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS [JWS] signing algorithms (alg values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT]. The value none MAY be included.
userinfo_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE [JWE] encryption algorithms (alg values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT].
userinfo_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT].
request_object_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for Request Objects, which are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support none and RS256.
request_object_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (alg values) supported by the OP for Request Objects. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.
request_object_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) supported by the OP for Request Objects. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.
token_endpoint_auth_methods_supported
OPTIONAL. JSON array containing a list of Client Authentication methods supported by this Token Endpoint. The options are client_secret_post, client_secret_basic, client_secret_jwt, and private_key_jwt, as described in Section 9 of OpenID Connect Core 1.0 [OpenID.Core]. Other authentication methods MAY be defined by extensions. If omitted, the default is client_secret_basic -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
token_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the Token Endpoint for the signature on the JWT [JWT] used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. Servers SHOULD support RS256. The value none MUST NOT be used.
display_values_supported
OPTIONAL. JSON array containing a list of the display parameter values that the OpenID Provider supports. These values are described in Section 3.1.2.1 of OpenID Connect Core 1.0 [OpenID.Core].
claim_types_supported
OPTIONAL. JSON array containing a list of the Claim Types that the OpenID Provider supports. These Claim Types are described in Section 5.6 of OpenID Connect Core 1.0 [OpenID.Core]. Values defined by this specification are normal, aggregated, and distributed. If omitted, the implementation supports only normal Claims.
claims_supported
RECOMMENDED. JSON array containing a list of the Claim Names of the Claims that the OpenID Provider MAY be able to supply values for. Note that for privacy or other reasons, this might not be an exhaustive list.
service_documentation
OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the OpenID Provider. In particular, if the OpenID Provider does not support Dynamic Client Registration, then information on how to register Clients needs to be provided in this documentation.
claims_locales_supported
OPTIONAL. Languages and scripts supported for values in Claims being returned, represented as a JSON array of BCP47 [RFC5646] language tag values. Not all languages and scripts are necessarily supported for all Claim values.
ui_locales_supported
OPTIONAL. Languages and scripts supported for the user interface, represented as a JSON array of BCP47 [RFC5646] language tag values.
claims_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the claims parameter, with true indicating support. If omitted, the default value is false.
request_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the request parameter, with true indicating support. If omitted, the default value is false.
request_uri_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the request_uri parameter, with true indicating support. If omitted, the default value is true.
require_request_uri_registration
OPTIONAL. Boolean value specifying whether the OP requires any request_uri values used to be pre-registered using the request_uris registration parameter. Pre-registration is REQUIRED when the value is true. If omitted, the default value is false.
op_policy_uri
OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about the OP's requirements on how the Relying Party can use the data provided by the OP. The registration process SHOULD display this URL to the person registering the Client if it is given.
op_tos_uri
OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about OpenID Provider's terms of service. The registration process SHOULD display this URL to the person registering the Client if it is given.
Additional OpenID Provider Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session].
Some data are optional/recommended only, so Keycloak doesn't provide all of them.

Ensure uniqueness of a token string for the same payload but for two different use cases

I have two use cases: a. Verify Email Address b. Reset forgotten password
For JWT signing, I am just passing a user Id in the payload. Does JWT signing process make sure that two different (unique) JSON tokens be generated for these two use cases? If not, what do I need to do? Kindly help
Thanks

Only when signed using a deterministic algorithm - RS and HS family, all other algorithms (ES, PS, EdDSA) are not deterministic and two tokens with the same header and payload will have different signatures.

is it possible for JWT to generate a same token, two times?

is it safe to only use tokens to access/change a user's data in database?
Imagine I get a request with only jwt inside of it and I want to change something for only that user using his token which is stored in database, How do I be certain that no two users have same tokens stored in database? Do I need to get his username ( another data stored in database ) and compare both of them or only token is enough?

Probablytm. The chances of users details hashing to the same string (a collision) are pretty darn small.
The header will be quite common but the payload will vary wildy, depending on the algorithm. The signature is a product of the first two so a collision depends on the payload. This has so info on that (see the accepted answer) https://crypto.stackexchange.com/questions/2558/how-many-rsa-keys-before-a-collision

The simplest answers is that it is possible but it's very very unlikely that this will happen

How Does The Server Know If A Bearer Token Is Valid Without Storing It On Disk Or Memory

So I just implemented token based authentication in a Web API app using OWIN and I was able to understand the concept of how it all works (well on the surface at least).
What I couldn't understand is how the server validates the generated bearer token without storing it on the disk or memory. I mean sure the expiration date is probably encrypted in the token itself, but that only applies if it is already expired. So how does the server do it (on a high level)?
Update:
Okay i can see that the claims are stored in the token.So at some level the server is still checking that with the db during authentication correct? Otherwise let's assume that i'm the server and I was able to decrypt the token to this object:
{
"iss": "thesite.com",
"exp": 1300819380,
"name": "Chris Sevilleja",
"admin": true
}
So the question now is does the fact that I (the server) was able to decrypt the token into key value pairs (checking for the presence of specific keys like 'iss', 'exp' and checking for values like the 'admin' key must be true) means that I will authorize the web request?

JWT token is made up with three parts separated by dot(.).
First part is Header.
Second part is Payload
Third Part is Signature (say s0)
JWT Format
Signature is created using Header and Payload.
When server receives JWT token it creates temporary signature (say s1) from incoming header and payload.
If s0 and s1 signatures are same then token is valid.
Also token contains claims which are used to validate token. e.g exp claim contains unix epoch time after which token is considered as invalid.

The token is encoded with the JWT format (JSON Web token). This is well described in the standard (https://www.rfc-editor.org/rfc/rfc7519) and you will see that the token contains a certain number of claims, among which the expiration date (exp).