Hi Igor, Without getting into any specific details, most large websites will check your browser cookies, along with other factors (including your IP address, simultaneous sessions from other IP addresses, recent changes to your account, the time you last verified your password, etc) to determine if your browser is still authorized to access your Mail. When in doubt, the site will verify your password to refresh the session before continuing.
Hope that helps, Allen On 4/8/10 3:09 PM, "Igor Faynberg" <[email protected]> wrote: > Allen, > > (I am a happy user of Yahoo mail via Verizon.) In some cases, especially > if I had not used e-mail for a while, Yahoo prompts me to enter the > password. Now, I think this is a very good feature, which would protect > me if my computer is stolen. The question: how is this interworking with > the case you explained? > > Igor > > Allen Tom wrote: >> Yahoo has exactly the same use case. >> >> The user is authenticated into the Yahoo Instant Messenger client >> application, and clicks on the Yahoo Mail button to check Yahoo Mail. >> >> Clicking the Mail button spawns a browser window with an >> authentication token that is passed to the browser on the URL. The >> browser submits the token to Yahoo¹s authentication server which >> validates the token, sets authentication cookies to the browser, and >> then redirects the browser to Yahoo Mail. >> >> Allen >> >> >> On 4/8/10 11:30 AM, "George Fletcher" <[email protected]> wrote: >> >> On 4/8/10 11:31 AM, Eran Hammer-Lahav wrote: >> >> Re: [OAUTH-WG] Limiting signed requests to use the >> Authorization request header Can you share an example of a >> native application launching an external browser with a >> protect resource? >> >> Native application = AIM >> Protected Resource = User's AIM Mail box >> >> AIM has supported this for a while. >> >> >> Why can¹t the end user just login to the browser using normal >> web login and access the resource? >> >> It's a better user experience to be seamlessly logged in than >> having to reenter credentials. >> >> Thanks, >> George >> >> >> EHL >> >> >> On 4/8/10 7:51 AM, "Anthony Nadalin" <[email protected]> >> wrote: >> >> >>> Why is the native application launching a browser with a >> protected resource request? That seems odd. >> >> Not odd at all a lot of the Eclipse applications can work >> this way >> >> >> *From:* [email protected] >> [mailto:[email protected]] *On Behalf Of *Eran >> Hammer-Lahav >> *Sent:* Thursday, April 08, 2010 7:41 AM >> *To:* George Fletcher; OAuth WG >> *Cc:* Jonathan Moore >> *Subject:* Re: [OAUTH-WG] Limiting signed requests to use >> the Authorization request header >> >> Why is the native application launching a browser with a >> protected resource request? That seems odd. >> >> Note that we currently have no plans of supporting >> signatures in any of the flows. We are discussing >> signatures only for using tokens with secrets when >> accessing protected resources. >> >> EHL >> >> >> On 4/8/10 7:08 AM, "George Fletcher" <[email protected]> wrote: >> Another use case is where a rich client wants to bootstrap >> a web session with the same identity (rich client to web >> SSO). Assuming that the web session will be established >> via OAuth with signatures, there is no way to fire up the >> browser with a "signed URL" if the OAuth parameters and >> signature need to be in a header. >> >> As Jon mentions, the concept of allowing a service to >> create a signed URL and then pass it back to JS running in >> the browser, or invoking a browser directly is something >> that we leverage a lot across our rich clients and web >> applications. >> >> I realize that these sorts of use cases are trivial if >> establishment of the SSO session switches from a signed >> mechanism to the OAuth WRAP bearer token model. The one >> nice feature of the signed URL is that it is one time use >> where the bearer token can be replayed multiple times. >> >> Thanks, >> George >> >> Real world use case. Login into the latest AIM client. >> Click the mail icon/link. >> >> >> On 3/31/10 7:25 AM, Moore, Jonathan wrote: >> >> What about a use case where the signature will be >> generated by one component but the request will be >> redeemed by another? >> >> For example, suppose there is a cross-domain JSONP call >> that requires authorization; in this case, I might have my >> client side code hit *my* origin server, obtain a signed >> URL, and then redeem it by hitting the JSONP resource. >> This has scaling advantages over having my origin proxy an >> OAuth request, and doesn't require me to have keys located >> on the client; I can keep them safely in my data centers. >> >> In this case, sending a "ready to redeem" signed request >> using the query parameter mechanism simplifies the >> client-side code. Furthermore, in this use case >> (cross-domain script inclusion), the client doesn't have >> the means to set the Authorization header (it can only >> include a <script> element with a URL). >> >> A similar use case would be if you wanted to provide >> signed redirects (similarly useful for cross-domain >> functionality); browsers aren't going to modify the >> redirect URL they get back, or add an Authorization header >> to it. >> >> Jon >> ........ >> Jon Moore >> Comcast Interactive Media >> >> >> >> -----Original Message----- >> From: [email protected] on behalf of Eran Hammer-Lahav >> Sent: Wed 3/31/2010 12:20 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Limiting signed requests to use the >> Authorizationrequest header >> >> Since we have consensus that using signed requests is a >> more advance use >> case and will be used by more experienced developer, I >> would like to suggest >> we limit sending signed request parameters to the >> Authorization header (no >> URI query parameters or form-encoded body). >> >> This will not change the ability to send the oauth_token >> parameter in the >> query or body when using bearer tokens (as well as in the >> header). It will >> only apply to sending signed requests. >> >> The makes client request parameter much simpler as the >> only parameter >> "invading" the URI or body space of the request is >> oauth_token. Anything >> else is limited to the header. >> >> Thoughts? If you are not a fan, please reply with a use case. >> >> EHL >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
