While I agree it may not be "proper" OAuth the fact is that the attack
is still possible and that means that some acknowledgement (security or
spec considerations) is required. Being able to MITM the UA or get the
user to click a link that takes them to a malicious "client" that is
really a MIT
I'm not sure what's described in the blog post is actually a variant of an
attack that anyone is really concerned about? A client developer would have
to change a production system to use an unfamiliar value for the token
endpoint based solely on a an email without even looking at service
documenta
Nov,
Are you referring to Sec 3.1.2.1 of RFC 6749.
Stating that the the redirection endpoint SHOULD require TLS, and that the AS
should warn the user if the redirect URI is not over TLS (Something I have
never seen done in the real world)
Not using TLS is reasonable when the redirect URI is us
Hi
I'm not sure if the next question is off topic or too low level,
hopefully not,
When the repeated authorization is skipped or only new scopes are
requested to be authorized as per the incremented auth approach, is it
reasonable to assume that the record that is used to track it all is
ac
The grants should be tied to the refresh token, or a grant record tied to the
confidential client.
For native iOS I have seen people bind it to the client_id if the client is
not confidential. That way if the user installs the same app on another device
it gets the same grants.
I am however
-- J Dred from --
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Fwiw, at Ozwillo, we track grants per user per client_id (we don't support
native apps; only web flows for now), and we don't do "incremental grants"
like Google: if you request scope B and the user had only granted scope A,
you'll get a token for scope B only. This is partly because our tokens are
I'm staying that it's sufficiently unlikely that it shouldn't be part of
the threat model and that a discovery lookup on iss isn't necessary.
On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher wrote:
> While it's a different way of getting the endpoints mixed up, I don't
> think that makes it in
Hi,
I support the adoption of this document as starting point for our work
towards OAuth discovery.
Restating what I already posted after the last IETF meeting: It seems
the document assumes the AS can always be discoverd using the user id of
the resource owner. I think the underlying assump
I understand what you're saying but disagree with the premise.
On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher wrote:
> So I'm fine with not requiring discovery in the simple case of an RS
> supporting a single AS. However, once the RS moves to supporting multiple
> authorization servers then
Hi,
PKCE only mentions OAuth 2.0 code flow - but wouldn’t that also apply to OIDC
hybrid flow e.g. code id_token?
—
cheers
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hi Mike,
I really like the new revision since it is much simpler :-)
My comments:
I'm fine with describing all mitigations we talked about in Darmstadt in
one/this spec. But the state check at the tokens endpoint is supposed to
be a mitigation against code injection/cut and paste attack, whic
Yes it also applies to the “code id_token” response_type. It would also apply
to “code token” , “code token id_token” response types as well though I can’t
think of why a native app would use those.
We can look at a errata to clarify. It is a artifact of resonse_type being
treated as a singl
Agreed.
The security ext draft might fit well with the general grab bag of issues
around all the "dynamic" cases.
It would be stronger than a new threat model ext draft which would likely be
informational.
Phil
> On Jan 26, 2016, at 12:10, Torsten Lodderstedt
> wrote:
>
> Hi Mike,
>
>
In MITREid Connect we track grants per client_id per user, and we have a
separate database object for storing them. I wouldn’t recommend simply updating
an access token that’s already in the wild with more power — that just sounds
wrong.
— Justin
> On Jan 26, 2016, at 1:57 PM, Thomas Broyer
John,
Nov is not talking about the redirection endpoint. I just noticed that
3.1.2.1 of RFC 6749 is just asking TLS by "SHOULD" and I think it needs to
be changed to "MUST" but that is not what he is talking about.
Instead, he is talking about before starting the RFC 6749 flow.
In many cases, a
To the end, perhaps amending RFC6749 so that the response type is treated
as a space separated value would be a better way to go?
2016年1月27日(水) 5:20 John Bradley :
> Yes it also applies to the “code id_token” response_type. It would also
> apply to “code token” , “code token id_token” response
Thanks!
we are almost done implementing PKCE in identity server.
And yea - a comment that PKCE applies to whenever a code is involved would be
probably helpful for other implementers. Even if that makes total sense, it is
not obvious.
—
cheers
Dominick Baier
On 27 January 2016 at 03:11:28,
18 matches
Mail list logo