Can anyone provide insight about what protection PKCE adds for browser
based apps using the authorization code flow? The PKCE intro says that the
specification is designed to mitigate an attack where:
> the attacker intercepts the authorization code returned from the
authorization endpoint within
Fixing my "with this technique" url: it should have been
https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .
On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel wrote:
> Hi All,
>
> I've just encountered a server that performs a redirect (back to the
> clie
Hi All,
I've just encountered a server that performs a redirect (back to the
client's redirect_uri) via POST instead of GET. This was surprising
behavior to me and broke my client implementation — but citing chapter and
verse, the server developer pointed out that
https://tools.ietf.org/html/rfc67
We've taken a similar approach for SMART Health IT [1], using the code flow
for public clients to support in-browser apps, and <1h token lifetime. (We
also allow these public clients to request a limited-duration refresh token
by asking for an "online_access" scope; these refresh tokens stop workin
d is more work.
> It also may give the server a false sense of security.
>
> John B.
>
> On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote:
>
> I think the confusion here is that I'm not using HEART's OAuth profiles :-)
>
> I'm using the SMART profiles, where
quite sure what you are doing.
>
> Perhaps Justin has a better answer.
>
> John B.
>
>
> On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote:
>
> John,
>
> I appreciate your response. I'm hoping you can clarify why you say that
> "HTTP POST... won't wo
Java Script API approach.
>
> John B.
>
>
> On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote:
>
> Thanks Justin,
>
> To clarify: John's comment and my question were about POST. (I do
> understand the behavior of HTTP POST and of window.postMessage; these are
>
h an AJAX call. What is wrong with
> this?
>
>
> ------
> *From:* Justin Richer
> *To:* Josh Mandel
> *Cc:* Oleg Gryb ; "" ;
> Liyu Yi
> *Sent:* Friday, July 1, 2016 2:00 PM
>
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragmen
John,
Could you clarify what you mean by "POST doesn't really work"? Do you just
mean that CORS support (e.g., http://caniuse.com/#feat=cors) isn't
universal, or something more?
On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote:
> Yes but POST doesn't really work for in browser apps.
>
> If it
Hi all,
I'm exploring the idea of an OAuth server comprising two separate
components:
* Static *frontend* web app that handles all UI functionality
* Headless *backend* that never returns HTML
These two components would communicate via some well-defined internal
protocol. For example, the fron
> Your way also works. It is just the reverse of my proposal. The difference
> being that my proposal does not need any coding on the server but just
> configuration, and it can return more metadata if needed.
>
> Cheers,
>
> Nat
>
> 2016年1月21日(木) 23:04 Josh Mandel :
>
Apologies if this is the wrong forum for my comment (and please direct me
to the appropriate place in that case), but I have two questions about the
propose mitigation (and the thinking behind it) that I think the write-up
could address:
1. Could the writeup clarify whether/how the primary "mixup"
Hi Brian,
In general, OAuth 2.0 is an authorization framework; as such it doesn't
directly describe authentication claims like "who is the current user?" or
"what is this user's e-mail address". OAuth 2.0 can be used as the basis
for authentication protocols like OpenID Connect [1], which you may
the attacker using that
> and passing in https://attacker.com as the desired RS and audience?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
> On Mar 16, 2015, at 11:12 AM, Josh Mandel wrote:
>
> Hi Phil,
>
> It might help me if you spelled ou
e this helps. It seems to me, a phishing link could tell your
> app to launch and pass in any RS value could it not?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
> On Mar 16, 2015, at 10:47 AM, Josh Mandel wrote:
>
> Hi Torsten,
t probably won't stop
>> the majority of possible AT leaks.
>>
>> John B.
>>
>>
>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt
>> wrote:
>>
>> Hi Josh,
>>
>> I'm not aware of a common practice to use such a parameter.
Hi All,
In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource
Server"), RFC6819 describes a threat where a counterfeit resource server
tricks a client into obtaining and sharing an access token from a
legitimate authorization server. One of the proposed mitigations involves:
"te
Hi Adam,
I'm not 100% sure what you're envisioning as an alternative to the implicit
flow, but if I'm reading between the lines of your question correctly,
there are two key parts to the answer, because the implicit flow is
designed to accomplish two key goals (vs. the authorization code grant):
You'll want to follow Vimeo's instructions -- probably be visiting
https://developer.vimeo.com/api and clicking "register your app". If you
have any questions, you'll want to visit http://developer.vimeo.com/help .
This mailing list is not affiliated with Vimeo, and we can't help you
register with
Forgive me if this is well-trodden territory, but I would have expected the
security considerations in this proposal to include a note to the effect of:
"In a scenario where a mobile client is contending with malicious apps on
the same device that listen on the same custom URL scheme, it's importa
Hi Justin,
Well, I spent ~20min to read over this pair of drafts (association +
software_statement). I have to say that in isolation, I find this approach
quite reasonable. In particular:
1. This approach does *not* require both a bearer token and
software_statement for the registration step. The
dependentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
>
>
> On 2013-08-20, at 8:30 AM, Josh Mandel wrote:
>
> The group may be interested in bits of the following classification that
> we put together for BlueButton+:
> http://blue-button.github.io/
The group may be interested in bits of the following classification that we
put together for BlueButton+:
http://blue-button.github.io/blue-button-plus-pull/#client-types
Here, we classified apps according to
1. whether they can protect a `client_secret` and
2. whether they can protect a `regist
> not everyone who's doing OAuth-protected APIs is doing SCIM
+1. (I'd wager very few have even heard of it.)
> People are already implementing the spec that we have, and will continue
> to do so even if the IETF drops it.
+1.
___
OAuth mailing list
on the AS starts to care is way outside of the spec.
>
> -- Justin
>
> On May 24, 2013, at 4:21 PM, Josh Mandel
> wrote:
>
> I think this discussion mixes two separable questions:
>
> 1. Should dyn-reg support client-side browser-based apps (which need
> client_id
I think this discussion mixes two separable questions:
1. Should dyn-reg support client-side browser-based apps (which need
client_ids for each AS they talk to, even if they only talk briefly and
then throw the credentials away)?
2. Which authorization flows are available to clients?
I have exa
As I understand it (corrections welcome!) rfc6749 says that public clients:
1. are defined functionally, as clients "incapable of maintaining the
confidentiality of their credentials" [section 2.1]
2. "MAY establish a client authentication method" if the server allows.
e.g. client password auth
27 matches
Mail list logo
