that's not the way WWW-Authenticate headers are used today. Instead the
resource server should return a single WWW-Authenticate header _per_
supported authentication scheme, such as
WWW-Authenticate: MAC realm="somerealm"
WWW-Authenticate: BEARER realm="somerealm"
furthermore, I think interdependencies among WWW-Authenticate headers as
suggested by Phil
WWW-Authenticate: OAuth
token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyy
could be rather fragile.
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"
Which raises the question whether the coupling between authentication schemes
and the OAuth2 core protocol is stronger than assumed.
please als see http://www.ietf.org/mail-archive/web/oauth/current/msg04988.html
regards,
Torsten.
Am 04.02.2011 22:39, schrieb William Mills:
I was thinking along the lines of simply returning the HTTP Authorization
header schemes that are supported. In the OAuth 2 context that would be
WWW-Authenticate: 401 error="blah blah blah" auth_types="Bearer MAC
Basic"
The client has to be aware of the authentication scheme names.
-bill
-----Original Message-----
From: Phil Hunt [mailto:[email protected]]
Sent: Friday, February 04, 2011 1:14 PM
To: William Mills
Cc: Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
2/10)
I agree, that is still to be defined. There seems to be some push back
on discovery, but this is likely warranted. If only because web sites
may have both browser clients and app clients.
In a previous message, I did suggest the web site return HTTP 401 as
below...
401 Unauthorized
WWW-Authenticate: Basic realm="tokenSvc"
WWW-Authenticate: Digest realm="tokenSvc"
WWW-Authenticate: Form
url="/clientAuthenticate.jsp",realm="tokenSvc"
It could also include other items for "MAC", etc.
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.
Phil
[email protected]
On 2011-02-04, at 11:44 AM, William Mills wrote:
I was thinking more about how the client knows what to use. The
ubiquitous "service documentation" may come in to play here. Some form
of serv ice discovery/webfinger thing could also be used.
-----Original Message-----
From: Phil Hunt [mailto:[email protected]]
Sent: Friday, February 04, 2011 11:37 AM
To: William Mills
Cc: Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
2/10)
Yes. This should be defined in each token type specification.
Phil
[email protected]
On 2011-02-04, at 11:29 AM, William Mills wrote:
The only challenge is to know what scheme to use and what the
nuances
are of how to present the credential.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Phil Hunt
Sent: Friday, February 04, 2011 9:42 AM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name
(deadline:
2/10)
OAuth should be able to support other token schemes.
Or conversely you don't have to have OAuth to use MAC, JWT, or
whatever.
Phil
[email protected]
On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote:
On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav
<[email protected]> wrote:
Hey Marius,
-----Original Message-----
From: Marius Scurtescu [mailto:[email protected]]
Sent: Thursday, February 03, 2011 10:36 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name
(deadline:
2/10)
On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav
<[email protected]> wrote:
2. Single OAuth2 scheme with sub-schemes
Define a single authentication scheme for all token types with
some
attribute used to detect which scheme is actually being used.
Benefits:
- single scheme, reuse of the 1.0 pattern.
Downsides:
- requires a new registry for authentication header
parameters.
How is this different from option 1? Wouldn't that need some
registry?
#1 relies on the existing practice of creating HTTP scheme names
(no
current registry but httpbis might be creating one), as well as
the
-12
token type registry. Using a sub-scheme means you also need a
registry
for the header attributes that each token type will need (unless
you
just don't care about using the same attribute name for different
needs).
Sure, there is no registry for schemes yet, but we would still
need
some coordination. The fact that a sub-scheme needs a registry
that
we
control is a benefit not a downside IMO.
- schemes are not easily reusable outside OAuth.
Sure. But I really don't see this group trying to create
generic
authentication
schemes.
MAC is exactly that.
May or may not be. My point is that this group is not focused on
creating generic authentication schemes. Are you aware of any
other
protocols that might use MAC or BEARER? Are we willing to put in
the
effort to create generic schemes? Is it our charter?
- existing frameworks usually switch on scheme name, not on
sub
scheme, which will cause difficulty in some deployments.
I can see this as a potential problem. But considering that
there
wasn't much
objection to use "OAuth" as a scheme name before (total overlap
with
OAuth 1, and the suggested solution was to look for the
signature
parameter) I don't see how this is suddenly an issue.
There was pretty strong objection to reusing OAuth.
Yes, because there was no sub-scheme nor version (and the grammar
was
totally broken). Even so, lots of implementations went ahead and
did
it. Were there any scheme switching issues we are aware of?
Do we have a concrete problem here or this is just theoretical?
This came up during the review of draft-hammer-http-token-auth
[1].
There was a long thread about it where people posted actual
framework
issues.
- potential to produce a very complicated scheme once many sub
schemes
are added.
Why? I would argue that this option actually produces more
uniform
schemes because it forces all of them to be name/value pairs.
Beyond
token_type everything is scheme specific. I really don't see
what
is very
complicate here.
It is still a single scheme with many different sub-schemes,
each
with different key-value pairs that may have conflicting meaning.
The
way I look at it is that if I try to fully implement this mega
scheme
(which means all its sub-schemes), it will likely be a complicated
task. On the other hand, if you split it across scheme name, we
already
have a well-established system in place to pick and choose HTTP
authentication schemes.
No one has to implement a mega scheme. All schemes must use
name/value
pairs and that's where the common part stops.
- requires its own discovery method for which schemes are
supported.
Why is this a downside only for this option?
Because the other options get this for free by using the WWW-
Authenticate header (since each scheme has a unique name). You can
list
multiple headers in the 401 response.
I thought we dropped WWW-Authenticate. Why cannot WWW-
Authenticate
work for sub-schemes as well?
Should I record your vote for #2?
#2 or #3
Thanks,
Marius
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
