Hi all,
I'm looking to apply OAuth for a particular use case with a Javascript client
and would like to get some guidance with this. Bear with me as I'm new to this
list.
I have a Javascript client which needs to be deployed on a number of different
sites for which we don't have control over
Hi Phil,
the server won't see the access-code, cause it is returned within the hash
that stays at the client-site:
http://.../returnUri#access_code=ABCDE.
By definition, the returnURI has to be the URI that was registered for the
client. IMHO, you are only allowed to add additional URL-
Hi Manfred,
On 5 Feb 2014, at 11:30, Manfred Steyer wrote:
> Hi Phil,
>
> the server won't see the access-code, cause it is returned within the hash
> that stays at the client-site:
> http://.../returnUri#access_code=ABCDE.
>
That's excellent. I hadn't picked that up in the text. I t
Well, this means you are completely dependent on a security model that
is based on a very specific property of HTTP
redirects. The User agent MUST NOT forward any component of a fragment
URI in a redirect - you are depending on the user having
a conformant and uptodate user agent.
I would say t
While you should always factor in an analysis of the security properties of
your client, you should also realize that by hosting the client completely
inside the browser, most of the benefits of the code flow go away. You're no
longer able to separate the knowledge of different parts of the prot
Well, there is a fundamental difference between the security properties
of implicit vs. code flow: in the former access tokens are passed via
URLs (protected only by the fragment URI requirement), whereas in the
latter this is never the case. So I do see a foundational difference in
security pro
The implicit flow is intended to get a access code to JS clients in the
browser. It is true that you could use the code flow, but only if the AS
token endpoint allowed CORES requests.
Given that the client is in the UA and has a direct TLS connection to the
Authorization endpoint, from the cl
Thanks all - some interesting points raised.
I've used the Authorisation Code grant for a couple of other use cases on other
projects. The Implicit Grant is less desirable but it fits here for me because
of the particular constraints of the client and its hosting environment. The
level of sec
You can use PostMessage if you control both the client and AS.
Google uses it in there identity toolkit if you use there g+ Java Script
client. http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.html
There is some example code at
https://code.google.com/p/oauth2-postmessage-profile
This looks along the same lines as the solution my colleague here has proposed
but I was unsure of the security implications and unaware of any existing
implementations.
I agree that a standardised profile for this would be helpful.
Thanks,
Phil
On 5 Feb 2014, at 21:49, John Bradley wrote:
> Y
The security for PostMessage and fragment encoded is similar as long as you pre
register the JS origin of the client and use TLS.
Some have argued that PostMessage with a registered JS origin is a more secure
way of doing CORES than using fragment encoding in a redirect.
With fragment encodin
Thanks for your comments, Phil. I'm working on addressing them at present.
One comment confuses me. You wrote "Section 4.1 - It would be good to have an
example with a software statement and no initial access token (or both)." Yet
the last example in Section 4.1 already is such as an example
Oh, I should add that I disagree that it's not necessary to return the software
statement. It's a key part of the client registration information, and so
should be returned like the other client registration information actually used.
-- Mike
-Original Messa
13 matches
Mail list logo
