Re: [OAUTH-WG] Refresh tokens

There is a scalability reason, in that the access_token could be verifiable on the resource server without DB lookup or a call out to a central server, then the refresh token serves as the means for revoking in the "an access token good for an hour, with a refresh token good for a year or good-t

Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"

Thanks, I understand that the spec leaves it ambiguous, I read the long thread on multiple components single client ID. I wanted to point out that this will be common despite this. Hopefully maybe to encourage FB to start an extension clarify this. Thanks for your help, I had overlooked using

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

The only reason I've heard was interoperability but it is always stated as patently obvious without a given reasoning. My assumption is this is concern of OAuth 2 client library authors who don't want to depend on 3 parsing libraries but want to state they can inter-operate with any OAuth 2 prov

Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned)

Once again, I want to plea the case for keeping the response simple key/value string pairs so it is trivial to serialize to multiple formats. The OAuth endpoint should be able to match the format(s) of the API it protects. Given this simple response payload, the spec can generically describe how

Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned)

I like your response. I think application/json and application/xml would be fine without application/x-www-form-urlencoded. I just thought it made a good lowest common denominator for serialization which I think aids in making it simple to support multiple formats. On May 26, 2010, at 12:19 A

Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme

Can't you always have the front end web server preserve the original URI in a header or something before the rewrite engine or application framework mangle it, right? For example, this Nginx conf that preserves original parts of the request that get changed when the request is proxied to the up

Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme

Except you are in control of your web server so you know you put it there and where it came from right? On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote: > That’s the same thing (in a header or in the attached signed blob). > > EHL > > From: Kris Selden [mailto:kris.s

Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme

need that workaround if you don't have access to the original uri. On May 28, 2010, at 6:47 PM, Eran Hammer-Lahav wrote: How is that different than using the authorization header? EHL From: Kris Selden [mailto:kris.sel...@gmail.com] Sent: Friday, May 28, 2010 3:46 PM To: Eran Ha

Re: [OAUTH-WG] Definition of XML response format

How about keeping it even more flat and compact: This also is more simple on the DOM side, just doc.root['access_token'] instead of traversing or xpath. Anyway, I think OAuth 2 is better served in general by the KISS principle . -Kris On Jun 4,

Re: [OAUTH-WG] Definition of XML response format

In order to do that On Jun 15, 2010, at 12:02 AM, Eran Hammer-Lahav wrote: > Since XML was dropped, if you feel strongly about this, please submit a new > I-D extending the spec to allow XML format responses. Don’t worry about how > to extend it, just add parameters or whatever for now. > > EH

Re: [OAUTH-WG] Definition of XML response format

Sorry about the partial message, hit send by accident. -- In order to do that well it would be nice if some further restrictions were imposed on extending rather than responses can be any valid JSON doc. In JSON, keys can be any string, so you can not use them as tags or attribute names in

Re: [OAUTH-WG] Proposal for text for section 2

This is configurable in IIS, Apache and Nginx but the default ranges from 4k to 16k. Don't know if there are issues with buffer sizes on the client side. On Jun 29, 2010, at 5:14 PM, Eran Hammer-Lahav wrote: > More precisely, what are the actual deployed limits on HTTP *request* headers > in

Re: [OAUTH-WG] assertion profile changes

The refresh token is key to separating concerns of the protected resource from the auth server. I think this is succinctly explained the original rationale (refresh token = refresh secret): http://wiki.oauth.net/ScalableOAuth#Appendix On Jul 8, 2010, at 1:51 AM, Laurens Van Houtven wrote: > J

Re: [OAUTH-WG] issuing new refresh tokens

Torsten Lodderstedt [OAUTH-WG] Refresh tokens security enhancement http://www.ietf.org/mail-archive/web/oauth/current/msg02292.html Eran Hammer-Lahav Re: [OAUTH-WG] Refresh tokens security enhancement http://www.ietf.org/mail-archive/web/oauth/current/msg02390.html On Jul 13, 2010, at 7:04 AM, Er

Re: [OAUTH-WG] Hashing passwords for "password" grant type

If it is https you aren't sending the password unencrypted. You shouldn't be logging post params unfiltered. You should have a per user random salt you are hashing the password with, which would make it hard for you to hash it on the phone without making a separate call to lookup the salt for th

Re: [OAUTH-WG] Hashing passwords for "password" grant type

> Kris - Can you clarify why phones can't protect the client secret? This > sounds like it would be a major issue for a lot of people. Mobile apps on phones like iPhone are installed apps, and it is not possible as far as I know to prevent the client secret from being extracted – you have to

Re: [OAUTH-WG] User-Agent flow and refresh tokens

> Secrets on native apps are good! The key is (no pun intended) that the > secret not ship with the app. Each client should register for its own > client_id and secret when it is installed on the client machine. Maybe I'm missing something but... If it has no credentials, why does sending it

Re: [OAUTH-WG] User-Agent flow and refresh tokens

re for this and a lack of understanding why we can't trust it is our own app which I suspect will be common as well). On Sep 19, 2010, at 7:37 AM, Torsten Lodderstedt wrote: > Am 18.09.2010 01:28, schrieb Kris Selden: >>> Secrets on native apps are good! The key is (no pun intended)

Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01

Also, when a browser follows the Location header it strips the fragment from the URL. Fragments are visible to the client but not sent to the server. On Dec 2, 2010, at 7:24 AM, Eran Hammer-Lahav wrote: > Fragments are not allowed in the HTTP request URI and are not transmitted. > They are all

Re: [OAUTH-WG] Flowchart for legs of OAuth

A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? Why doesn't implicit_g

Re: [OAUTH-WG] Flowchart for legs of OAuth

r it instead, by passing OAuth > completely). > > On Apr 4, 2011, at 2:02 PM, Phil Hunt wrote: > >> On 2011-04-04, at 10:47 AM, Kris Selden wrote: >> >>> A typical iPhone app cannot be shipped with a client secret and rightly or >>> wrongly users expect to

