[OPENAM-1930] OAuth2 Authorization Code Grant – null or missing
redirect_uri parameter should display error page, not redirect Created: 03/Dec/12
Updated:
06/Nov/14 Resolved: 05/Nov/13
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
OpenAM
oauth2
10.1.0-Xpress
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
GErickson
Fixed
None
Not Specified
QA Assignee:
GErickson
10.1.0-Xpress
Priority:
Assignee:
Votes:
Major
jason
0
Not Specified
Not Specified
Description
When using the Authorization Code Grant flow with more than one Redirection URIs specified,
if the redirect_uri parameter is specified with a null value, or if it is not specified at all, the
authorization server should not redirect the browser to the redirect_uri, but "inform the resource
owner of the error" using the OAuth2 Error Page. Cf. RFC 6749 §4.1.2.1.
Currently, the OpenAM authorization server incorrectly redirects the browser to the OpenAM
login page. After a successful login, the user-agent is redirected to the redirect_uri with an error
parameter, but this is neither 1) the required error response nor 2) the order specified in the spec
(validate, then login).
Found by test case OAM-40:Invalid parameter client_id
(http://172.18.1.12/linkto.php?tprojectPrefix=OAM&item=testcase&id=OAM-40).
Comments
Comment by jason [ 05/Dec/12 ]
Committed a partial fix for this issue to trunk. The fix fixes the error message so that it is displayed in an error p
redirected. The flow of events (login then error display) will be fixed in 10.1 FINAL with the removal of the rest
Comment by GErickson [ 14/Dec/12 ]
In 10.1.0-Xpress RC1, this is partially still broken. If redirect_uri is null, OpenAM currently returns an error pag
not set" and also redirects the user-agent to the authorize(!!) endpoint with error and error_description parameter
parameters. However, if redirect_uri is omitted, OpenAM correctly returns HTTP status 400 and an error page th
the error. A null parameter should return the same error as if it was as omitted (cf. §3.1, though I'm ok with a dif
error_description, as used elsewhere, as the spec seems to be ambiguous on that point).
Comment by GErickson [ 14/Dec/12 ]
The #2) order problem of requiring an end-user login before reporting errors has been moved to .
Comment by jason [ 15/Dec/12 ]
This is partially still broken. If redirect_uri is null, OpenAM currently returns an error page that says "Ty
and also redirects the user-agent to the authorize(!!) endpoint with error and error_description parameters
query parameters.
That error happens when you do not set the grant_type or response_type. and redirecting in that case is what is su
Never the less I ran the authorization code flow with ommited and null values and in both cases got an error page
redirection.
Please give me the URL command you ran.
Comment by GErickson [ 17/Dec/12 ]
This is fixed in trunk rev 3902 (between 10.1.0-Xpress RC1 & RC2). The URLs from the test case are
http://openam1.internal.forgerock.com:8080/openam/oauth2/authorize?response_type=code&client_id=OAuth2
and openam1.internal.forgerock.com:8080/openam/oauth2/authorize?response_type=code&client_id=OAuth2Cl
Comment by GErickson [ 21/Dec/12 ]
Fixed in 10.1.0-Xpress, SVN rev 3955.
Comment by GErickson [ 05/Nov/13 ]
Re-opened to change component from oauth to oauth2.
Comment by Cyril Grosjean [ 06/Nov/14 ]
When testing with OpenAM 11.0, a missing redirect_uri in the code grant flow returns an error page, which is ex
to this JIRA ticket.
But according to the OAuth2 RFC, §4.1.1 (http://tools.ietf.org/html/rfc6749#section-4.1.1), the redirect_uri is op
so it looks like OpenAM behaviour is not fully compliant with the RFC in this particular case. Right ?
Generated at Fri Feb 05 11:23:00 GMT 2016 using JIRA 6.3.9#6339sha1:46fa26140bf81c66e10e6f784903d4bfb1a521ae.