On Thu, Aug 10, 2023 at 9:40 PM George Fletcher wrote:
> Hi Matthias,
>
> First, OAuth is about authorization and NOT authentication. If you are
> concerned with Authentication then this thread should move to the OpenID
> Connect working group mailing list :)
>
Allow me to set the public
I very much agree with Neil here, sending the authorization code to
application URLs is a recipe for leaking that code through the Referer
header to any remote site that content is loaded from (JS, analytics,
images etc. etc.). In addition to the inherent risk of "sloppy" pattern
matching,
Hi,
One more:
I'm planning to add support to the next release of mod_oauth2, an Apache
HTTPd module implementing the OAuth 2.0 RS functionality, see:
https://github.com/zmartzone/mod_oauth2/blob/master/README.md
Regards,
Hans.
On Tue, Jan 3, 2023 at 6:51 PM Vittorio Bertocci wrote:
>
there's DPoP support in liboauth2:
https://github.com/zmartzone/liboauth2/blob/v1.4.5/src/dpop.c#L331-L441
albeit it not updated to the latest draft yet
liboauth2 is used in OAuth 2.0 Resource Server modules for
Apache/NGINX (mod_oauth2/ngx_oauth2_module)
Hans.
On Wed, Aug 10, 2022 at 11:39 PM
Hi Denis,
thanks for correcting the thread topic:
On Tue, Mar 29, 2022 at 10:19 PM Denis wrote:
> nothing stops Alice from logging in on Bob's device, obtaining tokens for
> access and then leave Bob with the device, even in long term user accounts
>
> Even so, Alice will be unable to use that
On Tue, Mar 29, 2022 at 9:54 PM Denis wrote:
> Nothing stops Alice from giving her token that says “This is Alice” to Bob
> and having Bob use it.
>
> Such scenario does not exist in the context of long term user accounts.
> However, it is important first to understand the concept
> of long term
AFAIK this topic has been discussed before, e.g.:
https://mailarchive.ietf.org/arch/msg/oauth/gIuIrxeXudRBg8L6RYGDElxrc4s/
Hans.
On Fri, Dec 17, 2021 at 9:44 PM Pieter Kasselman wrote:
> The problem isn’t invalid URLs but malicious ones. Given a choice between
> a sub-optimal user experience
+1 for adoption, I'm impartial to the name
Hans.
On Tue, May 4, 2021 at 11:03 PM Aaron Parecki wrote:
> Okay, I have come around to this idea and agree that we shouldn't use
> "BFF" to refer to this pattern. The only reason I am continuing the
> discussion in this thread is that if we agree we
IMHO this use case is about proving the ownership of an e-mail address to
authenticate the user to obtain an access token.
The authorization code is not really suitable because it is supposed to be
short lived and (more or less by induction) supposed to be associated with
an account at the AS.
I'd
Thanks Vittorio and Brian for starting this work: I have deployed this
pattern in the field on a number occasions, at security and tech savvy
organizations, on their request.
I'd describe it as a regular OAuth 2.0 web client with the addition of a
well known endpoint meant for in-browser
+1
Hans.
On Wed, Jul 15, 2020 at 7:43 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a *call for adoption* for the following *OAuth 2.1* document as a
> WG document:
> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>
> Please, provide your feedback on the mailing list by *July
I would also seriously look at the original motivation behind ROPC: I know
it has been deployed and is used in quite a lot of places but I have never
actually come across a use case where it is used for migration purposes and
the migration is actually executed (I know that is statistically not a
I support the adoption of PAR
Hans.
On Tue, Dec 17, 2019, 22:15 John Bradley wrote:
> I support addoption
> On 12/17/2019 11:01 AM, Aaron Parecki wrote:
>
> I support the adoption of PAR.
>
> Aaron Parecki
>
>
> On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef
> wrote:
>
>> All,
>>
>> This
How about:
- don't use the Implicit or Resource Owner Password Credentials grant types
- perform exact matching of redirect URIs and make then Client/AS specific
- use PKCE
Hans.
On Tue, Nov 19, 2019 at 5:58 PM Torsten Lodderstedt
wrote:
>
>
> > On 19. Nov 2019, at 17:10, H
On Tue, Nov 19, 2019 at 10:38 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Hans,
>
> > On 18. Nov 2019, at 04:11, Hans Zandbelt
> wrote:
> >
> > Hi,
> >
> > Please find my feedback from page 21 onwards below.
> >
> > Ha
Hi,
Please find my feedback from page 21 onwards below.
Hans.
Overall I would argue there's room for a very concise guidance section that
says: do this, don't do that, without explanation, just as a reference for
developers; the current text provides in depth analysis but that is perhaps
not
Hi,
Please find my feedback on page 11-20 below.
Hans.
P14
4.2.4 For an RP there should be more explicit text and guidance about
having a single dedicated immutatable redirect URI per client that
"demultiplexes" access to the protected resource by storing the original
location that the user
screenshot...
Hans.
On Fri, Nov 8, 2019 at 2:13 PM Denis wrote:
> Hello Hans,
>
> You wrote:
>
> one client can always share the protected data with another client once
> retrieved, regardless of pop or secure elements
>
> No, there exist means that prevent a client to share the protected data
one client can always share the protected data with another client once
retrieved, regardless of pop or secure elements
Hans.
On Fri, Nov 8, 2019 at 8:38 AM Denis wrote:
> Daniel,
>
> No. It is not a correct summary. One client can allow another client to
> get an access token that belongs to
Hi,
Please find my feedback on the first 10 pages below.
Hans.
Overall:
- grammar in the first sections: there's a lot of comma-separated sentences
that could/should be reworked by a native speaker
- perhaps readers guidance pointing developers straight to section 3. as
Torsten said on the call
"Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix will cause new compliant reserve proxies to
> automatically scrub the inbound HTTP header.
>
> * The NAME part still makes the header easily identifiable (I think Rich
> Salz had this concern).
>
>
t, potentially optional, will provide a line of
> defence against config errors in old legacy reverse proxies.
>
> All concerns should then get covered.
>
> Vladimir
> On 31/10/2019 12:48, Hans Zandbelt wrote:
>
> the way I see this is that stripping and setting the headers must be
the way I see this is that stripping and setting the headers must be part
of the implementation of the protocol itself, it should not be something
left to a non-atomic piece of configuration by an administrator; I
implemented it like this in the Apache implementation of Brian's TTRP spec
[1] and
+1 to Justin's and Brian's comments, I am interested to contribute and I
will try and be there in person as well
Hans.
On Tue, Oct 29, 2019, 22:56 Brian Campbell wrote:
> +1 to pretty much everything Justin said there.
>
> With some facilitating assistance from Ben it looks like there's now an
I am interested and should be able to make it.
Hans.
On Tue, Oct 15, 2019 at 5:45 PM Hannes Tschofenig
wrote:
> Hi all,
>
> we would like to hold a virtual interim meeting to discuss the next steps
> regarding the OAuth 2.0 Security Best Current Practice (
>
indeed OAuth != identity see https://oauth.net/articles/authentication/
Hans.
On Sat, Aug 17, 2019 at 8:31 PM John Bradley wrote:
> The openID Connect kind of OAuth server.
>
> OAuth on its own is not designed to be secure for identity federation.
>
> John B.
> On 8/17/2019 1:23 PM, Salz, Rich
+1, as discussed before
Hans.
On Mon, Jul 22, 2019, 18:25 Brock Allen wrote:
> I think the implication is that the server-side would use something like
> OIDC to the token server in order to establish the identity of the user.
> The difference is that this would be driven from the server-side
hat was brought up for including sub only for user
>> based ATs was to use it as heuristic for telling those tokens apart from
>> app-only ones. To that end, *Karl MCGuinness suggested that we include
>> grant_type as a return claim, which the RS could use to the same effect*..
>
lps ASes to provide the desired functionality
> without imposing changes that will ripple across their codebase well beyond
> this particular use case.
>
> On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt
> wrote:
>
>> I understand your legacy-breaking point (and do see a n
e’s adding a new claim- which I
> can literally already do in various commercial ASes via extensibility
> points, without changing their code.
>
>
> On Mon, May 6, 2019 at 15:11 Hans Zandbelt
> wrote:
>
>> I'm suggesting that whichever "sub" and "client_i
guidance requires a big effort to be applied
> are very much in scope for me.
>
> On Mon, May 6, 2019 at 14:54 Hans Zandbelt
> wrote:
>
>> the scope and way of generating sub/client_id is orthogonal to the
>> semantics IMHO but if I'm the only one who thinks so, I'll rest m
>
> On Mon, May 6, 2019 at 13:49 Hans Zandbelt
> wrote:
>
>> I may be missing something but I'd argue that by requiring and comparing
>> both "sub" and "client_id" we achieve the same semantics without a
>> new/additional claim (barring na
I may be missing something but I'd argue that by requiring and comparing
both "sub" and "client_id" we achieve the same semantics without a
new/additional claim (barring name spacing)
Hans.
On Mon, May 6, 2019 at 8:58 PM Karl McGuinness wrote:
> Makes sense that we don’t want to further couple
OAuth 2.0 has its merits and will be around for the next 20 years or so;
yet we're bumping into its limitations every day if not only for its
complexity and the incomprehensibility for regular IT peeps that don't have
the full historical background; support for transactions is obviously
missing
+1
Hans.
On Mon, Apr 8, 2019, 19:34 John Bradley wrote:
> I agree this should be adopted as a working group document.
>
>
> On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
> > Hi all,
> >
> > this is the call for adoption of the 'JWT Usage in OAuth2 Access
> Tokens' document following the
map, but if
> we’re to create a JWT access token standard, it’s reasonable to require
> that the claims usage comply with the JWT standards.
>
>
>
> -- Mike
>
>
>
> *From:* Hans Zandbelt
> *Sent:* Thursday, April
cipal that is the subject of
> the JWT.
>
>
>
> If an access token uses “sub”, its usage must comply with the definition
> from RFC 7519.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth *On Behalf Of *George
t; as a special class will just make things more
> complicated. If we need a claim to identify the subject is a "human" then
> why not just add that. This doesn't break anything and makes it easy for
> people to detect this case in those use cases where it's required.
> >
&
agreed but it (i.e. "sub") also brings us back to where we started
Hans.
On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell wrote:
> The same is true for most of the other main claims too - iss, exp, aud,
> sub, iat, etc.. They are defined in RFC 7519 not OIDC.
>
> On Thu, Apr 4, 2019 at 9:21 AM
ree that this will break a lot of existing flows... especially those
> using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
>
> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>
> great summary! this will hurt quite a few existing m2m deployments but I
&g
loss in expressive power, should that difference be relevant for the
>>> resource server.
>>>
>>> Dominick, Hans- I probably missed the security issue you guys are
>>> thinking of in this case. Of course, if this would introduce a risk I
>>> compl
hey always combine it.
>
> In reality this leads to potential security problems - this spec has the
> potential to rectify the situation.
>
> Dominick
>
> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandb...@zmartzone.eu)
> wrote:
>
> Without agreein
Without agreeing or disagreeing: OIDC does not apply here since it is not
OAuth and an access token is not an id_token.
The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
"The "sub" (subject) claim identifies the principal that is the
subject of the JWT. The claims in a
On Mon, Dec 3, 2018 at 4:18 AM David Waite
wrote:
> If (as Hans proposed) there was a mechanism for javascript to get access
> tokens to interact with protected resources in lieu of the client, there
> could be BCP around managing that (which would likely also overlap with a
> genuine
one
> (another example being a reverse proxy which maps remote OAuth endpoints
> into local, session-token-protected ones). I personally am just not sure
> how you would define the communication between back-end and front-end
> portions of the client in these architectures as a standar
+1 to the suggestions that Vladimir raises; I've seen a fair number of
requests in the field for exactly that
Hans.
On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov
wrote:
> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>
> To start with, the AS may use refresh token rotation in
Hi all (and Brian :-)),
Whilst implementing the client side of OAuth 2.0 Token Exchange into an
Apache module I ran into some questions wrt. authentication to the token
exchange endpoint as specified in section 2.1:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14#section-2.1
1.
+1
Hans.
On Sat, Jul 21, 2018 at 7:12 PM, Filip Skokan wrote:
> I support the adoption or this document by the WG.
>
> Filip Skokan
>
> Odesláno z iPhonu
>
> 19. 7. 2018 v 19:43, Rifaat Shekh-Yusef :
>
> Hi all,
>
> This is the call for adoption of the 'JWT Response for OAuth Token
>
___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
[image: Ping
om/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
and companion website:
http://no-oauth.insanecoding.org/
regards
antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt
d.
Thanks,
George
On 3/17/16 1:25 PM, Hans Zandbelt wrote:
a good AS (at first) may become compromised and attack another AS;
whilst I agree it is less likely and less easy in static configs
(hence my point about the dynamic scenario) the root cause is not
related to configuration: it is a runtime at
.com/gffletch
Office: +1-703-265-2544 Photos:http://georgefletcher.photography
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
__
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https:/
source and 2 issuers doesn't need
discovery either but is vulnerable to the IDP mixup attack.
I'd really like to see the two being addressed independently of each
other, regardless of the fact that a Discovery solution *could* solve
the IDP mixup attack as well.
Hans.
--
Hans Zandbelt
lman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
, the cut-and-paste attack portion works,
but I cannot see how the first portion works. Could you elaborate?
2016年1月28日(木) 5:56 Hans Zandbelt <hzandb...@pingidentity.com
<mailto:hzandb...@pingidentity.com>>:
a perfectly valid - at first - AS may get compromised later and used to
<https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>https://tools.ietf.org/html/draft-sakimura-oauth-meta-05
that
was discussed at IETF
94 and had support
there should be
adopted as well.
Nat Sakimura
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ng list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work:george.fletc...@teamaol.com
<mailto:george.fletc...@teamaol.com>
AOL Inc. AIM: gffletc
s AS1)
This can be done if AS1 is a good AS but has it’s logs
compromised so that an attacker can read them. Hans Zandbelt
built a proof of concept for the attack.
In some cases the attacker gets the code and the credential to
use it at the good AS to
/www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
aol.com
<mailto:george.fletc...@teamaol.com>
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch
Office: +1-703-265-2544 Photos:http://georgefletcher.photography
__
with the provisions of BCP 78
and BCP 79 have already been filed. Please confirm.
Ciao
Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
or pointier: there are OAuth 2.0 deployments today that offer login
semantics because they have a REST/JSON user profile API that can be
accessed using the AT that was obtained in a code flow; should that be
acknowledged in the doc?
Hans.
On 10/16/14, 11:23 PM, Hans Zandbelt wrote
lazy and rely on it.
-- Justin
On Oct 20, 2014, at 2:42 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
or pointier: there are OAuth 2.0 deployments today that offer login semantics
because they have a REST/JSON user profile API that can be accessed using the
AT that was obtained
a round trip to fetch data it doesn't really want. Having the
separation between the authentication context and the profile information
really does make the code paths a bit simpler.
-- Justin
On Oct 20, 2014, at 3:20 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
My point
the write-up Justin had distributed.
Ciao
Hannes Derek
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
someone would put up a webpage describing the
difference between authorization and authentication and why people need to stop
confusing the two.
Oh wait...
On Oct 16, 2014, at 1:06 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
About the write-up: at the end of the metaphor section
antonio
On Sep 4, 2014, at 3:15 PM, Hans Zandbelt
hzandb...@pingidentity.com wrote:
I am convinced about the issue in the use case Antonio provided
but I hope not to close the door on returning errors to known and
trusted clients. Not sure anymore if that's possible though because
” the spec right? (I assume to avoid
open redirect…)
But other implementers do follow the spec hence they have this open
redirector… and this is not nice IMHO...
On Sep 3, 2014, at 7:40 PM, Hans Zandbelt hzandb...@pingidentity.com
mailto:hzandb...@pingidentity.com wrote:
On 9/3/14, 7:14 PM, Antonio
:50 AM, Antonio Sanso wrote:
Hi Hans,
I really fail to see how this can be addressed at registration time for cases
where registration is unrestricted (namely all the big Providers)
regards
antonio
On Sep 4, 2014, at 9:47 AM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Classifying like
registration the deviation or caution is not needed
Hans.
On 9/4/14, 1:44 PM, Antonio Sanso wrote:
hi Hans
On Sep 4, 2014, at 10:58 AM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Agreed, I see you point about the big providers using exactly the unrestricted
flow for which the trust model
Maybe just to clarify my point: where did the client_id in the example
that you gave come from?
Hans.
On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
yes, you are right about the unrestricted client use case; I just got
caught by the fact that you were talking about *unrestricted* client
they are not bad in some way.
John B.
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Maybe just to clarify my point: where did the client_id in the example that you
gave come from?
Hans.
On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
yes, you are right about the unrestricted
at registration time for cases
where registration is unrestricted (namely all the big Providers)
regards
antonio
On Sep 4, 2014, at 9:47 AM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Classifying like this must also mean that consent should not be stored until
the client is considered (admin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
___
OAuth mailing list
OAuth
fail to see the open redirect.
Hans.
On 9/3/14, 6:56 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 6:51 PM, Hans Zandbelt hzandb...@pingidentity.com
mailto:hzandb...@pingidentity.com wrote:
Let me try and approach this from a different angle: why would you
call it an open redirect when an invalid
On 9/3/14, 7:14 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Is your concern clients that were registered using dynamic client registration?
yes
I think your issue is then with the trust model of dynamic client
registration
the RFC.
John B.
Sent from my iPhone
On Sep 3, 2014, at 7:14 PM, Antonio Sanso asa...@adobe.com wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt hzandb...@pingidentity.com wrote:
Is your concern clients that were registered using dynamic client registration?
yes
Otherwise
on lobbying OIDC to join the IETF and this WG.
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
80 matches
Mail list logo