Re: [OAUTH-WG] MAC request URI normalization (query parameters)

Can't the mod_rewrite in Apache set an environment variable with the original request? [E=ORIG_PATH:$1] Or set a header if proxying the request after rewrite (similar to X-Forwarded-For or X-Forwarded-Proto) to preserve the original request path? - Everyone's main interest, I'm guessing, i

Re: [OAUTH-WG] Language encoding in error_description

How about taking a page from URI spec since it is a query parameter value and follow this for the value of such human readable text params: When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should

Re: [OAUTH-WG] Language encoding in error_description

Is there a problem with sticking to UTF-8? OAuth already mandates JSON which is Unicode only. Would be nice to keep it simple. I'm guessing without guidance, most would convert to UTF-8 and percent encode anyway. On May 18, 2011, at 1:32 PM, Julian Reschke wrote: > On 2011-05-18 22:

Re: [OAUTH-WG] Language encoding in error_description

a ServletRequest.getParameter(String name) // Tomcat has 2 settings which govern query string parsing URIEncoding which defaults to ISO-8859-1 and useBodyEncodingForURI which defaults to false URLDecoder.decode(String s, String enc) // Need to know encoding before percent decoding On May 18, 2011, a

Re: [OAUTH-WG] Language encoding in error_description

would start at the most limited case, the url fragment which is intended to be parsed by a client side script. Javascript cannot percent decode into a string anything other than UTF-8. On May 19, 2011, at 2:55 AM, Julian Reschke wrote: > On 2011-05-19 11:14, Kris Selden wrote: >>> Wel

Re: [OAUTH-WG] Text for Native Applications

Why can't you just revoke the refresh token for a client when you change the client secret? Is it not easier to revoke a token than it is to rotate the client secret (which is usually configured or embedded in the client whereas the token is issued)? On May 31, 2011, at 5:37 PM, Brian Eaton wr

Re: [OAUTH-WG] Text for Native Applications

I would suspect that many users are overwhelmed when authorizing many fine grained scopes and don't fully understand the risks. Many popular sites ask for offline access straight away upon connecting to Facebook (Foursquare, Quora, Instagram, etc). This offline access token, has a higher chanc

Re: [OAUTH-WG] Text for Native Applications

On May 31, 2011, at 11:05 PM, Brian Eaton wrote: > On Tue, May 31, 2011 at 10:39 PM, Kris Selden wrote: >> Why can't you just revoke the refresh token for a client when you change the >> client secret? >> >> Is it not easier to revoke a token than it is to