FAPI2SP appears to permit response_types "id_token", "id_token token" and "none"
FAPI2SP appears to permit response_types "id_token", "id_token token" and "none" - the only text I could find that’s relevant is these two statements, neither of which would prevent this:
shall reject requests using the resource owner password credentials grant or the implicit grant described in [RFC6749] or the hybrid flow as described in [OIDC]¶
shall support the authorization code grant (
response_type=code
&grant_type=authorization_code
) described in [RFC6749]¶
[technically, “id_token token” is probably not permitted because I don’t think there’s any way to issue a sender constrained access token from the authorization endpoint.]
Comments (10)
-
reporter -
It was my suggestion so I should probably offer some text. Here’s a stab at rewording that first sentence:
“shall reject requests using the resource owner password credentials grant, the implicit grant described in [RFC6749], the implicit or hybrid flows as described in [OIDC], or the
none
response type.”
a ref for none may or may not be needed https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#none
-
discussed on the call and suggestion to further clarify:
- don’t issue access token from authorization endpoint
- don’t issue id token from authorization endpoint
-
suggestion for auth code flow section:
1. shall support the authorization code grant (`response_type=code` & `grant_type=authorization_code`) described in [@!RFC6749];
to change to make clear only that response type
-
Close to the end of the call the following suggestion was made (this is a rough summary)
Under General Requirements the
shall reject requests using the resource owner password credentials grant or the implicit grant described in [RFC6749] or the hybrid flow as described in [OIDC]
may just end up being
shall reject requests using the resource owner password credentials grant
or it may end up being a combination of that, what brian suggested above and what Aaron mentioned on the call (about not issuing access and id tokens via frontchannel?
A section to add before Authorization Code Flow called Authorization Endpoint
For the Authorization Endpoint, Authorization servers
1. shall require the use of the
code
response type described in [RFC6749]The Authorization Code Flow section may stay as-is.
-
Just checked.
- shall require the use of the
code
response type described in [RFC6749]
As pointed out, “the use of” may be a bit vague. Perhaps
- shall require the value of
response_type
described in[@!RFC6749]
to becode
;
might be better.
- shall require the use of the
-
- changed status to open
Dave to create a PR.
-
-
assigned issue to
-
assigned issue to
-
-
- changed status to resolved
PR merged
- Log in to comment
Discussed on today’s call - consensus to just expand the wording so it covers the implicit from OIDC as well, and explicitly denies none.