Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify redirection proposal. See #117. #118

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Clarify redirection proposal. See #117. #118

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 24 additions & 19 deletions draft-ietf-oauth-v2-1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -533,11 +533,13 @@ for certificate validation and other security considerations.

This specification makes extensive use of HTTP redirections, in which
the client or the authorization server directs the resource owner's
user agent to another destination. While the examples in this
specification show the use of the HTTP 302 status code, any other
method available via the user agent to accomplish this redirection,
with the exception of HTTP 307, is allowed and is considered to be an
implementation detail. See {{redirect_307}} for details.
user agent to another destination.
While this specification
forbids the use of the 307 status code (see {{redirect_307}})
and illustrates the use of the 302 status code,
any other mechanism to accomplish the above redirection
is legitimate and is considered as an implementation detail as long as
it does not expose user credentials to untrusted parties.


## Interoperability
Expand Down Expand Up @@ -966,35 +968,38 @@ Extension grant types MAY define additional endpoints as needed.
## Authorization Endpoint

The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant. The authorization server
MUST first verify the identity of the resource owner. The way in
which the authorization server authenticates the resource owner
owner and obtain an authorization grant. The AS
MUST first authenticate the resource owner. The way in
which the AS authenticates the resource owner
(e.g., username and password login, session cookies) is beyond the
scope of this specification.

The means through which the client obtains the location of the
The means through which the client obtains the URL of the
ioggstream marked this conversation as resolved.
Show resolved Hide resolved
authorization endpoint are beyond the scope of this specification,
but the location is typically provided in the service documentation,
but the URL is typically provided in the service documentation,
or in the authorization server's metadata document ({{RFC8414}}).

The endpoint URI MAY include an "application/x-www-form-urlencoded"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's a location, it's an URL, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is in there to make sure clients don't make assumptions that the authorization server URL might not contain a query string. Also note that just below this there's a limit that the URL can't contain a fragment, so I think it's worth pointing out still.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is in there to make sure clients don't make assumptions that the authorization server URL might not contain a query string

I don't understand how this is related to the query string. IIUC, both URI and URL can have a query component:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but without an explicit mention, I suspect a lot of people would assume the URL would not contain a query string, especially because it's pretty uncommon for it to do so in practice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without an explicit mention

we explicitly mention the query component in the lines below - that are not removed - so people are told that URLs have query component.

@aaronpk

The authorization endpoint URL:

- MUST NOT include a fragment component;
- MAY include an "application/x-www-form-urlencoded"
formatted query component {{WHATWG.URL}},
which MUST be retained when adding additional query parameters. The
endpoint URI MUST NOT include a fragment component.
which MUST be retained when adding additional query parameters.

The authorization server MUST support the use of the HTTP `GET`
method Section 9.3.1 of {{RFC9110}} for the authorization endpoint and MAY support
the `POST` method (Section 9.3.3 of RFC9110) as well.
The authorization endpoint
MUST support GET requests (see Section 9.3.1 of {{RFC9110}})
and MAY support POST requests (see Section 9.3.3 of {{RFC9110}}).

The authorization server MUST ignore unrecognized request parameters.
The authorization endpoint MUST ignore unrecognized request parameters.

Request and response parameters
defined by this specification MUST NOT be included more than once.
Parameters sent without a value MUST be treated as if they were
omitted from the request.

An authorization server that redirects a request potentially containing
user credentials MUST avoid forwarding these user credentials accidentally
An authorization endpoint that redirects a request potentially containing
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aaronpk I reworded it removing normative language. This is because we cannot forbid to accidentally do something ;) instead it is better to suggest how to mitigate the risk.

user credentials is expected to define a trust boundary and to not
forward these credentials outside it
(see {{redirect_307}} for details).

## Token Endpoint
Expand Down