Better error messages maybe? :-)

[Jeremy Smith]

Actually, that's not a bad idea.  The authorization could stay
persistent on example.org, and since I control both sites, I am not
only guaranteed that example.org won't bug the user about trusts on
every page requests, but also that nobody will give me crap for
overusing the auth server :-)

Just have to make sure that all the redirects between sites are like
lightning so the user can't tell.

Me likey.  Thanks :-)

-Jeremy

On 8/15/05, Richard 'toast' Russo <russor at msoe.edu> wrote:
> You could use OpenID to auth on example.org, and then on example.com
> (where users are hijacking cookies), auth against example.org on
> every request.
> 
> So as a user, I would have a cookie with my ID server (livejournal),
> and example.org, but not example.com, which my friends can steal
> cookies from.
> 
> Probably doesn't make your life any easier.
> 
> --- Jeremy Smith <jeremyrsmith at gmail.com> wrote:
> 
> > I see what you're saying.  My original idea was a site where people
> > could ONLY log in through OpenID (as in, there are no user accounts
> > for this site specifically) and then my site would not have to host
> > any sensitive cookie information.  Then users could have their own
> > javascript and other so-called "Web 2.0" nifties without being able
> > to
> > hijack other people's logins by stealing cookie information.
> >
> > Looks like I should have thought it through better :-)
> >
> > -Jeremy
> >
> > On 8/15/05, Michael 'hacker' Krelin <hacker at klever.net> wrote:
> > > On Mon, Aug 15, 2005 at 01:46:22PM -0700, Jeremy Smith wrote:
> > > > By storing an assertion in the session, doesn't that leave the
> > user
> > > > vulnerable to replay attacks via cookie theft?  I was hoping
> > using
> > >
> > > As much as having persistent session (login, for instance) at
> > all.
> > > OpenID lets user confirm who they are like they would do with
> > mere
> > > password otherwise. It's up to you what to do with the user once
> > > authenticated - use it, for instance, for adding comment and
> > forget or
> > > keep session information for the user (possibly associated with
> > IP
> > > address).
> > >
> > > Love,
> > > H
> > >
> > >
> > > > OpenID for decentralized authentication would
> > > > quell that problem.
> > > >
> > > > But now that I think about that, I guess there's no way to do
> > it.  Hmmm.
> > > >
> > > > -Jeremy
> > > >
> > > > On 8/15/05, Martin Atkins <mart at degeneration.co.uk> wrote:
> > > > > Jeremy Smith wrote:
> > > > > >
> > > > > > Now, another question: How is an OpenID consumer to deal
> > with staying
> > > > > > logged in?  Shall I verify the ID (entailing a series of
> > redirects)
> > > > > > for every page request?
> > > > > >
> > > > >
> > > > > You should create a session of some description for your user
> > which has
> > > > > a duration of as long as you are willing to trust the
> > assersion. How
> > > > > long you are willing to allow is up to you, depending on the
> > sensitivity
> > > > > of your application and any other criteria you like. How you
> > track the
> > > > > session is entirely up to you as well.
> > > > >
> > > > > Re-verifying for every request is possible but certainly not
> > a good
> > > > > idea. For one thing, users whose ID servers don't have a
> > "Yes, every
> > > > > time" option will have to keep authorizing it over and over,
> > and I'm
> > > > > sure the identity servers themselves won't be too happy.
> > > > >
> > > > >
> > > >
> > >
> >
> >
> 
>