[OPENAM-12759] During authorization code grant flow - max_age should be a number, not a string Created: 28/Mar/18  Updated: 15/Sep/20  Resolved: 05/May/20

Status: Resolved
Project: OpenAM
Component/s: OpenID Connect
Affects Version/s: 5.5.1, 6.0.0, 6.5.0, 6.5.0.1, 6.0.0.7, 6.5.1, 6.5.0.2, 6.5.2, 6.5.2.1, 6.5.2.2, 6.5.2.3
Fix Version/s: 5.5.3, 6.0.1, 7.0.0, 6.5.3

Type: Bug Priority: Major
Reporter: Quentin CASTEL [X] (Inactive) Assignee: C-Weng C
Resolution: Fixed Votes: 0
Labels: EDISON, FIN-PSD2-OB, Must-Fix, OpenBanking, PSD2, VERT-FIN
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
is related to OPENAM-16395 HTTP 302 error=login_required instead... Open
Target Version/s:
Sprint: AM Sustaining Sprint 73, AM Sustaining Sprint 74
Story Points: 3
Needs backport:
Yes
Support Ticket IDs:
Verified Version/s:
Needs QA verification:
Yes
Functional tests:
Yes
Are the reproduction steps defined?:
Yes and I used the same an in the description

 Description   

Bug description

When doing an authorization code flow, you can specify an option call max_age.
Currently, AM is expecting this value to be a String but the standard says it should be a number.

How to reproduce the issue

Do an authorization code grant flow with the option max_age.

Expected behaviour

the login page

Current behaviour

An internal server error that is actually catch up and returned as "The request requires login" which makes completely no sense.

Work around

Use max age as a string



 Comments   
Comment by Ľubomír Mlích [ 22/Jun/20 ]

You know, hackers don't care if "" is legal according to specification, they care if it is possible to exploit not expected input - I don't know if this is exploitable, but I created OPENAM-16395

Comment by Ľubomír Mlích [ 22/Jun/20 ]

Reproduced in ForgeRock Access Management 6.5.2 Build 314d553429 (2019-June-17 15:07)
Verified as fixed in ForgeRock Access Management 6.5.3-M5 Build c61acc98e9 (2020-June-15 10:38)

Generated at Wed Sep 30 03:29:34 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.