Okay, this is hardly complete, but it satisfies my research needs for the day.

RFC 2617 spells out authentication protocols. I found RFC 2617 to have the following paragraph:

2 Basic Authentication Scheme

The "basic" authentication scheme is based on the model that the
client must authenticate itself with a user-ID and a password for
each realm.  The realm value should be considered an opaque string
which can only be compared for equality with other realms on that 
server. The server will service the request only if it can validate
the user-ID and password for the protection space of the 
Request-URI.  There are no optional authentication parameters.

For Basic, the framework above is utilized as follows:

    challenge   = "Basic" realm
    credentials = "Basic" basic-credentials

Upon receipt of an unauthorized request for a URI within the
protection space, the origin server MAY respond with a challenge 
like the following:

     WWW-Authenticate: Basic realm="WallyWorld"

where "WallyWorld" is the string assigned by the server to identify
the protection space of the Request-URI. A proxy may respond with 
the same challenge using the Proxy-Authenticate header field.

To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 [7]
encoded string in the credentials.

     basic-credentials = base64-user-pass
     base64-user-pass  = <base64 [4] encoding of user-pass,
                      except not limited to 76 char/line>
     user-pass   = userid ":" password
     userid      = *<TEXT excluding ":">
     password    = *TEXT

Userids might be case sensitive.

If the user agent wishes to send the userid "Aladdin" and password
"open sesame", it would use the following header field:

     Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value 
of the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.
Similarly, when a client sends a request to a proxy, it may reuse a
userid and password in the Proxy-Authorization header field without
receiving another challenge from the proxy server. See section 4 for
security considerations associated with Basic authentication.
[download]

It also has this blurb when talking about the Digest method of authentication:

Because the client is required to return the value of the opaque
directive given to it by the server for the duration of a session,
the opaque data may be used to transport authentication session 
state information. (Note that any such use can also be 
accomplished more easily and safely by including the state in 
the nonce.) For example, a server could be responsible for 
authenticating content that actually sits on another server. It would 
achieve this by having the first 401 response include a domain directi
+ve 
whose value includes a URI on the second server, and an opaque directi
+ve 
whose value contains the state information. The client will retry the 
+request,
at which time the server might respond with a 301/302 redirection,
pointing to the URI on the second server. The client will follow the
redirection, and pass an Authorization header , including the
<opaque> data.
[download]

Which sounds like exactly what you are trying to do, so it may or may not be possible with the basic method. I suggest some experimentation (remember you can send named parameters to redirect() ) to see if you can get it to work. Please let us know what progress (or lack) you make.