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
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
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
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
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
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
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, 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
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
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-
10 matches
Mail list logo
