Hi James,
Am 06.02.2011 14:07, schrieb Manger, James H:
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.
I don't think a WWW-Authenticate header is the right way to transmit
supplementary data to other WWW-Authenticate headers, such as hints how
to obtain credentials (e.g. OAuth). If such data belong to a
authentication scheme, then it should be provided with the respective
WWW-Authentication header. Alternatively, some other discovery
mechanismus could be used, such as host-meta on the resource server.
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).
What the difference to my proposal? authorizationURL instead of tokenURL?
regards,
Torsten.
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
