I support adoption.
On 7. February 2025 at 20:51:43, Michael Jones (michael_b_jo...@hotmail.com)
wrote:
I obviously am in favor of adoption, as I believe we should do the work to
close the identified security vulnerabilities in a timely manner. Thanks
to all who worked on this doc with me prio
Good examples of bypassing some of the recommendations from the web BCP and
OAuth 2.1
https://youtu.be/OpFN6gmct8c
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hi,
While implementing I found
Section 4.2 says
htu: The *HTTP* target URI (Section 7.1 of [RFC9110]), without query and
fragment parts, of the request to which the JWT is attached.
While Section 4.3 says
the htu claim matches the *HTTPS* URI value for the HTTP request in which
the JWT was re
Hi Aaron et al,
I re-read the latest version of the web app BCP. For me it has become
increasingly hard to follow, and so I’m concerned that it’s even harder for
the target audience this document is intended for.
It seems that over time more and more content got accumulated which IMO
jumps straig
s not
prevent CSRF attacks from within a site boundary. Scenarios could be a
compromised sub-domain, like sub-domain takeover or just some vulnerable
application co-located on the same site.
thanks
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
We have implemented it
https://duendesoftware.com/products/identityserver
———
Dominick Baier
On 4. September 2021 at 16:26:21, Rifaat Shekh-Yusef (
rifaat.s.i...@gmail.com) wrote:
All,
As part of the shepherd write-up for the OAuth 2.0 Authorization Server
Issuer Identification document, we
No. But they are CSRF protected (either SameSite or anti-forgery) and
HttpOnly.
———
Dominick Baier
On 17. February 2021 at 21:08:37, Neil Madden (neil.mad...@forgerock.com)
wrote:
Do you eliminate the cookies too?
On 17 Feb 2021, at 19:50, Dominick Baier wrote:
Well. Maybe it is at least
Well. Maybe it is at least worth while then to at least mention that you
could also take a slightly different approach and eliminate all tokens in
the browser - with the respective trade offs.
———
Dominick Baier
On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:
While
this doesn’t solve the XSS problem” -
this is absolutely correct. But when there are no tokens in the browser -
you can simply eliminate that part of the threat model ;)
———
Dominick Baier
On 17. February 2021 at 18:30:23, Vittorio Bertocci (
vittorio.berto...@auth0.com) wrote:
Thanks Dominick
implement a more and more
common security guideline these days - namely: “no JS-accessible tokens in
the browser” - but this document doesn’t cover this.
cheers
———
Dominick Baier
On 16. February 2021 at 22:01:37, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:
On Mon, Feb 15
it is in-memory or
local storage) - but this exactly seems to happen in D.
Thanks
———
Dominick Baier
On 12. February 2021 at 21:46:20, Vittorio Bertocci (
vittorio.bertocci=40auth0@dmarc.ietf.org) wrote:
Dear all,
Brian and yours truly are proposing a new specification that shows how the
user
+1
———
Dominick Baier
On 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef (rifaat.s.i...@gmail.com)
wrote:
All,
This is a call for adoption for the following AS Issuer Identifier in
Authorization Response as a WG document:
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth
Also IdentityServer implements JAR
https://github.com/IdentityServer
———
Dominick Baier
On 21. September 2020 at 21:22:17, Hannes Tschofenig (
hannes.tschofe...@arm.com) wrote:
Hi all
Because some procedural issues I have to update the shepherd writeup of the
JAR document and I wanted to
IdentityServer is.
https://github.com/IdentityServer
Cheers
———
Dominick Baier
On 17. September 2020 at 14:56:01, Hannes Tschofenig (
hannes.tschofe...@arm.com) wrote:
Hi Vittorio, Hi all,
I am working on the shepherd writeup for
and you can find the latest version
here:
https://github.com
Good point. Thanks, Brian.
We should retrofit typs everywhere..in hindsight.
———
Dominick Baier
On 22. July 2020 at 23:55:20, Brian Campbell (bcampb...@pingidentity.com)
wrote:
Because it wouldn't actually prevent it in this case due to JWT assertion
client authentication (
Even more. Jwsreq should have it. But the authors decided against it.
———
Dominick Baier
On 23. July 2020 at 07:38:04, Dominick Baier (dba...@leastprivilege.com)
wrote:
Good point. Thanks, Brian.
We should retrofit typs everywhere..in hindsight.
———
Dominick Baier
On 22. July 2020 at 23:55
Why not use a typ header as suggested by the JWT BCP?
———
Dominick Baier
On 22. July 2020 at 17:37:41, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:
The TL;DR here is a somewhat tentative suggestion that a brief security
consideration be added to
https
I support adoption
———
Dominick Baier
On 16. July 2020 at 01:54:08, William Denniss (
wdenniss=40google@dmarc.ietf.org) wrote:
I support adoption.
On Wed, Jul 15, 2020 at 4:37 PM wrote:
> +1
>
>
>
> *From:* OAuth *On Behalf Of *Dick Hardt
> *Sent:* Wednesday, July
Hey,
Have a look at https://github.com/IdentityServer/IdentityServer4
<https://github.com/IdentityServer/IdentityServer4>
I <https://github.com/IdentityServer/IdentityServer4>t’s an OIDC certified
..NET implementation
Thanks!
———
Dominick Baier
On 25. June 2020 at 11:27:34, Thib
. Is it a technical issue?
thanks
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hi,
This has been brought up before - but no response.
Either I can’t find it - or it is missing. But is the setting the JWT typ
explicitly mentioned somewhere?
I think it should to prevent cross JWT confusion.
Thanks
———
Dominick Baier
___
OAuth
Would be also interested in the official language here.
Would an implementation need to introduce an optional “strict JAR
validation mode” - which complies with JAR, but breaks OIDC compatibility?
———
Dominick Baier
On 7. May 2020 at 15:32:33, Brock Allen (brockal...@gmail.com) wrote
In IdentityServer, the PKCE requirement is per client.
We started with a default of false - and now switched to true.
FWIW
———
Dominick Baier
On 10. May 2020 at 22:22:35, Mike Jones (
michael.jones=40microsoft@dmarc.ietf.org) wrote:
Exactly!
I believe that this also the same point that
right because all of our customers
use both in conjunction.
IOW - you move our cheese ;) But don’t worry about it.
———
Dominick Baier
On 4. May 2020 at 10:55:41, Dominick Baier (dba...@leastprivilege.com)
wrote:
Hey,
No problem - this email was not intended to make you change the document.
Just
same conclusion. And yes I know - you cannot please everybody ;)
Still some comment inline...
thanks
———
Dominick Baier
On 4. May 2020 at 10:20:16, Vittorio Bertocci (vittorio.berto...@auth0.com)
wrote:
Thank you Dominick, very useful!
I’d like to understand more about the security risk
-writing and I guess this applies to any reasonably complex
system that is already out there. So I am still not sold that the “dual
purpose” claims are the best choice. YMMV.
IOW - we will not adopt the sub/client_id semantics as proposed by the
document.
My 2c / cheers
———
Dominick Baier
Oh and while we are at it - could you also fix the typo in my name? Thanks
;)
———
Dominick Baier
On 21. April 2020 at 09:43:49, Vittorio Bertocci (
vittorio.berto...@auth0.com) wrote:
This is a great point. In my head I just considered the OIDC semantic and
thought only of highlighting the app
...
———
Dominick Baier
On 20. April 2020 at 09:48:51, vittorio.berto...@auth0.com (
vittorio.berto...@auth0.com) wrote:
Thanks Dominick for your comments!
Inline
*>** All other OAuth specs make a very clear distinction between users and
client.*
There’s a nuance worth highlighting here:
Hence my question
What should be the recommended semantics - “informative” - “or don’t accept
before a certain time stamp” ?
———
Dominick Baier
On 20. April 2020 at 09:05:53, Philippe De Ryck (
phili...@pragmaticwebsecurity.com) wrote:
In theory, you can issue a token that only becomes valid
Just a quick data point -
The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.
I guess my real question is - what’s the difference between the two
practically speaking - and shouldn’t be the more common (aka supported by
most libraries) be used?
———
Dominick Baier
On 20
Tbh - the most valuable part of the doc to me is the definition of the
“at+jwt” typ. For the rest I’d rather like to see just some standard claims
and IF they are used, which semantics they have.
cheers
———
Dominick Baier
On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.i...@gmail.com)
wrot
style
architecture instead.
Cheers
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
+1
———
Dominick Baier
On 17. March 2020 at 14:18:37, Torsten Lodderstedt (
torsten=40lodderstedt@dmarc.ietf.org) wrote:
+1
> On 17. Mar 2020, at 13:40, Vladimir Dzhuvinov
wrote:
>
> +1 for DPoP
>
> On 17/03/2020 14:25, Rob Otto wrote:
>> I support adoption
>&g
the wording needs
to be clearer.
———
Dominick Baier
On 12. March 2020 at 23:15:19, Vittorio Bertocci (
vittorio=40auth0@dmarc.ietf.org) wrote:
Rotation can be used to detect leakage, right? Client credentials offer
more guarantees, but unless you are using private JWTs with a non
exportable
s possible.
———
Dominick Baier
On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:
It looks like there is consensus to remove ROPC for a user -- but that the
password grant is not a bad practice for service accounts. That leads to
providing clarity on service accounts.
1) add servi
No - please get rid of it.
———
Dominick Baier
On 18. February 2020 at 21:32:31, Dick Hardt (dick.ha...@gmail.com) wrote:
Hey List
(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron,
Torsten, and I are working on)
Given the points Aaron brought up in
Agreed - that’s why we disabled request_uri by default and added
extensibility points to implement validation.
I thought it is odd that this was not mentioned in the typical “security
considerations” in the OIDC spec..
———
Dominick Baier
On 16. January 2020 at 08:07:44, Neil Madden (neil.mad
I’d support adoption of both PAR and RAR.
———
Dominick Baier
On 16. December 2019 at 23:02:58, Rob Otto (
robotto=40pingidentity@dmarc.ietf.org) wrote:
I’d support adoption of both PAR and RAR.
On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle wrote:
> +1 for a call for adopt
“chosen code challenge attack” (at least that’s how I
understood it) - again enforcing that makes the AS logic more complicated
d) it’s a clear statement
cheers
———
Dominick Baier
On 11. December 2019 at 03:29:14, Nat Sakimura (sakim...@gmail.com) wrote:
Correct. The WG supported the precedence
August will conflict with holiday time for most Europeans…
Just been to Trondheim last week - it was lovely weather.
———
Dominick
On 25. July 2019 at 22:14:28, Mike Jones (
michael.jones=40microsoft@dmarc.ietf.org) wrote:
I'm not aware of any conflicts for any of the three sets of dates.
-
:
On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
wrote:
> I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
> Unless you want to dive into the details h
, Dominick Baier wrote:
Forgot one more thing
In 7.1
Browser-based apps MUST use the OAuth 2.0 "state" parameter to
protect themselves against Cross-Site Request Forgery and
authorization code swap attacks and MUST use a unique value for each
authorization request, and MUST
ate in the
authorization response matches the original state the app created.
Isn’t state optional when PKCE is used?
thanks
———
Dominick
On 22. July 2019 at 08:14:33, Dominick Baier (dba...@leastprivilege.com)
wrote:
Hey,
Just read the spec - good to see the progress. Some feedback:
I am yet
Hey,
Just read the spec - good to see the progress. Some feedback:
I am yet undecided if I like the categorisation of the “Application
Architecture Patterns”. I definitely want to distinguish between
applications only accessing same-site back-end services and “others”. Not
sure if “dynamic applic
+1
———
Dominick
On 8. April 2019 at 20:21:21, William Denniss (
wdenniss=40google@dmarc.ietf.org) wrote:
I support adoption of this draft as a working group document.
On Mon, Apr 8, 2019 at 11:11 AM George Fletcher wrote:
> +1 for me as well :)
>
> On 4/8/19 1:38 PM, Hans Zandbelt wrote:
;>
>>- Despite OAuth2 not requiring any specific format for ATs, through
>>the years I have come across multiple proprietary solution using JWT for
>>their access token. The intent and scenarios addressed by those solutions
>>are mostly the same across vend
.. but
> nevertheless I agree with the potential confusion and thus security
> problems arising from that (though one may argue the semantics are the
> same).
>
> Hans.
>
> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier
> wrote:
>
>> Yes I know - and I think i
/acting only in terms of users
Hans.
On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier
wrote:
> IMHO the sub claim should always refer to the user - and nothing else.
>
> OIDC says:
>
> "Subject - Identifier for the End-User at the Issuer."
>
> client_id should be used
in the
implementations are different enough to prevent developers from reusing
code and skills when moving from product to product.
- I asked several individuals from key products and services to share
with me concrete examples of their JWT access tokens (THANK YOU Dominick
Bai
A good example of a desktop application using browser authentication is
Github for Desktop.
They use custom URLs/callbacks for both OSX and Windows. Works very well.
———
Dominick
On 25. February 2019 at 11:48:20, Vittorio Bertocci (
vittorio=40auth0@dmarc.ietf.org) wrote:
Ahh, as John knows
The Uber app uses it for their OAuth flow to PayPal e.g.
———
Dominick
On 23. February 2019 at 18:05:33, Brock Allen (brockal...@gmail.com) wrote:
I often have push back from customers (mainly the marketing department/UX
folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They
as
+1
———
Dominick
On 21. February 2019 at 09:35:35, Dave Tonge (dave.to...@momentumft.co.uk)
wrote:
+1 for mtls_endpoints optional metadata
Dave Tonge
On Thu, 21 Feb 2019 at 00:09, John Bradley wrote:
> I agree.
>
> If someone really wants separate meta-data nothing stops them from having
>
complex code to work with. But that’s just my experience as, you know, an
actual developer.
Let’s keep the assumptions and snide remarks about others’ backgrounds off
the list, please.
--
Annabelle Richard Backman
AWS Identity
*From: *Dominick Baier
*Date: *Wednesday, February 13, 2019 at
mTLS-optional scenario to the
> mTLS-only scenario. This sidesteps the challenges of aligning the
> “either/or” semantics of mTLS-optional with some of the rigid parameter
> definitions in RFC8414 (see: token_endpoint,
> token_endpoint_auth_methods_supported).
>
>
>
>
'm struggling, however, to adequately gauge whether or not there's
sufficient consensus to go ahead with the update. There's been some support
for it voiced. As well as talk of other approaches that could be
alternatives or additional measures. And also some vocal oppositi
We are currently implementing MTLS in IdentityServer.
Our approach will be that we’ll offer a separate token endpoint that
supports client certs. Are you planning on adding an official endpoint name
for discovery? Right now we are using “mtls_token_endpoint”..
Thanks
———
Dominick
On 7. February
I agree with Vittorio -
While we all agree that implicit is outdated and we can do better (and it
is indeed good that this discussion has finally started for real) - the
communication around the (preliminary) results of the BCP was unfortunate
and not very responsible - quoting:
“Simply put, the
said before - at the end of the day the access token will end up in
the browser. Regardless how secure you made the authentication request in
the first place.
---
Dominick Baier
On 17 February 2017 at 19:06:23, Jim Manico (j...@manicode.com) wrote:
> Given a solid client library for JS, I th
(e.g. not using CSP) will always write bad code that might lead
to leaking a token.
---
Dominick Baier
On 17 February 2017 at 18:43:25, Adam Lewis (
adam.le...@motorolasolutions.com) wrote:
+1000
We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps
always use
them together - or put differently - I recommend against using OAuth on its own
without OIDC (besides client_creds/extension grants scenarios of course).
—
cheers
Dominick Baier
On 2 May 2016 at 04:08:25, William Denniss (wdenn...@google.com) wrote:
I'm inclined to think that
.
—
cheers
Dominick Baier
On 1 April 2016 at 00:46:03, Eduardo Gueiros (eguei...@jive.com) wrote:
Any plan to bring the libraries to more “young” languages like Swift in iOS and
Kotlin in Android?
> On Feb 26, 2016, at 12:30 PM, William Denniss wr
The nonce would allow to build a replay cache, the timestamp to trim that cache
and reject messages that are too old.
Similar protocols have a nonce for the above reasons (ws-sec msg security,
hawk)...
—
cheers
Dominick Baier
On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu
I also added a support for it to our .NET client library.
blog post here:
http://leastprivilege.com/2016/02/02/pkce-support-in-identityserver-and-identitymodel/
--
Dominick Baier
On 2 February 2016 at 09:25:43, Dominick Baier (dba...@leastprivilege.com)
wrote:
IdentityServer 2.4 has PKCE
IdentityServer 2.4 has PKCE support now as well
https://github.com/IdentityServer/IdentityServer3/releases/tag/2.4.0
--
Dominick Baier
On 1 February 2016 at 22:12:54, Mike Jones (michael.jo...@microsoft.com) wrote:
Congratulations on your deployment!
From: William Denniss [mailto:wdenn
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
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
I totally agree with that - and that’s how we gonna implement it in identity
server.
We are planning to introduce something called a “scope secret” - it’s like a
client secret but for resources.
—
cheers
Dominick Baier
On 20 Jul 2015 at 07:01:48, Justin Richer (jric...@mit.edu) wrote
67 matches
Mail list logo
