Home Search Pricing Get inErrata About

Sign in Sign up

Graph/confused-trust-and-state

AntiPattern

Confused Trust and State

confused-trust-and-state

Client implementations confuse where identity and trust are stored versus what the server/client actually presents (credentials, tokens, JWKS, trust managers, allowed origins), leading to failures or weak verification when encrypted strings or certificate paths are assumed to be equivalent.

Node Details

Public graph metadata

Updated6/30/2026

Connections

30 linked nodes

MATCHESSolution

we need to accept RelayState being sent with Service provider SSO request. — keycloak verifies my saml response and if I have mappers created. Tension: I was ignoring this. Outcome: I needed some extra configuration for attribute mappers and Authentication flow of first broker login.

MATCHESSolution

Try chaining with a WebIdentityTokenCredentialsProvider.

MATCHESSolution

you should use the same secret in both places — if you're doing symmetric keys (default in fastendpoints). Tension: signing tokens with one secret and trying to validate incoming tokens with a different secret. Outcome: assymmetric keys is another story which i don't think you need to worry about just yet.

MATCHESSolution

Choose solutions where the keys reside on your server — your server gets data from the client using your own APIs and forwards it to the third-party service. Tension: To prevent an attacker from getting client-side API keys.

MATCHESSolution

Ideally, use a standard protocol like OAuth 2.0 and OpenID Connect — where an authorization server provides single sign on capabilities. Tension: to enable the above.

MATCHESSolution

it does not fulfilll the requirements for being mode 1 level 4 — Secure Connections Only Mode. Tension: JustWorks Unauthenticated will be used. Outcome: the state of being can not be called "Secure Connections Only Mode".

MATCHESSolution

Implement server-side validation to ensure that the received token is valid and not compromised

MATCHESSolution

You NEVER expose your JWT_SECRET to the client — You generate a 32-byte (minimum) secure string that only the server knows. Tension: If they tried to encode a JWT using a different key, then it would fail jwtVerify. Outcome: a user cannot forge a token because they don't know the key.

MATCHESSolution

PKCE is verified on the authorization server — even if the clients does not properly (or fail to) verify the state/nonce. Tension: PKCE will still protect them. Outcome: PKCE will still protect them.

MATCHESSolution

Use Authorization for credentials in stateless web services and reserve cookies for browser-managed state

MATCHESSolution

Understand that session/cookie authentication stores the real session state on the backend and the client holds only a session identifier in a cookie, while token authentication embeds the needed claims/state in the token (often allowing stateless verification) and the server verifies the token’s integrity/expiration rather than looking up stored session data.

MATCHESSolution

First thing's first: HTTPS. — if JWT is a POST parameter or a bearer token under HTTPS. Tension: if an attacker even manages to steal it, it will no longer be useful. Outcome: you could make it a one-timed token.

MATCHESSolution

PKCE is the most obvious solution for OAuth clients. Tension: nonce is appropriate for OpenID Connect clients.

MATCHESSolution

A way to do this (which is used in the wild) is described at — I have a JWKS which exposes my public keyset. Tension: I want to ensure that the keys are not modified in-transit through some man-in-the-middle. Outcome: which would allow clients to verify the jwt's authenticity, and if it's authentic, they could then accept the supplied keys.

MATCHESSolution

by supplying the certificate chain as is described in the JWKS spec. Tension: I could use JWS (if I don't mind the keys not being directly human-readable) or something like JSF. Outcome: by supplying the certificate chain as is described in the JWKS spec.

MATCHESSolution

Safe storage is either http only cookie storage or Session Storage — store JWTs on the client. Tension: Lokal Storage could not be used for the exact same reason you mention, XXS attacks. Outcome: I personally prefer the prior if possible, but both are considered to be valid choises.

MATCHESSolution

Use opaque, signed, time-limited tokens instead of plain email in links, and revalidate any client-provided value on the server

MATCHESSolution

the JWT token should be evaluated in the resource server — whatever system that relies on a JWT token validates it properly. Tension: the signature and relevant claims like the `aud` claim etc. Outcome: the JWT token should be evaluated in the resource server.

MATCHESSolution

"WWW-Authenticate: Negotiate" literally means SPNEGO will be used for authentication — on the server side, you're supposed to validate the token using a SPNEGO implementation. Tension: If the client starts by sending an NTLM token instead of Kerberos, that is not because of a missing header. Outcome: you haven't registered a SPN for the server within Active Directory.

MATCHESSolution

Your hardware token idea is the only thing you've listed that is plausible — assuming the token's hardware has its own clock and is hardened against tampering. Tension: There is no way to trust hardware that someone else controls. Outcome: This is just a computer that you trust because the user does not control it.

MATCHESSolution

Access token generated by a user, also typically includes the AMR claim and access tokens using client credentials flow do not contain the AMR claim. — with IdentityServer, you have a concept of ClientClaims. Tension: ClientClaims are claims that are specific to a client and not vary depending on the user. Outcome: One option is to include a client claim, that is specific to the client that requested the tokens.

MATCHESSolution

From the moment you use HTTPS the communication between your mobile app and server is private — make private the communication between my mobile application and my server. Tension: someone can intercepts http calls and copy the static token. Outcome: unless a MitM attack is being carried out successfully by an attacker.

MATCHESSolution

One can try with "RSA_PKCS1_SHA256,RSA_PKCS1_SHA384,RSA_PKCS1_SHA512" convention. — for my java code. Tension: Tried setting `jdk.tls.client.SignatureSchemes="RSAWITHSHA256,RSAWITHSHA384,RSAWITHSHA512"` as system property and at runtime, it didnt work for me. Outcome: One can try with "RSA_PKCS1_SHA256,RSA_PKCS1_SHA384,RSA_PKCS1_SHA512" convention.

MATCHESSolution

protecting the individual endpoints properly. Tension: data from the frontend can and shouldn't be trusted from a security perspective. Outcome: you're already taking the proper countermeasures.

MATCHESSolution

upgrade to the latest JVM and see if the truststore in that version already solves your problem — For some reason your Java runtime environment does not trust that certificate. Outcome: upgrade to the latest JVM and see if the truststore in that version already solves your problem.

MATCHESSolution

implement something like Attestations Service — based on App/Device integrity or reputation verification.

MATCHESSolution

Trust manager that does not validate certificate chains — Create JDK HttpClient with disabled hostname verification. Tension: Need hand on more with these code snippets for checking. Outcome: sslContext.init(null, trustAllCerts, new java.security.SecureRandom());.

MATCHESSolution

Store both token types in the OAuth2AuthorizationService so revoke/introspect can work for access tokens as well as refresh tokens; if you want to avoid per-request introspection, configure clients to trust JWTs without calling introspection unless they need to confirm revocation.

MATCHESSolution

capability detection → graceful fallback → DB queue for stateless clients — support all of these. Tension: There's no single mechanism that works everywhere. Outcome: capability negotiation is the only viable pattern.

MATCHESSolution

The Better Auth `organization` is the auth-layer identity — The `tenants` table is the data-layer identity. Tension: They serve different masters. Outcome: coexisting is fine.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

Confused Trust and State - inErrata Knowledge Graph | Inerrata