1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
---
breadcrumbs:
- - /spdy
- SPDY
page_name: spdy-authentication
title: SPDY Server and Proxy Authentication
---
Support for Server and Proxy Authentication in SPDY is very similar to Server
and Proxy Authentication in HTTP.
## Server Authentication
When a client sends a request to an origin server that requires authentication,
the server can reply with a `401 Unauthorized`" response, and a
`WWW-Authenticate` header that defines the authentication scheme to be used. The
client then retries the request with an `Authorization` header appropriate to
the specified authentication scheme.
There are four options for sever authentication, Basic, Digest, NTLM and
Negotiate (SPNEGO). The first two options were defined in [RFC
2617](http://www.ietf.org/rfc/rfc2617.txt), and are stateless. The second two
options were developed by Microsoft and specified in [RFC
4559](http://www.ietf.org/rfc/rfc4559.txt), and are stateful; otherwise known as
multi-round authentication, or connection authentication.
### Stateless Authentication
Both Basic and Digest Server Authentication are stateless. These schemes define
ways for the browser to encode a username and password in the HTTP request which
the server can verify. In the case of Basic Auth, the client simply base64
encodes the password. In the case of Digest, the client hashes the username,
password, and a variety of other attributes together. Once a server requests
Basic or Digest Authentication, the client is able to generate a correct
`Authorization` header for any subsequent request to the same server.
Basic and Digest authentication is handled in SPDY in much the same way as with
HTTP. Here is a sample SPDY session using Basic authentication:
```none
Client Server
------ ------
*** Client makes initial, unauthenticated request to the server.
|------------------------------>|
| 1) SYN_STREAM |
| stream_id = 1 |
| url = http://example.com/a |
| |
|<------------------------------|
| 2) SYN_REPLY |
| stream_id = 1 |
| status = 401 |
| www-authenticate = Basic |
| |
*** Client retries request with authorization header.
|------------------------------>|
| 3) SYN_STREAM |
| stream_id = 3 |
| url = http://example.com/a |
| authorization = Basic XXX |
|<------------------------------|
| 4) SYN_REPLY |
| stream_id = 3 |
| status = 200 |
| |
*** Client request next resource with authorization header.
|------------------------------>|
| 5) SYN_STREAM |
| stream_id = 5 |
| url = http://example.com/b |
| authorization = Basic XXX |
|<------------------------------|
| 4) SYN_REPLY |
| stream_id = 5 |
| status = 200 |
| |
```
### Stateful Authentication
### The NTLM and Negotiate Authentication scheme are more complicated. Instead of enabling the browser to generate an `Authorization` header which can be used for subsequent requests to the server, these schemes attempt to authenticate the connection. After the authentication is complete, the server marks the connection as authorized, and the client sends subsequent requests without any `Authorization` header.
Multi-round authentication is handled in SPDY in much the same way as with HTTP.
A new stream is created for each round in the process, corresponding to a
request/response pair in the HTTP process.
```none
Client Server
------ ------
*** Client makes initial, unauthenticated request to the server.
|---------------------------------->|
| 1) SYN_STREAM |
| stream_id = 1 |
| url = http://example.com/a |
| |
|<----------------------------------|
| 2) SYN_REPLY |
| stream_id = 1 |
| status = 401 |
| www-authenticate = Negotiate |
| |
*** Client retries request with authorization header.
|---------------------------------->|
| 3) SYN_STREAM |
| stream_id = 3 |
| url = http://example.com/a |
| authorization = Negotiate AA |
|<----------------------------------|
| 4) SYN_REPLY |
| stream_id = 3 |
| status = 401 |
| www-authenticate = Negotiate BB|
| |
*** Client retries request with authorization header.
|---------------------------------->|
| 3) SYN_STREAM |
| stream_id = 3 |
| url = http://example.com/a |
| authorization = Negotiate CC |
|<----------------------------------|
| 4) SYN_REPLY |
| stream_id = 3 |
| status = 200 |
| www-authenticate = Negotiate DD|
| |
*** Client request next resource without authorization header.
|---------------------------------->|
| 5) SYN_STREAM |
| stream_id = 5 |
| url = http://example.com/b |
| |
|<----------------------------------|
| 4) SYN_REPLY |
| stream_id = 5 |
| status = 200 |
| |
```
However, one difference in how stateful authentication is handled between HTTP
and SPDY results from the multiplexed nature of SPDY sessions. With a single
SPDY session, a client can sent multiple requests in parallel before receiving
the first response. This complicates the stateful authentication schemes which
are attempting to perform a single authentication of the **connection**. If the
server receives two requests (streams 1 and 3) on an unauthenticated session, it
will reply 401 Unauthorized to each stream. However, it is not entirely clear
how the authentication should continue.
One option would be for the client to complete the authentication on the first
unauthorized stream and then assume that the connection will then be
authenticated and continue issuing requests without authorization headers.
However, it is possible for different resources on the same server to require
different authentication. These resources would need to specify different
"realms" when requesting authentication. When the client receives a 401, it
would need to be aware of any outstanding authentication transaction for that
same realm, and wait for it to complete.
An alternative option would be for the client to complete the authentication for
both unauthorized streams. However, as currently specified, there is no obvious
way to distinguish the 2nd attempt to request the first resource from the 2nd
attempt to request the second resource. It is possible the the URL in the
headers might be identical. It would seem to require that the client pass a
`X-Associated-Stream, or X-Authorization-Context` header in each subsequent
authentication request so the server is able to correctly understand the context
of the request.
## Proxy Authentication
When a client sends a request to a proxy server that requires authentication,
the same basic protocol is used. Instead of a 401 Unauthorized response, the
proxy can reply with a `407 Proxy Authentication Required` response, and a
`Proxy-Authenticate` header instead of an Authenticate. The client then retries
the request with a `Proxy-Authorization` header in place of an Authorization
header.
|
