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 record
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, underes
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:
> Thank
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 Ri
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 an
+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 (counterpa
+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 29th.*
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 ve
there's:
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps
that mentions handing OAuth through a backend component in:
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02#section-6.2
There's an implementation of such a backend in a module for the Apache
webserver
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 i
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:
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 sui
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 agen
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 i
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
has the format "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 conc
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 ha
+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 (
> https://datatracker.ietf.org/doc/dra
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 p
>> One of the main reasons that 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
ems to
> do the exact opposite: it helps 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 yo
cale, there’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
r the 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
nt logic.
>
> 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 cl
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 tod
+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 positi
, 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,
principal 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 *G
rate out "humans" 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
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 Bri
hat 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 deployment
e there's
>>> no 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
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 agreeing or disag
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 JW
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 javascript-
I strongly support the recommendation of using code instead of implicit. I
do so based on my own experience in the field [1] and stick to that also
after reading the comments and (what I would call) workarounds on this
thread.
Hans.
[1]
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect
n a public 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
+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 combinati
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. the
+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
> Introspect
>
> > Can anybody confirm this attack, and whether it was described before?
> >
> > Cheers,
> > Daniel, Guido, Ralf
> >
> > --
> > Informationssicherheit und Kryptografie
> > Universität Trier - Tel. 0651 201 2847 - H436
> >
> > ___
> > OAuth
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
oint me to the thread.
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: i
_
OAuth mailing list
<mailto:OAuth@ietf.org>OAuth@ietf.org
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org&g
, and clients are designed to
be used across domains.
— Justin
On Mar 17, 2016, at 1:06 PM, Hans Zandbelt wrote:
I'm sorry to keep pushing on this but the attack is not opened up by discovery,
having two fixed ASes is already a threat: multiple ASes in general leaves the
client ex
etariat
___
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://www.ietf.org/mail
#x27;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 | Sr. Tec
iling 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
, 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 mailto:hzandb...@pingidentity.com>>:
a perfectly valid - at first - AS may get compromised later and used to
attack other ASes; that attacj do
gt;
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: gffletch
Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch
Office: +1-703-265-2544
ption.
However, it is only a
half of the story. I
believe
<https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>https:
st
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
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Ident
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
--
Hans Zandbelt | Sr. Technical Architec
lto: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
_______
OAuth mail
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
_
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
>>>>
ving something the client can read
directly saves 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 wrote
ly true enough that
developers get lazy and rely on it.
-- Justin
On Oct 20, 2014, at 2:42 PM, Hans Zandbelt 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 obta
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:
a
good catch! If only 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 wrote:
About the write-up: at the end of the metaphor section it says:
these discussions
and to first finish 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..
;> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com
>>>> phil.h...@oracle.com
>>>>
>>>>
>>>>
>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote:
>>>>>
>
n 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 wrote:
Classifying like this must also mean that consent should not be stored until
the client is considered (adm
sure they are not bad in some way.
John B.
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt 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 client use ca
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
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 wrote:
Agreed, I see you point about the big providers using exactly the unrestricted
flow for which the trust model (by definition) is out of scope of
14, 9: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 wrote:
Classifying like this must also mean
s by choice “violating” 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 mailto:hzandb...@pingidentity.com>> wrote:
On 9/3/14, 7:14 P
uld update the RFC.
John B.
Sent from my iPhone
On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote:
Is your concern clients that were registered using dynamic client registration?
yes
Otherwise the positive case is returning a response
On 9/3/14, 7:14 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt 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; that is left out of scope of the
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 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 scope is provid
Auth@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
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Iden
tter
focused 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
83 matches
Mail list logo
