Phil Hunt said: > The only other issue would be determining whether the token is obtained via > an OAuth profile or > via some default profile. That could be handled with > something like: > > WWW-Authenticate: Basic realm="somerealm" > WWW-Authenticate: MAC realm="somerealm" > WWW-Authenticate: OAuth > token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyyy" > > The above would suggest that MAC tokens could be used alone as described in > some specification > for "MAC". However, the presence of the OAuth header > indicates that MAC and BEARER tokens can > be used in the OAuth pattern. > > I think this allows both de-coupling of tokens from OAuth but also informs > clients what tokens > can be used with OAuth. > > There may be other ways to do this. But it does help with the decoupling.
I agree that this is a good approach. A separate WWW-Authenticate header indicating that an OAuth delegation flow can be used to get access. I am not sure that you need to token="MAC;BEARER" at this point -- you can get that detail from the token response. Torsten Lodderstedt said: > I would expect the WWW-Authenticate header to return all the data required to > obtain the credentials/tokens, such as > > WWW-Authenticate: MAC realm="somerealm", tokenUrl="yyyyy&token_secret=yes" > WWW-Authenticate: BEARER realm="somerealm", tokenUrl=""yyyyy" I don't really like this approach. Existing WWW-Auth headers do NOT "return all the data required to obtain the credentials". They assume the client already has the credentials -- perhaps from a config file, perhaps from prompting a user. I don't think we can add tokenUrl etc to existing (non-OAuth-specific) auth schemes -- the existing specs and existing implementations just don't support it. That shouldn't mean those schemes cannot be used for the authentication part of an OAuth authorization flow, though. I would expect a 401 HTTP error response to return all the data required (except any client credentials (if required)) for the client to make a successful request. Or at least the data required for the next step towards making a successful request (eg an authorization URI). -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
