I think is was just a bug that verify = false still caused verification in the first place.
What you want would look like this (should have been like this even in 1.5.6):
JWT.decode(id_token, nil, true, { verify_exp: true, algorithm: 'none' })
But it does not actually work.

It looks like alg none is only really accounted for in encode but not in decode.

I think is was just a bug that verify = false still caused verification in the first place.
What you want would look like this (should have been like this even in 1.5.6):
JWT.decode(id_token, nil, true, { verify_exp: true, algorithm: 'none' })
But it does not actually work.

It looks like alg none is only really accounted for in encode but not in decode.

I think there are two meanings of verification, signature and claims.
What is the parameter 'verify' in decode method designed for, to verify the signature, or to verify claims?

Thank you!

Thoughts specific to the gem in question

I think there are two meanings of verification, signature and claims.
What is the parameter 'verify' in decode method designed for, to verify the signature, or to verify claims?

I'm not the author of that code to tell what was the intension behind the API's design decisions. Naming things is one of those subjective and hard topics in programming.

This gem has basic validation as per RFC and simply does not cover some rare or peculiar use cases.

Although it's possible the gem could make use of "validation" vs "verification" terminology, but as I point out later, a full-blown validation is likely not the point of the gem and what it does right now it more like a "do what RFC explicitly states" in a single chunk under the "verify" umbrella term.

As best as I can understand the current design of the gem, the API:

JWT.decode(id_token, nil, true, { verify_exp: true, algorithm: 'none' })

would make perfect sense.
verify=true (third argument) stands for "standard set of RFC requirements", while options let you choose specific claims to verify.
Following this design there exists a bug as of now. The verification does not support "alg": "none". Which is perfectly suitable for further verification as per the RFC (it does not make distinction between secured and unsecured tokens when it comes to claims verification). The gem explicitly supports "alg": "none" for token creation and it would only be logical if it could successfully parse back it own output.
Everything beyond that behaviour would be considered application-specific behaviour.

Thoughts about terminology and RFCs

I want to make sure that, is it correct to perform the claim verification on an Unsecured JWT?

Yes, the RFC does not forbid the verification of unsecured tokens and leaves it to the developer to secure the token by the means they deem sufficient. Section 6 clarifies that https://tools.ietf.org/html/rfc7519#section-6

To my mind, whether you trust a JWT or not is a separate question from claims verification.

Signature has nothing to do with the validness of the contents of a message. It is normal to validate submitted html forms but they are not signed. You can verify (be sure) who sent the message (using cryptography) but you have to check separately whether it's not garbage.

RFCs are often very generic. And it's sometimes hard to draw the line between mandatory/standard and application-specific. It's a common issue with RFCs involving auth and crypto. Hardly anyone should blame lib's creators and maintainers in such cases (so please don't).

The RFC puts some requirements on the registered claims while still leaving them in the application domain. It will be a very long and not necessarily fruitful discussion to decide whether a gem should have sophisticated claims validation or should leave it completely to a gem's user.

https://tools.ietf.org/html/rfc7519#section-4.1.4:

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

What is processing? Does it mean "halt the executing right there"? Or does it mean "don't do with that token what you would usually do" (i.e. grant permission) and you can do something else?
Does this mean I can never look into the contents of an otherwise perfectly valid but expired token to show some nice error message or anything else based on its claims?

I think there are two meanings of verification, signature and claims.

Think about "unverified" and "invalid". What would you want to do with an unverified token and with an invalid token. It's likely that you don't want to touch an unverified token any further. But you may still want to do a special treatment for a verified but invalid token. Here verification is about trust and validation is about relevance and consistency.

This point of view helps me to better architecture the handling of JWT. In one of the cases any trustworthy token received by that particular system had to have valid signature, Issuer and Audience. Otherwise it's not even allowed to be read by other components. Meanwhile there were a plethora of uses cases (access tokens, permission granting, authorization, etc.) with distinct claims validation rules (many of which utilized registered claims). And I had to write a completely separate API on top of this gem to do that.

@hesalx
Thank for your detailed response, especially the RFCs v.s. application (Verification v.s. Validation) part. I benefit a lot from your comment.

I do not mean to blame the author. What I want to confirm is if it is a bug or not.

Going to close this one. The ::JWT::EncodedToken will allow separate claim verification and signature validation. We are not going to touch the behavior of the historical JWT.decode