Re: [dotnetopenauth] OAuth2 no javascript crossdomain possible?

[Øyvind Sean Kinsey]

Bearer is not really part of oaut2 - how you use the token is up to the resource server.
Supporting access_token as a get/post argument is quite normal though.

On Aug 14, 2012 3:31 PM, "fantastischIdee" <fantast...@gmail.com> wrote:

I would like to use OAuth2 in a browser / javascript only solution. Therefore I have to make crossdomain (jsonp) servicecalls. But I found that changing headers is not possible when using crossdomain servicecalls. And therefore I think that OAuth2 is not working for me. Or do I miss something?

Also I could not get the SampleWcf2Javascript.html working from the DotNetOpenAuth Samples. Should this work?

$.support.cors = true; // force cross-site scripting (as of jQuery 1.5)

function serviceCall(operation, accessToken, label) {

label.text('fetching...');

$.ajax({

url: "http://localhost:65170" + encodeURI(operation),

headers: {

"Authorization": "Bearer " + accessToken

},

cache: false,

success: function (data, textStatus, jqXHR) { label.text(data.toString()); },

error: function (jqXHR, textStatus, errorThrown) { label.text(textStatus + ": " + errorThrown); }

});

};

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/IuXoOmDW5lkJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[Brad Laney]

Actually bearer IS part of OAuth2. It specifically states that the resource server MUST support bearer. Anything else is extra.

http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-22

2.1

Resource servers MUST support this method.

[Øyvind Sean Kinsey]

That is not the OAuth2 spec ;)

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

[Brad Laney]

Yes actually it is part of the OAuth spec. Which is why it refers to resource server, and is under the oauth v2 section.

How is it not? It refers to authorization servers and everything from OAuth2

[Brad Laney]

Look at the title:

The OAuth 2.0 Authorization Framework: Bearer Token Usage
                     
draft-ietf-oauth-v2-bearer-22

[Øyvind Sean Kinsey]

This is a separate spec, part of the overall OAuth2 framework - http://tools.ietf.org/html/draft-ietf-oauth-v2-31 is the draft for the main protocol - everything else is addendums and extensions. They are both on the standards track, but there is no guarantee that Bearer draft will be approved with the main spec.

That said, don't invest to heavily in using every feature of OAuth2, you'll regret it - for some background, read http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/.

- Sean

--

[fantastischIdee]

Apart from the discussion over the Bearer, i'm interested in getting this sample to work. I found that it is working in Internet Explorer, but not in other browsers (e.g. Chrome) . This is the error:  

XMLHttpRequest cannot load http://localhost:50172/OAuth/Token. Origin http://localhost:3826 is not allowed by Access-Control-Allow-Origin 

On Tuesday, August 14, 2012 10:57:34 AM UTC+2, fantastischIdee wrote:

I would like to use OAuth2 in a browser / javascript only solution. Therefore I have to make crossdomain (jsonp) servicecalls. But I found that changing headers is not possible when using crossdomain servicecalls. And therefore I think that OAuth2 is not working for me. Or do I miss something?

Also I could not get the SampleWcf2Javascript.html working from the DotNetOpenAuth Samples. Should this work?

$.support.cors = true; // force cross-site scripting (as of jQuery 1.5)

function serviceCall(operation, accessToken, label) {

label.text('fetching...');

$.ajax({

url: "http://localhost:65170" + encodeURI(operation),

headers: {

"Authorization": "Bearer " + accessToken

},

cache: false,

success: function (data, textStatus, jqXHR) { label.text(data.toString()); },

error: function (jqXHR, textStatus, errorThrown) { label.text(textStatus + ": " + errorThrown); }

});

};

On Tuesday, August 14, 2012 10:57:34 AM UTC+2, fantastischIdee wrote:

I would like to use OAuth2 in a browser / javascript only solution. Therefore I have to make crossdomain (jsonp) servicecalls. But I found that changing headers is not possible when using crossdomain servicecalls. And therefore I think that OAuth2 is not working for me. Or do I miss something?

Also I could not get the SampleWcf2Javascript.html working from the DotNetOpenAuth Samples. Should this work?

$.support.cors = true; // force cross-site scripting (as of jQuery 1.5)

