Open laurids opened 1 year ago
FWIW, Claims.isSpecDate
has been migrated to a new internal (impl
module only) field/converter concept, where each RFC-standard field (aka 'Parameter') defines what is accepted for values as well as how to convert them to more idiomatic Java types. For example:
(The name Field
will be renamed shortly to Parameter
before the release to match the RFC taxonomy for this concept, but that's beside the point 😅 ).
This is mostly a reflection that the JJWT team implements support for all standards defined by the JOSE Working Group (which are 9 RFCs at the time of writing).
auth_time
is technically not in the scope for those specifications, it's part of the OpenID working group specifications, so we have no immediate plans to support additional (non-JOSE) specifications by default.
The reasons for this are a few:
End-User's full name in displayable form including...
. I would think there's a high likelihood that the generic concept of name
(or address
, etc) could conflict with any number of existing application JWTs value formats (is it a String
? A JSON Object
? etc)That said, I would like to support all of these where feasible, but I don't know what that looks like just yet - i.e. should the Parameter
concept be made public, and they can be specified on a JwtBuilder
and/or JwtParserBuilder
? It seems like this would be necessary to avoid conflict with existing JWTs that have conflicting fields with different value structures. But that could also open up a substantial part of the internal impl
classes to the API module that I'd rather not do.
In any event, this level of non-JOSE-spec parameters will have to wait until probably after 1.0.
So your approach of getting a Long
and converting it yourself is definitely the right approach at the moment.
Finally, thank you once again for a well-written / formatted issue - it really helps!
Also, just writing my thoughts for posterity: An ideal place for this JSON-to-Object unmarshalling behavior would likely be done via the the underlying JSON processor (Jackson, GSON, etc) since those libraries are purpose-built for JSON-to-Java-Instance conversion logic (well, except org.json
😞 ).
For example, Jackson and GSON can take any field and unmarshall it into whatever Java object type you prefer before JJWT ever gets the Map<String,?>
value, so just calling claims.get("auth_time")
would return an already-constructed Date/Instant/whatever instance. For example:
Instant authTime = claims.get("auth_time", Instant.class);
We (JJWT) don't really want to be in the business of JSON-to-Java unmarshalling when other libraries are wholly dedicated to this concept. That is, we don't want to 'reinvent the wheel' and we'd rather 'stand on the shoulders of giants' for this type of functionality if we can.
Is your feature request related to a problem? Please describe. "auth_time" is not part of the default fields in
Claims
. When we need to read it, we cannot useclaims.get("auth_time", Date.class)
because the parameter is in seconds and java.util.Date requires milliseconds.Describe the solution you'd like Ideally all the Authentication Information Claims (
auth_time
,acr
,amr
) added as getters inClaims
, or justauth_time
added inDefaultClaims.isSpecDate
, to be able to do e.g.claims.get("auth_time", Date.class)
.Describe alternatives you've considered Instead of reading it as a Date directly, we need to do something like:
var authTimeSeconds = claims.get("auth_time", Long.class);
var authTime = authTimeSeconds == null ? null : new Date(authTimeSeconds * 1000);
Additional context See https://datatracker.ietf.org/doc/html/rfc9068#section-2.2.1