JARM: the type of expires_in in authorization response JWT
4.1.2. Response Type "token" in JARM (Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0) shows an example of authorization response as follows:
{
"iss":"https://accounts.example.com",
"aud":"s6BhdRkqt3",
"exp":1311281970,
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"state":"S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw",
"token_type":"bearer",
"expires_in":"3600",
"scope":"example"
}
In the example, the type of the value of the expires_in is "string", but it should be "number" if we strictly follow the definition of expires_in which is found in A.14. "expires_in" Syntax in RFC 6749.
A.14. "expires_in" Syntax
The "expires_in" element is defined in Sections 4.2.2 and 5.1:
expires-in = 1*DIGIT
Comments (6)
-
-
reporter In order to say "in JARM all the authorization response parameters are also strings", the specification would also have to state "
exp
is not regarded as an authorization response parameter (, so its value doesn't have to be a string)". Otherwise, the value of theexp
claim would have to become a string, too. -
It would define how the authorization response parameters are encoded into the JWT but not the standard JWT claims.
Something along the lines of '... by encoding the authentication response parameters as claims of the JWT, with each parameter name as the claim name and its value as a JSON string."
-
Pull request #83 proposes to address this by saying that "Authorization endpoint response parameter names and string values are included as JSON strings and numerical values (e.g.,
expires_in
value) are included as JSON numbers." while also changing theexpires_in
value in the example to be a number rather than a string (i.e. no quotes). -
- changed status to resolved
-
pull request #83 was merged at f10eba4 to fix this
- Log in to comment
The syntax and definition of "expires_in" means it could be represented as a JSON number. However, in the normal fragment encoding all the authorization response parameters are strings. So it arguably might be more straightforward to just say that in JARM all the authorization response parameters are also strings. Maybe.
One way or the other, JARM should probably be specific about it.
Should we decide to make "expires_in" a JSON number, some text along the lines of the following taken from https://tools.ietf.org/html/rfc6749?#section-5.1 might be good enough.
as well as changing the example to
"expires_in":3600,