I am currently implementing an iOS app, which integrates with a cloud hosted .net backend system in azure, which.

The api login endpoint takes user/pass -> replies with an signed only HS256 jwt token. All further calls to the endpoint require an Authorization header of type bearer, and the endpoint supports renewal of this token, as long the token is not expired, for what it seems to be an infinite amount of time. (which in itself isn't great). The server-side seems to validate the signature of this token in every request.

In the past having used only RSA tokens, we always shared with clients the public key so they could verify the signature of the token. However since this api only supports HS256, this is not possible.

What security risks would a client not verifying the signature incur for the client side? An obvious one is accessing cached data within the screens. But would there be more serious ones? Thanks in advance.

  • Why would the client want to verify the token?
    – user163495
    Jan 23, 2020 at 14:29
  • Its an HR application, where users will send potentially confidencial information from the client (project related information, or even personal) isnt it best practice to do so? verifying the token would allow to know if a token was tampered with would know not send information back to the server? No?
    – McDuck
    Jan 23, 2020 at 14:34
  • What would be the point of using a tampered token? The original web server would not be able to use it and nothing would work.
    – user163495
    Jan 23, 2020 at 14:36
  • Yes that is correct. So from ur perspective there is no point in validating the token from the server?
    – McDuck
    Jan 23, 2020 at 14:37
  • 1
    Exactly, because a.) you can't do it anyways and b.) you can't do anything about it either.
    – user163495
    Jan 23, 2020 at 14:40

2 Answers 2


A session token of any kind, JWT included, is expected to be an opaque blob to the client. This is actually enforced for most tokens stored in cookies, where the HttpOnly flag means the client can't inspect the cookie. Even for bearer tokens, though, there's no need to inspect the token client-side.

Indeed, I'd be suspicious of any system where any element of its security depended on the client validating the session token. Client-side validation can be useful for convenience or for offloading some performance (for example, the client might notice a token is about to expire and refresh it), but the server always must perform its own validation and make no expectation of the validity of the client data (in that example, the server needs to operate correctly if the client doesn't refresh in time, refreshes constantly, sends an invalid refresh token, etc.).

I'm not entirely sure what you mean by "accessing cached data within the screens", but it doesn't sound like a relevant problem at all. If the app wants to know how long sessions last (so it can clear its cache when they end), that's a reasonable thing to desire, but there's no need or reason for it to verify the token for this purpose; if the attacker can modify the token they can (almost certainly) also just access the cache directly.

Assuming the token is only ever transmitted over secure connections and not stored when an untrusted user/app can access it (which... if either aren't true you have other, very large problems, but none due to the risk of the token being invalid), and that the token isn't being used as anything other than "a token" (i.e. it's not also an key for client-side data encryption or some such), there's really no need for the client to know anything about the token at all.

The reason people use asymmetric signatures in JWTs is so that only one service can mint them, but others - which the minter might not trust - can verify them. The client/bearer is not generally a "service" in this sense. The reason people use keyed hashes in JWTs is because asymmetric crypto is very computationally expensive, especially if you want the same degree of security. The ability for the client to make heads or tails of the signature is never, in my experience, relevant (even with asymmetric signatures I've never seen a case like you talk about, where the service actually publishes the public key to the client; it's just not relevant).


First of all I am extremely sorry if I did not understood the question correctly.

IMHO, if a token got hijacked (implementing MiTM), then the malicious user (especially if signature is not verified and the TTL of token is infinite) can use it to impersonate as server, pushing and update (depends on how you actually built your service) and doing anything he can by impersonating server responses. Or he can impersonate the client, and try to update account details in application.

Regarding the difficulty of such attack, it requires to be targeted (because hacker have to listen to traffic first), and depends much on a server side\client side settings (storing token in server side cookies not accessible by javascript to defend against physical access, setting TTL to a very short time, and so on).

  • The token can be renewed through a renew endpoint and retrieves a new token each time, but the session will be alive as long Its renewed. Server side developers are happy to change the alg to rsa, so i can sign it as long there are security risks to the app not verifying its signature. Serverside developers say in each request they will validate the token signature, to make sure it wasnt tampered. From what i can think of, leaving it as it is would allow a user to do mitm and seeing cached screens which can have personal information (depending at which point the user is), is there anymore?
    – McDuck
    Jan 23, 2020 at 18:00
  • Are there anymore risks. And should a client (app) validate the token?
    – McDuck
    Jan 23, 2020 at 18:01
  • RicardoDuarte, I am sorry for not being clear enough. Reading your question, I understood that token's life are set to infinite. My answers were regarding security in replay attacks, not tamper ones. Forgive me if I misread something. Jan 23, 2020 at 18:06
  • 1
    Regarding client side verification - it does not give much, since when MiTM attack will be involved, the attacker can route token validation requests to himself, and validate them. If I wanted to defend client from that vector, I would have implemented an encrypted tokens. Jan 23, 2020 at 18:14
  • Thank you rashad, i think both ur answers and google have given me a enough information to take onboard. I was aware of what you @mechmk1 suggestions but i was worried i was missing something.
    – McDuck
    Jan 23, 2020 at 18:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .