I've just seen, the current draft already specifies an attribute
"authorization-uri" for the WWW-Authenticate header. Is this attribute
intended for announcing the authorization servers endpoint?
I don't think the example implies discovery. As far as I understood,
it just uses the same addresses for both protected resource and
authorization server. This might work for some deployments, it won't
work for installation with a single authorization server authorizing
access to multiple resources with different adresses.
I like the idea of using the protected resources realm as resource
specification in the authorization server requests. To enhance the
idea we need some kind of endpoint discovery. The simplest way would
be to include another parameter in the WWW-Authenticate response
indicating the authorization servers endpoint, e.g.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth realm='example',
endpoint='authorization.example.com'
According to http://www.ietf.org/rfc/rfc2617.txt (Basic/Digest Authn
Spec) this should be a legal usage of the WW-Authenticate header. An
example of a WWW-Authenticate header for Digest authentication is:
WWW-Authenticate: Digest realm="testre...@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
regards,
Torsten.
Presumably, the realm was used to discover the token issuance endpoints.
Why wouldn't the discovered URL of the access token endpoint dictate
realm, and why can't the realm then be implicit beyond discovery?
-----Original Message-----
From: Eran Hammer-Lahav<e...@hueniverse.com>
To: OAuth WG<oauth@ietf.org>
Subject: [OAUTH-WG] Scope using Realm idea
Date: Fri, 2 Apr 2010 09:18:36 -0700
This is half baked but I wanted to get people's reaction:
Clients tries accessing a resource with or without an access token:
GET /resource/1 HTTP/1.1
Host: server.example.com
The server replies with:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth realm='example'
Clients requests an access token (using the client credentials flow) and
includes the requested realm (line breaks for display purposes):
POST /access_token HTTP/1.1
Host: server.example.com
client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&
mode=flow_client&realm=example
The server issues a access token capable of accessing the resource
realm.
This means one new parameter on the request side which is already
baked into
the 401 response in a standard way.
Thoughts?
EHL
_______________________________________________
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
_______________________________________________
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
