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 tokensAPI
cookies when trying to
web site you will likely be able to access the
same data as the access token (web site uses refresh token on backend to
make API calls on behalf of the logged in user... which is based on the
cookie that was stolen).
EHL
On 7/14/10 11:04 PM, Evan Gilbert uid...@google.com wrote:
Password
Hi all - having a little bit of a hard time following the full thread, but
I'm strongly in favor of base64url encoding.
A big advantage of this encoding is that, if token is base64url encoded,
then urlencode(token) == token.
This allows developers to avoid a large class of problems in dealing
On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott andrewarn...@gmail.comwrote:
If we can agree that it is useless from a security perspective (and I think
we agree on that by now), then an auth server must not ever issue an access
token to a user agent client without interacting with the user (no
On Sun, Jun 27, 2010 at 1:46 PM, Robert Sayre say...@gmail.com wrote:
On Sun, Jun 13, 2010 at 11:20 AM, Evan Gilbert uid...@google.com wrote:
Can you explain the XSS hole from parsing a random JSON string?
Naive processor calls:
var href = document.location.href;
var jsonBlob
On Sun, Jun 13, 2010 at 5:55 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
To be clear, you are +1 on using only JSON for server responses on the
token endpoint?
Yes, +1 on JSON responses for token endpoint.
EHL
*From:* Evan Gilbert [mailto:uid...@google.com]
*Sent:* Sunday, June 13
to the AS with the access token on the server side
for complex data, and JSON is the right response format for this followup
call.
EHL
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
Of *Evan Gilbert
*Sent:* Sunday, June 13, 2010 2:47 AM
*To:* Robert Sayre
*Cc:* OAuth WG (oauth
On Wed, May 19, 2010 at 6:33 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
Marius,
Only direct responses are JSON, form/url encoded
still has to be used:
- direct requests
- through browser requests
- through browser responses
- through browser fragment responses
A
I'd like to get a standard for redirect URI matching, but think this may not
be feasible - we are leaving the callback URI registration mechanism
undefined and I've heard a number of different mechanisms that companies
want to support.
I think we should leave the matching undefined, possibly with
On Wed, May 12, 2010 at 11:52 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
Evan,
The key point is that this discovery covers a lot of the same grounds as
the sites parameter, and it's hard to define semantics around a sites
parameter without understanding the semantics of
.
EHL
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
Of *Evan Gilbert
*Sent:* Thursday, May 13, 2010 9:00 AM
*To:* Manger, James H
*Cc:* OAuth WG
*Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid
On Wed, May 12, 2010 at 11:52 PM, Manger
On Thu, May 13, 2010 at 4:54 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
Evan,
we have no API endpoints that are only arrived at by links
This doesn't sound very web-friendly. Your APIs don't have to follow a
web-style, but an IETF spec should support web-style APIs.
I
Thanks for the response - feedback inline...
On Wed, May 12, 2010 at 5:09 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
Evan,
Clients need to know the following in advance:
1. The scope to use to request access to a protected resource
2. The API endpoint to call to access
On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu mscurte...@google.comwrote:
On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Sunday, May 09, 2010 5:52 PM
3.5.1. Client
I really like the idea behind the sites parameter
I think this idea relates closely to scopes and probably needs to be bound
more tightly to the inbound scope parameter. Both identify a set of
protected resources that can be accessed with the token - one is the
requested resources, the other is
I'm seeing a few OAuth features in spec discussions which:
- Feel like it would be a major omission if they don't make it into OAuth
2.0, but
- Haven't been used previously or even prototyped, which makes people
uncomfortable with adding to the spec
This includes the scope / sites syntax
On Mon, May 10, 2010 at 1:20 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Am 10.05.2010 um 22:07 schrieb Marius Scurtescu mscurte...@google.com:
On Sun, May 9, 2010 at 3:01 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
3.5.1.1. End-user Grants Authorization
I
On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
I'll add something to the draft and we'll discuss it. There is enough
consensus on a single JSON response format.
Responses that are returned via a browser URL should
be application/x-www-form-urlencoded. These
On Wed, May 5, 2010 at 10:24 AM, Robert Sayre say...@gmail.com wrote:
On Wed, May 5, 2010 at 1:06 PM, Evan Gilbert uid...@google.com wrote:
On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
I'll add something to the draft and we'll discuss
On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Even if not supported directly by the platform there are many JSON
libraries available these days.
It's not hard to add JSON support, but it's a factor in the choice.
http://www.json.org/ lists 3
On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert uid...@google.com wrote:
On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Even if not supported directly by the platform there are many JSON
libraries available these days.
It's not hard to add JSON
assume we would also use URL parameters for the Web App flow when
redirecting with the verification code.
EHL
*From:* Evan Gilbert [mailto:uid...@google.com]
*Sent:* Wednesday, May 05, 2010 10:07 AM
*To:* Eran Hammer-Lahav
*Cc:* Torsten Lodderstedt; oauth@ietf.org
*Subject:* Re: [OAUTH
+1 on option 3.
Commas seem slightly cleaner, but can go either way.
We should also consider naming this parameter scopes if we go with option
3
Evan
On Mon, May 3, 2010 at 6:23 AM, Manger, James H
james.h.man...@team.telstra.com wrote:
A comma is a better separator here.
Allow URIs as
On Fri, Apr 16, 2010 at 8:09 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
On 4/16/10 6:00 PM, Evan Gilbert uid...@google.com wrote:
- Add text to the spec to give overview of options for native app
developers
I need a proposal.
Here's a proposal for text to cover the options
On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Hi all,
I would like to propose an additional variant of the Web Server Flow w/o
the need for direct communication between client and authorization server in
order to obtain authorized access/refresh
On Sun, Apr 18, 2010 at 10:36 PM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-04-18, at 10:28 PM, Eran Hammer-Lahav wrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Dick Hardt
Sent: Sunday, April 18, 2010 9:20 PM
To:
On Mon, Apr 19, 2010 at 8:14 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Where does it say you cannot add a parameter named scope? To suggest that
you can’t use the specification because it doesn’t define a placeholder for
something called ‘scope’ is ridiculous.
Simpler client
will be that User 1 starts seeing User 2's data.
On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
How can they both be logged in? I have never seen a case where two users
can be both logged into to the same service at the same time...
EHL
On 4/19/10 8:33 AM, Evan Gilbert uid
On Mon, Apr 19, 2010 at 10:19 AM, Marius Scurtescu mscurte...@google.comwrote:
On Mon, Apr 19, 2010 at 7:28 AM, Evan Gilbert uid...@google.com wrote:
I have a preference to *not* have the oauth_ prefix on parameters when
redirecting back, but could be convinced.
The argument about
On Fri, Apr 16, 2010 at 7:01 AM, Justin Richer jric...@mitre.org wrote:
I favor this approach as well. It feels cleaner to me to have a
separation of purposes here. The two endpoints could always be collapsed
in a particular implementation -- I've seen several OAuth 1.0
implementations that
to work as a browser GET request
--Richard
On Apr 16, 2010, at 3:05 PM, Evan Gilbert wrote:
We should use the same name in the User-Agent and Web Callback flows.
Also, although the authorization server won't be allowing JSONP requests,
callback has become a bit of a defacto standard
the best to me too.
I'm fine with either.
-Original Message-
From: Richard Barnes [mailto:rbar...@bbn.com]
Sent: Friday, April 16, 2010 12:27 PM
To: Evan Gilbert
Cc: Luke Shepard; Naitik Shah; OAuth WG
Subject: Re: [OAUTH-WG] Rename callback = callback_uri
Ok, I think I get
semantic value imho.
-Naitik
On Apr 16, 2010, at 12:05 PM, Evan Gilbert wrote:
We should use the same name in the User-Agent and Web Callback flows.
Also, although the authorization server won't be allowing JSONP requests,
callback has become a bit of a defacto standard for JSONP
A few of us from Google Facebook had a face-to-face discussion today to
talk through the differences / similarities between Native App, Web
Callback, and User-Agent.
From the discussion it seemed that the current Native Application flow is
equivalent to Web Callback flow, with:
1. A redirect to
I've been participating in the OAuth 2.0 discussions, but realized I don't
know how the process is supposed to work for getting successive drafts and
getting to an agreed upon spec and if we have a rough timeline.
The Informal Guide http://www.ietf.org/about/process-docs.html didn't
help that
Thanks for the responses - they were very helpful.
On Thu, Apr 15, 2010 at 5:12 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
On 4/15/10 12:04 AM, Evan Gilbert uid...@google.com wrote:
- What does it mean to have successive drafts? And if we move an issue to
the
next draft, what does
On Thu, Apr 15, 2010 at 6:31 PM, Marius Scurtescu mscurte...@google.comwrote:
OK, here is a concrete example:
A Drupal (popular PHP based CMS) based web site wants to become an
OAuth 2 client. Among other things it needs to implement a callback
endpoint.
Ideally this endpoint would look
+1 in general
Question about display=none - I missed this part before, and proposed a
different parameter (immediate=true) for the same purpose -
http://www.ietf.org/mail-archive/web/oauth/current/msg01694.html.
Anyone have thoughts on whether we should have a separate parameter for
immediate
On Fri, Apr 9, 2010 at 10:08 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
On 4/9/10 1:58 PM, Evan Gilbert uid...@google.com wrote:
On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
On 4/9/10 8:29 AM, Evan Gilbert uid...@google.com wrote
On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
On 4/9/10 8:29 AM, Evan Gilbert uid...@google.com wrote:
On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
On 4/8/10 9:17 PM, Evan Gilbert uid...@google.com wrote
this requirement can move.
Possibly some of the folks who initially proposed client state can give
context as to why this might be different than URL parameters.
EHL
On 4/9/10 7:37 AM, Evan Gilbert uid...@google.com wrote:
On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav e...@hueniverse.com
On Wed, Apr 7, 2010 at 11:40 PM, John Panzer jpan...@google.com wrote:
On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert uid...@google.com wrote:
On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote:
I'm assuming that tokens need not be bound to a specific user (typically
, but it
never hurts to provide more information in the response back.
EHL
On 4/7/10 10:46 PM, Evan Gilbert uid...@google.com wrote:
On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote:
I'm assuming that tokens need not be bound to a specific user (typically
On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
On 4/7/10 9:20 PM, Evan Gilbert uid...@google.com wrote:
Authorization servers in the OAuth Web Callback flow and the User Agent
flow
should have the option to redirect back with access/refresh tokens
without
username. The authorization server MUST
only send back refresh tokens or access tokens *capable of making requests
on behalf of* the user identified by username
On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert uid...@google.com wrote:
On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav
e
On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Hi Evan,
On 4/5/10 4:28 PM, Evan Gilbert uid...@google.com wrote:
2.4.1 Web Callback Flow 2.4.2 Web Client Flow
In both flows, the authorization server should be able redirect back to
the
callback URI without
this?
On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert uid...@google.com wrote:
On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
Hi Evan,
On 4/5/10 4:28 PM, Evan Gilbert uid...@google.com wrote:
2.4.1 Web Callback Flow 2.4.2 Web Client Flow
In both flows
On Tue, Apr 6, 2010 at 11:26 AM, Allen Tom a...@yahoo-inc.com wrote:
One of the biggest differences between OAuth2 and WRAP is that OAuth2
requires that Protected Resources be accessed using HTTPS if no signature is
being used. Bullet Point #2 in Section 1.2 says:
4. Don't allow bearer
48 matches
Mail list logo
