[OAUTH-WG] Reusing refresh tokens and additional parameters when granting authorization

[Eric Cestari]

Hi,

I am currently implementing OAuth v2, and I have a couple questions:

- when a client requests an access token, with grant type "password" for 
example, can the authorization server resend the same refresh token from the 
last time the same client/resource owner combination requested an access token 
? That would prevent the auth database from being flooded with refresh tokens 
(which do not expire automatically) from badly behaving client, reusing the 
"password" grant type repeatedly.
Or did I overlook some security considerations?

- More about obtaining an access token: is it possible to send additional (and 
optional) parameters along when the client requests an access token ? The draft 
states "the authorization server SHOULD ignore unrecognized request 
parameters.", so I am thinking "yes". Am I correct ?

Thanks!
Cheers,
Eric Cestari

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Closing a few issues

[Alexey Melnikov]

Hi Barry,

Barry Leiba wrote:


There are three issues in the tracker that are just looking for
consensus on text that's in the document -- Eran had flagged them as
"pending consensus" in the -15 version.  Let's look at closing those
issues now.  The issues are

#8  4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code
http://trac.tools.ietf.org/wg/oauth/trac/ticket/8

#9  5.2, text for non-400 & 401 error conditions
http://trac.tools.ietf.org/wg/oauth/trac/ticket/9
 


These look fine to me.


#10 8.4. Defining Additional Error Codes
http://trac.tools.ietf.org/wg/oauth/trac/ticket/10
 


This is mostly fine, but I am wondering if the ACAP vendor name registry (RFC 6075), the 
OID vendor names, or DNS names can be recommended for the prefix (to satisfy the 
"SHOULD be prefixed by an identifying name when possible" requirement)?

Best Regards,
Alexey

--
Internet Messaging Team Lead, 
JID: same as my email address
twitter: aamelnikov

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Reusing refresh tokens and additional parameters when granting authorization

[Lodderstedt, Torsten]

Hi Eric,

>- when a client requests an access token, with grant type "password" for 
>>example, can the authorization server resend the same refresh token from >the 
>last time the same client/resource owner combination requested an >access 
>token ? That would prevent the auth database from being flooded with >refresh 
>tokens (which do not expire automatically) from badly behaving >client, 
>reusing the "password" grant type repeatedly.
>Or did I overlook some security considerations?

Your authorization server could provide the client with the same refresh token 
again. The question is whether the authorization server must ensure it is the 
same client _instance_ again. Otherwise, this might cause unintended impacts on 
other instances of the same client used by the same user on other devices. 

The spec does not prevent your authorization server from automatically expiring 
refresh tokens (e.g. after some idle time).

>- More about obtaining an access token: is it possible to send additional 
>>(and optional) parameters along when the client requests an access token ? 
>>The draft states "the authorization server SHOULD ignore unrecognized 
>>request parameters.", so I am thinking "yes". Am I correct ?

Doesn't section 8.2 answer this question?

Regards,
Torsten.

Thanks!
Cheers,
Eric Cestari

___
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

Re: [OAUTH-WG] Reusing refresh tokens and additional parameters when granting authorization

[Eric Cestari]

Thorsten, Justin,

Thank you for your answers, I know the spec would not address some of the 
points I raised, but I was pretty sure you had some best pratices in mind.
Le 3 mai 2011 à 14:48, Lodderstedt, Torsten a écrit :
>> - More about obtaining an access token: is it possible to send additional 
>> >(and optional) parameters along when the client requests an access token ? 
>> >The draft states "the authorization server SHOULD ignore unrecognized 
>> >request parameters.", so I am thinking "yes". Am I correct ?
> 
> Doesn't section 8.2 answer this question?

Indeed, massive overlook from my part, thank you!

Eric

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Closing a few issues

[Anthony Nadalin]

I propose that we close issue #12 (Restore WWW-Authenticate response to the 
framework specification) with no action, that is each extension would handle as 
they are doing now.

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry 
Leiba
Sent: Friday, April 29, 2011 11:05 AM
To: OAuth WG
Subject: [OAUTH-WG] Closing a few issues

There are three issues in the tracker that are just looking for consensus on 
text that's in the document -- Eran had flagged them as "pending consensus" in 
the -15 version.  Let's look at closing those issues now.  The issues are

#8  4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code
http://trac.tools.ietf.org/wg/oauth/trac/ticket/8

#9  5.2, text for non-400 & 401 error conditions
http://trac.tools.ietf.org/wg/oauth/trac/ticket/9

#10 8.4. Defining Additional Error Codes
http://trac.tools.ietf.org/wg/oauth/trac/ticket/10

I think these are non-controversial.  I'm aware of some conversation about 
perhaps tweaking the text to make sure it's clear what layer the status codes 
go into (for the redirects, it should be clear, but a slight text change might 
help).

Everyone, please review these.  They are short, and should be easy to confirm 
consensus on.  Please post any objection you have to closing these issues.  If 
you do have an objection, it would help if you could post alternative text that 
you'd be happy with.  Please post also if you think they're OK and ready to 
close.

I will close these issues next Friday, 6 May, if there are no unresolved 
objections.

Barry, as chair
___
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

Re: [OAUTH-WG] I-D Action:draft-oauth-dyn-reg-v1-02.txt

[Manger, James H]

Comments on the OAuth Dynamic Client Registration Protocol 
[draft-oauth-dyn-reg-v1-02]:

I found it hard to gleam from this draft where any trust in the client 
information being registered comes from. Sources could be: self-asserted; PKI 
with well-known roots; or DNS.

OpenID and WebID are two existing approaches for authenticating to a server you 
have never met before. A client logging in to an authorization server (AS) 
using one of these techniques then accessing a specific page could be treated 
as a registration.
[A variant of OpenID suitable for apps, as opposed to users, is sorely needed.]


Section 6: "Client Registration with Pushed Metadata"
The draft talks about an authorization server "verifying information received 
from the client" [6.2] but with no clues as to what is verified or how. Checks 
that client_name doesn't contain control characters, client_uri is 
syntactically correct, or that client_uri returns "200 OK" and text/html 
content are possible, but almost meaningless. They don't tell the AS that the 
values are appropriate for the client that it is talking to.

Section 7: " Client Registration with Pushed URL and Pulled Metadata"
Pushing a URL appears insecure. A malicious app POSTs another apps client_url 
(7.1) and gets a client_id and client_secret for that app in return. Perhaps 
signing the POSTed client_url helps (the draft says a client MAY do this), but 
it isn't obvious to me how the AS checks the signer is the right entity. Must 
the same certificate (or same key, or same cert subject...) be used to sign the 
POST and to serve the metadata the AS subsequently gets from 
https://.../.well-known/host-meta?


Section 6.2: "Client Registration Response" [and 6.3 and 7.3 and 7.4]
This looks like another version of an OAuth2 token response 
[draft-ietf-oauth-v2-15#section-5.1]. It conveys similar data 
(dynamically-issued credentials), but makes up another format. It doesn't tell 
the client how or where to use the credentials (ie which authentication 
mechanisms, and which servers).

This draft and OAuth2 would be helped if we defined an explicit media type for 
credentials: eg application/credentials+json. This draft could use it to return 
client credentials. OAuth2 could use it to return credentials representing a 
user's delegation to a client etc. It could cover the common needs: id, auth 
mechanism, where it is safe to use, lifetime, renewal, multiple credentials, 
errors


--
James Manger
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth