On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt
wrote:
> why that? If there will be a signature proposal for resource server access,
> the same (simplified?) model could be applied to the authz server's API.
Sure. Other folks have used signed URLs in this kind of protocol as
well: http://d
+1 for "OAuth2"
Brian Eaton schrieb:
Draft 10 switched from "Token" scheme in the authorization header to
"OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
"Token" is ugly as sin, but is better than "OAuth".
Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#pag
Marius Scurtescu schrieb:
On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
wrote:
I have a question concerning the OAuth philosophy: How many resource servers
may be managed by a single OAuth authorization server? (a) A single resource
server or (b) several of them exposing different res
No hang on. A single auth server should be able to handle man resource
servers.
It only gets hairy I think if you want multiple auth servers.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Torsten Lodderstedt
> Sent: Wednesday, July 1
I haven't seen the proposed discovery stuff yet, but discovery in the
SASL stuff will solve this, and so would discovery advertized from the
resource server.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Torsten Lodderstedt
> Sent: Wed
"Password" doesn't seem to be the right analogy. You don't (or really
shouldn't) store passwords in plain text or in cookies.
How about "cookies"? Most web developers understand that cookies are used as
a token that grants access to resources. We've also called these tokens"API
cookies" when tryin
why that? If there will be a signature proposal for resource server
access, the same (simplified?) model could be applied to the authz
server's API.
And as I pointed out in my original posting, I see this as a _further_
option not the only one. While it is technically more complicated, it
has i
Yeah ... seems like OAuth is definitely suited for different resource services
- as written, scope takes care of that. For instance Facebook offers messages,
photos, and a bunch of other services, across two different APIs (the Graph and
REST) and we distinguish permissions using scope.
As othe
We implement the second option in our SSO protocol.
Am 15.07.2010 um 01:02 schrieb Brian Eaton :
> On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
> wrote:
>>> The second request (as you pointed out in your original mail) is
>>> currently used to verify the client identity. Do you have
Token makes sense in the context of provisioning a more general token
auth header which we overload on. That said I'm glad we're getting
simpler.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Brian Eaton
> Sent: Wednesday, July 14,
On Wed, Jul 14, 2010 at 10:49 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Did I get you right? Your answer is: Oauth is not suited for deployments
> with different resource servers which rely in a single authz server?
>
> I don't know why you categorize this as "complex". Is it so
Did I get you right? Your answer is: Oauth is not suited for deployments with
different resource servers which rely in a single authz server?
I don't know why you categorize this as "complex". Is it so unusual to have
let's say mail, webstorage, telephony, and payment services?
At Deutsche Tel
Draft 10 switched from "Token" scheme in the authorization header to
"OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
"Token" is ugly as sin, but is better than "OAuth".
Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30
The problem with reusing "OAuth" i
On Tue, Jul 13, 2010 at 8:11 AM, Eran Hammer-Lahav wrote:
> - client credentials information was always problematic because people
> expressed interest in using it with pre-arranged authorizations, in which
> case, the client may be acting on behalf of an end-user.
...
> I suggested adding actual
On Wed, Jul 14, 2010 at 2:32 PM, Torsten Lodderstedt
wrote:
> We expected the clients to discard the old refresh token and to use the
> newly issued refresh token instead. The old refresh tokens is revoked
> instantly. Any attempt to use it afterwards is interpreted as a potential
> misuse because
On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
wrote:
>> The second request (as you pointed out in your original mail) is
>> currently used to verify the client identity. Do you have a
>> suggestion for an alternate mechanism?
>>
>
> A digital signature over the authz request? Alternatively
If your deployment is that complicated, even my discovery proposal is not going
to help you...
EHL
On Jul 14, 2010, at 18:37, "Marius Scurtescu" wrote:
> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
> wrote:
>> I have a question concerning the OAuth philosophy: How many resource se
On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
wrote:
> I have a question concerning the OAuth philosophy: How many resource servers
> may be managed by a single OAuth authorization server? (a) A single resource
> server or (b) several of them exposing different resource types?
>
> If the an
a - code in fragment
b - token in query
c - code and token in query
d - code and token split -10
EHL
On Jul 14, 2010, at 8:10, Eran Hammer-Lahav wrote:
> Please answer this based on actual use cases. When returning parameters
> using the redirection URI call, which of these combinations make
On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards wrote:
> Finally getting a chance to catchup and respond to this thread.
>
> Marius Scurtescu wrote:
>>
>> See comments bellow...
>>
>>
>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote:
>>
>>>
>>> Hallo Marius,
>>>
>>> thanks for your stateme
At some point this brings us back to 1.0...
EHL
On Jul 14, 2010, at 17:59, Torsten Lodderstedt wrote:
> Am 14.07.2010 23:52, schrieb Brian Eaton:
>> On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
>> wrote:
>>
>>> Yepp. That's an optimization of use case 2. That way the authz server d
I have a question concerning the OAuth philosophy: How many resource
servers may be managed by a single OAuth authorization server? (a) A
single resource server or (b) several of them exposing different
resource types?
If the answer is (b) then how is a particular resource server identified
i
Already in -10.
EHL
On Jul 14, 2010, at 14:46, Rob Richards wrote:
> Finally getting a chance to catchup and respond to this thread.
>
> Marius Scurtescu wrote:
>> See comments bellow...
>>
>>
>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote:
>>
>>> Hallo Marius,
>>>
>>> thanks
I do not quite understand the combination table: what are a, b, and c
parameters?
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, July 14, 2010 8:10 AM
To: OAuth WG
Subject: [OAUTH-WG] Quick survey:
Am 14.07.2010 23:52, schrieb Brian Eaton:
On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
wrote:
Yepp. That's an optimization of use case 2. That way the authz server does
not need to store the authorization transaction's results in a database and
there is no need to perform a a secon
On Wed, Jul 14, 2010 at 2:28 PM, William Mills wrote:
> We're trying to design around transport security with short expiration
> and single use tokens. SSL solves the problem.
No, we're not, and no, it doesn't.
The issue here is not that tokens are sent over unencrypted channels,
or unauthentic
On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
wrote:
> Yepp. That's an optimization of use case 2. That way the authz server does
> not need to store the authorization transaction's results in a database and
> there is no need to perform a a second request.
The authorization server doesn't
On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt
wrote:
I would also like to see support for b. In this case, additional means for
client authentication should be considered.
b is token on query string?
What's the use case for that?
Yepp. That's an optimization of use case
what about guessing/brute force attacks on the code? Supposed an
authorization server issuing tokens for a client w/o secret. Then the
number of attempts needed to obtain a token issued to that client only
depends on the length and randomness of the code. Should the spec state
something about t
On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt
wrote:
> I would also like to see support for b. In this case, additional means for
> client authentication should be considered.
b is token on query string?
What's the use case for that?
___
OAuth m
2 is a must have from my point of view.
I would also like to see support for b. In this case, additional means
for client authentication should be considered.
regards,
Torsten.
Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of th
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
wrote:
We plan to issue new refresh tokens for certain clients only (mobile, desktop),
it's part of the client-related policy. So the behavior for a particular client
is predictable.
Nice.
Would you be willing to expand on the c
We're trying to design around transport security with short expiration
and single use tokens. SSL solves the problem
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesday, July 14, 2010 1:35 PM
> To: William Mills
> Cc: Eran Hammer-Lahav; OAuth WG
> Subje
On Wed, Jul 14, 2010 at 11:58 AM, William Mills wrote:
> If I can see things go by on the fly I can submit the token late and
> mess with the user by revoking their session.
Meh.
If the best the attacker can do in those circumstances is DOS, we're
in good shape.
Bear in mind that if we do nothi
If I can see things go by on the fly I can submit the token late and
mess with the user by revoking their session.
>
> > It closes one door but opens a DOS attack.
>
> What's the DOS attack?
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/
2 and 3 are practically most interesting imho.
(b) is interesting in that if a client application does have SSL, then it's
the simplest flow of all.
-Naitik
On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav wrote:
> Please answer this based on actual use cases. When returning parameters
> usi
Finally getting a chance to catchup and respond to this thread.
Marius Scurtescu wrote:
See comments bellow...
On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote:
Hallo Marius,
thanks for your statement.
Your idea of a migration flow is quite good and necessary.
But I still doubt, if
I caught up on the thread and with Luke yesterday afternoon and am fine with
the user-agent flow using the fragment in the token and code case.
On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote:
> I can't parse this diagam, but here's my take:
>
> - web server flow should always return just a
I can't parse this diagam, but here's my take:
- web server flow should always return just a code.
parameter always goes in the query string
it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh toke
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
wrote:
> We plan to issue new refresh tokens for certain clients only (mobile,
> desktop),
> it's part of the client-related policy. So the behavior for a particular
> client is predictable.
Nice.
Would you be willing to expand on the curren
On Wed, Jul 14, 2010 at 8:25 AM, Andrew Arnott wrote:
> Um, if the signing key is lost, you're sunk. Forget about the database,
> with the signing key you can forge your own tokens till doomsday (which will
> come much more quickly). The keys are definitely the most confidential part
> of the sy
On Tue, Jul 13, 2010 at 9:40 PM, William Mills wrote:
> That's even worse I think, it's a harder problem.
Revoking previously issued refresh tokens is pretty easy.
Revoking the corresponding access tokens is hard in general, but in
some environments is feasible.
> Why do we want to revoke previ
Again, it's a good security optimization, and it makes sense for large
internet providers. But I don't think this argument holds for small
intranet providers, where there won't be proxies in the middle and many
of the clients will largely be non-browser-based and cacheless anyway.
At least, that's
On Tue, Jul 13, 2010 at 2:59 PM, Brian Eaton wrote:
> the question is what happens if both the
> signing key and the token database get compromised.
>
> Now that I think of it, you may have issues if the signing key alone
> is compromised. It depends how much other entropy you've added to the
>
Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of these combinations make sense?
| Code | Token | Code & Token
-+--+---+--
Fragment | a | 1 | 3
Query| 2 | b | c
Split* | n/a
45 matches
Mail list logo
