Opened 14 years ago
Closed 11 years ago
#78 closed design (fixed)
Relationship between 401, Authorization and WWW-Authenticate
| Reported by: | mnot@… | Owned by: | julian.reschke@… |
|---|---|---|---|
| Priority: | later | Milestone: | 16 |
| Component: | p7-auth | Severity: | Active WG Document |
| Keywords: | Cc: |
Description
Are these mechanisms exclusive? I.e., can they only be used together, or can a cookie-based authentication scheme (for example) use 401?
Attachments (1)
Change History (15)
comment:1 Changed 14 years ago by mnot@…
- Milestone changed from 01 to d00
comment:2 Changed 14 years ago by fielding@…
- Component set to auth
- Milestone d00 deleted
comment:3 Changed 14 years ago by mnot@…
- Milestone set to unassigned
comment:4 Changed 13 years ago by mnot@…
Note that some want to put WWW-Authenticate on 200 responses; see <http://www.w3.org/mid/492EEB95.9050001@gmx.de>.
comment:5 Changed 12 years ago by t.broyer@…
Re. the use of WWW-Authenticate in non-401/407 responses, FWIW: http://lists.w3.org/Archives/Public/public-web-security/2010Jan/0042.html
comment:6 Changed 12 years ago by mnot@…
- Priority set to low
- Severity set to Active WG Document
comment:7 Changed 12 years ago by julian.reschke@…
- Owner set to julian.reschke@…
comment:8 Changed 12 years ago by julian.reschke@…
I just checked the history of this bug, following several threads, and it appears this is really a *set* of issues...
- Relation between status code 401 and WWW-Authenticate
401 responses MUST include a WWW-Authenticate, but the opposite is not true.
Should we state more clearly in <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-11.html#header.www-authenticate> what this field means on a 2xx response? Any response?
- Relation between WWW-Authenticate and Authorization fields?
Does every authentication scheme need to specify the credentials in "Authorization"? <http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00> doesn't, and this doesn't seem to be a problem in practice (as long as cacheability is properly addressed)
- Should we specify how to handle a 401/WWW-Authenticate that does not contain any known schemes?
It appears all browsers nowadays display the message payload, which clearly is the right thing to do if we ever want to deploy new schemes.
Given the fact that implementations do the right thing, do we need to say more?
comment:9 Changed 11 years ago by julian.reschke@…
1) Yes, state what it means to get WWW-A on non-401. ("Authenticating may affect the response you got")
2) Yes, Authorization needs to be set because of caching implications.
Changed 11 years ago by julian.reschke@…
comment:10 Changed 11 years ago by julian.reschke@…
comment:11 Changed 11 years ago by julian.reschke@…
- Resolution set to incorporated
- Status changed from new to closed
comment:12 Changed 11 years ago by julian.reschke@…
- Milestone changed from unassigned to 16
comment:13 Changed 11 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:14 Changed 11 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
I don't think I understand this ticket. Is it an issue or a discussion item?
401 requires WWW-Authenticate. 401 is specifically designed to signal the use of HTTP authentication. I don't think it makes any sense to use it for cookie-based authentication, since the client is completely unaware that the cookies are being used for auth.