function serviceCall(operation, accessToken, label) {

label.text('fetching...');

$.ajax({

url: "http://localhost:65170" + encodeURI(operation),

headers: {

"Authorization": "Bearer " + accessToken

},

cache: false,

success: function (data, textStatus, jqXHR) { label.text(data.toString()); },

error: function (jqXHR, textStatus, errorThrown) { label.text(textStatus + ": " + errorThrown); }

});

};

On Tuesday, August 14, 2012 10:57:34 AM UTC+2, fantastischIdee wrote:

I would like to use OAuth2 in a browser / javascript only solution. Therefore I have to make crossdomain (jsonp) servicecalls. But I found that changing headers is not possible when using crossdomain servicecalls. And therefore I think that OAuth2 is not working for me. Or do I miss something?

Also I could not get the SampleWcf2Javascript.html working from the DotNetOpenAuth Samples. Should this work?

$.support.cors = true; // force cross-site scripting (as of jQuery 1.5)

function serviceCall(operation, accessToken, label) {

label.text('fetching...');

$.ajax({

url: "http://localhost:65170" + encodeURI(operation),

headers: {

"Authorization": "Bearer " + accessToken

},

cache: false,

success: function (data, textStatus, jqXHR) { label.text(data.toString()); },

error: function (jqXHR, textStatus, errorThrown) { label.text(textStatus + ": " + errorThrown); }

});

};

[Steven Livingstone Pérez]

Check out the cors support in this excellent library

https://github.com/thinktecture/Thinktecture.IdentityModel.40

Blog post about it here

http://brockallen.com/2012/06/28/cors-support-in-webapi-mvc-and-iis-with-thinktecture-identitymodel/

/steven

---

Date: Wed, 15 Aug 2012 00:15:52 -0700
From: fantast...@gmail.com
To: dotnet...@googlegroups.com
Subject: [dotnetopenauth] Re: OAuth2 no javascript crossdomain possible?

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/1ekSAIgn5ksJ.

[fantastischIdee]

A bit of overkill for my problem. But thanks anyway. I found the more simple resolution ;-)

[fantastischIdee]

I found the problem / solution!

1. You have to add this in the web.config:

<system.webServer>

<httpProtocol>

<customHeaders>

<add name="Access-Control-Allow-Origin" value="*" />

</customHeaders>

</httpProtocol>

</system.webServer>

2. This is not working in the Visual Studio Development Environment / cassini web server! So testing on a real server!

[John Bradley]

They have both been approved.   At the moment Bearer is the only approved token profile.

A new work item for proof of possession tokens is starting.   This may include some or all of the now likely abandoned MAC token profile.

John B.

[Øyvind Sean Kinsey]

I'll be damned...

Either way, I bet you know as well as I do that these getting approved or not is of little consequence - in the grand sceme of thing it has little meaning as no-one is ever going to implement the specs to the full extent. At FB I have several diffs ready to move our implementation forward in terms of version, but I no longer see any reason as to why I would want to. 
If you ask me, the spec should have had a feature freeze as soon as it was deemed useful, and from there on only security related issues (like audience restriction etc) should have accepted. 

Oh wait, that could have been OAuth WRAP :)

Just read http://www.thread-safe.com/2012/08/oauth-2-approved-by-iesg-and-sent-to.html - the Document Quality section is a joke :/

But this is all for a different forum I guess...

Øyvind Sean Kinsey
San Francisco, CA

[Andrew Arnott]

Oyvind,

 

Please do migrate FB to newer drafts of OAuth 2.  DNOA still have several hacks in there to support FB that I'd really like to remove.  Not just spec updates, but flat out bugs in FB (like not returning the right content-type http response header). 

 

It's going to be hard enough to support OAuth2 in spec libraries with as open-ended a protocol as it is.  Let's not preserve an unnecessary dimension of which draft a popular service is on, please. :)

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Andrew Arnott]

Thanks for sharing your solution.  I hesitate to put this into the sample because I don't fully understand the security ramifications of doing so. If this generally makes the XSS attack surface much larger on a site, I can hardly recommend anyone use it.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/IhJ3a-KBVUgJ.

[fantastischIdee]

of course you can  replace the value="*" in

<add name="Access-Control-Allow-Origin" value="*" /> 

with the domain-name you allow. 

You can find this solution all over the internet. My main problem was that this wouldn't work in the Visual Studio Development Web Server. But on a real IIS server this solution will work.