Re: [oauth] OAuth design for API without users permission
Hi Eric! If there's no user authentication, you can use two-legged OAuth. That means there's only consumer credentials but no token credentials. If the application is not hosted somewhere but deployed and installed at their user's, there's as far as I know no way to securely integrate consumer credentials. Unfortunately I think it's difficult to give you advice regarding key management, e.g. replacing compromised keys, without knowing the exact circumstances. Regards, Lukas Rosenstock 2010/7/30 Eric J. Smith e...@codesmithtools.com I am developing an API that will be used by users of my customers. Here is what the flow will look like: - User of my cloud based service creates an API key. - User embeds the API key into their own custom applications. - User deploys the application to their own end users. - The application talks to our API. I am looking for advice on how to secure this API. I see a few issues: - API key has to be embedded into the users application and is therefore vulnerable to being stolen and abused. - Once an API key is compromised, it can easily be disabled, but how will my users update their applications to use a new API key short of having to rebuild the application and redeploy. Does anyone have any ideas on how to design this? -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] SSL Gateway Service provider
Interesting idea, don't know if that exists. But my question would be in which scenarios an encrypted tunnel should be easier to configure compared to installing an SSL certificate on the webserver itself?! 2010/7/30 Jake findj...@gmail.com Hello, Does anyone know of a service provider that offers SSL termination services that tie back to the application via secure tunnel instead of another SSL connection? The idea is off load all the SSL work to the service provider and just connect back to the application via an encrypted tunnel to avoid supporting the SSL connection cycle on our infrastructure. Akamai kind of has something but they connect back to the origin servers via SSL which kind of kills the idea. I have no idea if this exists but am curious. Thanks. -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Confused about the request token
Hello! To answer your question ... the OAuth Temporary Credentials, which means the Request Token and Secret, are usually randomly generated by the Server in the same way like the Token Credentials (Access Token and Secret) and sent to the client. The Client needs the oauth_token_secret only once: for the request in which the Request Token is exchanged for an Access Token. For the requests between Client and Server, the signature is generated as follows: 1) Request for Temporary Credentials - signed with Client Credentials only. 2) Request for Token Credentials - signed with Temporary Credentials (this is what you need the oauth_token_secret for). 3) Request for Resources - signed with Token Credentials. Hope I could help. Regards, Lukas Rosenstock 2010/7/28 KeefTM kee...@gmail.com So I am currently writing a SP, and I have a few questions. First, I am following the specs here: http://tools.ietf.org/html/rfc5849 Those are the correct specs to follow, right? Second, it seems that for the Temporary Credential Request, oauth_token and oauth_token_secret are randomly generated. Is this the case? If so then what does the Client do with the oauth_token_secret? Thanks! -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Enterprise usage question: Role based access and scope parameter
scope is about the permissions that a client application is requesting. But if those permissions are inherently bound to the users becaus the users have certain roles, the Access Token requested for a user can be bound to those roles by the Authorization server. I don't feel there's a requirement to use scope at all. If, however, you want client applications to specifically state for which role they're requesting access, there's nothing to prevent you from implementing the scheme suggested. The specification doesn't state any format of scopes and neither does it say anything on how the scope values are converted into actual access privileges. Regards, Lukas Rosenstock 2010/7/6 wjgerritsen epsilon...@gmail.com: Hi, I am playing with the idea of using role names in the scope parameter (of RequestToken endpoint) for authorizing to our platform. It will work somehow like this: A user has a number of roles: e.g. SalesRep, Employee, Manager. To each role a consistent privilege set is assigned, so the user would also be able to use (part of) the functionality of the platform with only one role. Then the token would be bound to a certain role (e.g. SalesRep), such that the consumer app cannot excercise all privileges of the user, but only those limited to the assigned scope, which is a role. Upon app registration, it will be made clear which roles are liable for the scope parameter. Any comments? regards, Willem Jan -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Getting the user name
OpenID Connect (http://openidconnect.com/) is an alternative version of OpenID build on OAuth. It considers this use case as well and returns a user identifier which can be used to get username etc. in a standardized manner via OAuth. Regards, Lukas 2010/5/20 Leah Culver leah.cul...@gmail.com Many APIs have an endpoint solely for getting information about the authenticated user. I think Twitter's is account/verify_credentials... Leah On May 16, 2010, at 5:36 PM, Richer, Justin P. jric...@mitre.org wrote: Nothing exists for this specifically in OAuth, partially because not all APIs have a notion of a username. However, I think that it makes sense to have a notion of per-instance metadata attached to a token. For example, if a user has two instances of a thick client, both of those will have tokens in the server end, but since they'll both have the same client ID there's no way to tell them apart. Username could be one of these kinds of per-instance meta ields. I floated this idea on the list a while back and never got traction on it. -- justin -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Getting the user name
Hi! Twitter returns the screenname and user id with almost any API call, and also along with the Access Token. For other services you have to check which API call can give you an account name. There is no standardized way in OAuth to do this. Regards, Lukas PS: Anyone thinks this should be standardized?! 2010/5/11 hank williams hank...@gmail.com I am an Oauth Noob, and so I have a basic question. My company is intending to support Twitter, Google apps, and Yahoo apps access via Oauth. I know that part of the purpose of Oauth is to prevent the application developer from seeing the account name/password. But I am wondering if it is indeed the goal to keep the account name from the application developer. We would like to support a users ability to access multiple accounts on the same service. For example through our service the user could access two google accounts because they have two separate gmail accounts. For a proper user interface we need to be able to request, from within a given API, a call of the type what is the username for this account. This will allow us to provide a UI that has choices for which account the user wants to be able to use. I have just been looking at the twitter API and I do not see a what is the username for this account call, and so I thought I would ask here if I am somehow barking up the wrong philosophical tree, and if not if anyone knows how to make such calls for twitter, yahoo and google. Thanks, Hank. -- blog: whydoeseverythingsuck.com -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] oauth_callback parameter not sent to getsatisfaction
Hi! Just to clarify: The protocol knows two ways for sending the OAuth callback, one is along with the request token; and the other is by attaching it to the URL. The former (1.0a) is recommended and was introduced after security issues had been known about the latter (1.0). Regards, Lukas 2010/4/26 k42b3 k42b...@googlemail.com hi, However GetSatisfaction requires that oauth_callback=http://mysite.com/myresource be sent along with the authorization url As you mentioned the callback url must be send when you obtain the Temporary Credentials. You can set the callback to oob but then you have to provide the url in anotherway to GetSatisfaction. Unfortunately since my callback url is different at different entry points Then you probably must use the oauth_callback param. I dont know the API of GetSatisfaction but if its not according to the specification you should probably contact them. best regards -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] HTTP PUT request format
Hi! The correct way would be to use the HTTP Authorization header. Both methods which you have mentioned are basically fallbacks for that semantically correct Authorization header. If you can't use that, however, I would say 1) is better than 2) because as per the specification the signature in the body implies a application/x-www-form-urlencoded content type which usually is not the case if you use PUT. OAuth libraries should handle that as well. Regards, Lukas Rosenstock 2010/4/16 AriB ariel.boludov...@gmail.com Hi, when sending HTTP POST or PUT requests with Oauth, which is the right request format, 1) or 2)? Thanks in advance, AB 1) PUT http://www.mycompany.com:8080/blahblah?oauth_signature_method=HMAC-SHA1oauth_token=blahblahoauth_consumer_key=blahblahoauth_timestamp=1271415739oauth_nonce=14979237328487oauth_version=1.0oauth_signature=BZ5yz0cPta7Qs2PPzVD%2F6aDG6Gk%3D POST data: myrequestbodyhere [no cookies] Request Headers: Connection: keep-alive Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Length: 10 2) PUT http://www.mycompany.com:8080/blahblah POST data: oauth_signature_method=HMAC- SHA1oauth_token=blahblahoauth_consumer_key=blahblahoauth_timestamp=1271415739oauth_nonce=14979237328487oauth_version=1.0oauth_signature=BZ5yz0cPta7Qs2PPzVD %2F6aDG6Gk%3D myrequestbodyhere [no cookies] Request Headers: Connection: keep-alive Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Length: 10 -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Google oAuth Access Token Longevity
The specification does not guide or limit the provider in implementing their own security policies and that includes the lifetime of tokens. Some providers may limit it intentionally to let users re-confirm that they still want to provide the access (or simply users should be logged on to their site on the browser) and others don't set any expiry, like Twitter which keeps tokens alive unless someone revokes them. Lukas 2010/3/26 Gary Young gary.b.yo...@gmail.com I'm building an oAuth app that integrates with Contacts, and Gmail and everything is working correctly, except that the oAuth access tokens that I'm generating seem to only last 1 day. I was under the impression that oAuth access tokens should last indefinitely as long as they are not revoked by the user or my application. Can someone shed some light on this? Thanks! Gary webnexsys.com -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Updating my Twitter status programmatically.
Hi! As far as I know Twitter does not allow 2-legged OAuth. That means, apart from the Consumer Key and Secret that you have already registered, you need an Access Token and Secret as well. Now, you may have to do the following things: 1) Fetch a request token and secret from Twitter. This request will be signed with your Consumer Key and secret. 2) Open the Twitter login page (Authorize URL) with ?oauth_token= and the request token you got in the first step. 3) Fetch an access token from Twitter by exchanging your request token and secret for an access token and secret. Any OAuth library will assist in this. This process you will have to perform only once. After that, you can hardcode your Access Token and Secret along with your Consumer Key and Secret in your application. Your script can forget about the OAuth flow and just needs to generate the appropriate signature. As long as you don't manually go to your Twitter account and unauthorize your own application, your Access Token and Secret will be valid for posting. Regards, Lukas 2010/3/23 grantcv1 grant...@gmail.com I want to programmatically log into twitter periodically and update my status. This will happen a few times a day from my server without any user interaction. In order to do this, I need my server-based app to authenticate itself with twitter using my login credentials. It seems I have two choices. First, I can take the easy route and use basic authentication, but this is considered bad practice at this point in time. The second and apparently preferred approach is to use OAuth. So I have spent the past day learning what I can about OAuth. While I have learned loads about who created OAuth, what the history of the name is and that it is a double entente [sic - it's double entendre]. I have read beginners guides only to find that they are obsolete or authoritative gruide's only to find they are incomplete. All in all, I feel I have read about a lot of things, but in the end I haven't learned much at all. What I have learned is that, if this is to work at all, it will require the two-legged model rather than the three-legged model. I have struggled to find very much information about the two-legged model or get any confirmation that twitter even supports this. I did find what I believe to be the original spec for this model and it seemed to indicate that the model was simpler than the three-legged dance. It apparently requires the consumer key and consumer secret but no token key or token secret. I guess that the consumer key and secret is adequate to authenticate the application - and somehow maybe the app is associated with the twitter account so that is good enough. [???]. So I registered my app with twitter, got the consumer key and consumer secret, found a library to work with, and set about trying to get something to work, But alas, all I seem to get is a login popping up at me and then nothing. Am I on the right track? Or should I just abandon an effort to follow best practices and instead do the simpler thing? -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] 3-legged oauth -- user authorization failures -- what is the standard oauth spec
Hi! I would like to see this issue addressed in the next iteration of OAuth. For one internal scenario in which we have deployed OAuth we have come up with a solution in which apart from oauth_callback another error_callback parameter is passed - in case of failure the user will be redirected to that one instead. Regards, Lukas Rosenstock 2010/2/21 Mahesh Venkat mhven...@gmail.com Hi, I recently implemented the 3-legged oauth as per the OAuth 1.0a specs. During the implementation I am finding some gaps in the specs for error scenarios. We have oauth_callback url to redirect the user to the consumer app after a successful user authorization. There are a number of exception cases where I am not sure what the oauth specs are: 1. What is the user interface or oauth interface, if the user denies the authorization 2. If there is system failure in presenting the authorization page to the user, should the service provide redirect to the same oauth_callback url of the consumer? 3. When the service provider receives a request for user authorization using the 'unauthorized' request token, if the token is invalid or expired should the service provider redirect to the oauth_callback url or send a 404 error? Appreciate your response. -- Regards --Mahesh -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] test OAuth consumer and service provider
Hi! I think this looks very nice and will help to understand the flow and is good for debugging. We might use it to test the upgrade of our internal OAuth use from 1.0 to 1.0a. Lukas 2009/11/18 k42b3 k42b...@googlemail.com: hi OAuth folks, I like to announce a test consumer and service provider. http://dev.k42b3.com/index.php/oauth this is a implementation of the specification OAuth 1.0 Revision A. Because I missed a test server while Iam trying to understand the concept of OAuth ... I developed this OAuth service provider and consumer. This should help people to understand OAuth and to test applications that are based on it. best regards k42b3 -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=. -- http://lukasrosenstock.net/ -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Status of XRDS Simple and OAuth Discovery
Good afternoon! A long time back I came across two drafts for standards, which are now marked as obsolute, with a new version to be expected by the end of March 2009. Now it's November 2009! These standards are the OAuth Discovery and XRDS Simple: http://oauth.net/discovery/1.0 http://xrds-simple.net/core/1.0/ I planned to incorporate some of the functionality specified by those standards in my current project, but right now I'm unsure on how to proceed. Are there any successors of those protocols or is there any work in progress?! As I haven't been too active in the OAuth/OpenID communities recently I apologize in case this is a stupid question where I should know the answer ... Regards, Lukas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Question about Access Token
Ok, sorry, I read your last sentence wrong so my first sentence doesn't make sense ... One more thing: Using an Access Token the Consumer can make any number of requests as long as that token is valid. 2009/11/2 Lukas Rosenstock l...@lukasrosenstock.net Hi Melvin, yes, the Access Token is used to access the permissioned resource directly, but I would not say just access because this is the purpose of OAuth, right?! The Provider has some resources (data, functionality etc.) exposed through webservice APIs, which are related to a particular user (e.g. contain this user's personal details). Every request that directly goes from the Consumer to the Provider - a server-to-server request in which the user's browser is not involved - carries an OAuth signature. This signature contains the Access Token so that the Provider can verify that the user has actually given his consent to share the data with the Consumer. Hope that helped! Regards, Lukas 2009/10/31 Melvin Carvalho melvincarva...@gmail.com Hi All I hope this is not too much of a beginner question. I've been reading through the OAuth spec and I was wondering what the role of the access token is. It seems to me after stage 6.2 http://oauth.net/core/1.0a#auth_step2 1. The Service Provider has authorized the Consumer 2. The Service Provider has verified the Consumer Why then does the consumer need an access token, rather than just accessed the permissioned resource directly. Thanks Melvin -- http://lukasrosenstock.net/ -- http://lukasrosenstock.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: My case against section 6.2.1 (User redirection)
The idea behind OAuth has often been described as a valet key. The kind of authentication provided by the access token in OAuth is different from the user's username and password. During the redirect, the user may choose what kind of access he wants to give, for example whether the consumer application may only read data from the provider or whether write-access is also provided. Asking for the user's credentials does not provide this kind of access. The second thing about OAuth is that - while of course user's may be tricked - it at least gives the user the opportunity to find out about potential phishing sites by looking at the URL. With asking for the username and password there is no way the user can check whether his credentials are stored by the consumer or not. What you call a normal authorization flow has been described as the password anti pattern. I would agree that this may be a bit unusual to users but they're getting used to it and from security perspective it is better due to the reasons which I described above. Regards, Lukas PS: Although I'm using OAuth for some time, this is my first posting to this mailing list. I hope it's okay ... and welcome everybody ... 2009/9/29 James Wanga jwa...@gmail.com I'm new to the OAuth pattern, as such, I welcome any criticism of my ignorance. As I understand it, Section 6.2.1 of the OAuth 1.0a spec states that the consumer MUST obtain approval by directing the user to the service provider at which point the user enters their credentials, consequently, approving the request token. From what I gather, this redirection serves two purposes. It keeps the users credentials safe from a malicious/careless consumers and it prevents anyone snooping the wire on non-SSL connections from obtaining any useful data. I think premise that a redirect to the service provider keeps credentials safe in any reliable way is deeply, deeply flawed. I've read several arguments issuing caution about the susceptibility of this pattern to phishing attacks and most just issue the warning then continue on to explain how to implement it anyway. In my humble opinion a phishing attack is so trivial with this pattern that attempting to keep user credentials from the consumer is futile. Let me use the canonical scenario. The consumer - printer.example.com - directs the user to the service provider authorization page - photos.example.com/authorize - where the user logs in and authorizes the consumer. The OAuth pattern argues that this keeps the user safe in the event that printer.example.com is a den of thieves interested is stealing your credentials. I disagree. If they wanted to steal your info it would be pitifully trivial to redirect you to example.printer.com/authorize. The idea that most users will notice the URL slight of hand is unrealistic. Did you? For that matter, a malicious consumer could load the authorization page in a browser window without an address bar and remove the users ability to tell the difference. The only benefit redirection seems to offer is in keeping consumers from carelessly storing passwords that can be stolen. If a consumer wants your password, they'll get it. Easily! I argue that it is so easy to trick large numbers of users with a fake authorization page that the requirement is useless. Though far from ideal, I propose that it isn't any less safe to allow the consumer - web or installed - to authorize themselves by prompting for the users credentials and passing them over SSL. This would still eliminate the need for the consumer to store credentials on the users behalf as with basic auth and it would spare users the unfamiliarity of the OAuth workflow. I realize this does nothing to control malicious consumers. My only case is that compromising the redirect workflow is so trivial that at least we can give the user back a normal authentication experience. Once again, it is entirely possible that I'm mis-understanding something, it wouldn't be the first time. But if I'm not, then we should really consider whether or not redirection is presenting a dangerous, false sense of security. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
