Agreed -- I also support adoption.
-Brock
On 2/11/2025 10:20:35 AM, Dominick Baier wrote:
I support adoption.
On 7. February 2025 at 20:51:43, Michael Jones (michael_b_jo...@hotmail.com
[mailto:michael_b_jo...@hotmail.com]) wrote:
I obviously am in favor of adoption, as I believe we should
nows which IdP (if any) to redirect the user to.
On Thu, May 9, 2024 at 9:06 AM Brock Allen mailto:brockal...@gmail.com]> wrote:
Often a user needs to be presented with a prompt collecting some data to
identity the upstream IdP (e.g. email, or something else). This is very common
with B2B relat
nt to show off all
the business partners you integrate with for SSO.
Hope that makes sense.
-Brock
On 5/9/2024 12:04:13 PM, Dick Hardt wrote:
Would you elaborate on your point Brock? I don’t follow.
On Thu, May 9, 2024 at 8:54 AM Brock Allen mailto:brockal...@gmail.com]> wrote:
This is why r
This is why redirects with a custom UI are so essential. This allows other
forms of HRD without a NASCAR button list too. I hope that this will remain
possible, as it's crucial to so many business use cases.
-Brock
On 5/9/2024 11:06:23 AM, Dick Hardt wrote:
The NASCAR problem is rooted in the
acme.com] is an RP to all the federated IdPs —
and gathering the identifier to determine the IdP is out of scope of federation
protocols.
On Thu, May 9, 2024 at 9:54 AM Brock Allen mailto:brockal...@gmail.com]> wrote:
Could be, but if the IdP the RP uses is itself a gateway to othe
Hello --
While implementing PAR, some questions came up around the request_uri,
expiration, and one-time use semantics.
1: I found this conversation:
https://mailarchive.ietf.org/arch/msg/oauth/Xp5Wyt4N9U6RZZzMd6RctU3koQw/#
[https://mailarchive.ietf.org/arch/msg/oauth/Xp5Wyt4N9U6RZZzMd6RctU3ko
I agree with Philippe here.
If there are already documented attack vectors working around the techniques
presented in this document, then I worry it will give people a false sense of
security if they follow the guidance contained therein.
-Brock
On 8/10/2023 2:51:35 AM, Philippe De Ryck
wro
Hi -- another DPoP question :)
In the very last paragraph, in the very last sentence of section "5. DPoP
Access Token Request", draft-ietf-oauth-dpop-13 says:
"This existing sender-constraining mechanism is more flexible (e.g., it allows
credential rotation for the client without invalidating r
The current version of Duende IdentityServer supports everything included in
this proposal, except for the new unmet_authentication_requirement error which
has been added for v6.3.0 being released this summer.
https://duendesoftware.com/
Thanks.
-Brock
On 12/20/2022 8:15:52 AM, Rifaat Shekh-
> Has anyone faced the issue how an AS can handle a mix of OAuth 2.0 and
2.1 clients regarding PKCE enforcement?
In Duende IdentityServer we make this a per-client setting. That makes for a
very simple solution to the problem.
-Brock
___
OAuth mailing
nsequences
of using a protocol in a certain way is really important if we want to minimise
security issues that arise from implementation issues and protocol selection.
Cheers
Pieter
From: Brock Allen
Sent: Thursday 24 March 2022 02:25
To: George Fletcher ; Pieter Kasselman
; oauth@ietf.o
lateral attacks.
Anything we can do to encourage implementor to ask users to make fewer
decision, help them make better decisions and then protecting them in case of a
bad decision will help drive down risk.
Cheers
Pieter
From: Brock Allen [mailto:brockal...@gmail.com]
Sent:
I watched one of those videos and it seems to be that a proper consent screen
would have been the best and easiest line of defense. Is there something more
to the attacks where a better consent page (or any consent page for that
matter) would not have been sufficient?
-Brock
On 3/17/2022 5:10:
Hello all --
I just watched the recent OAuth WG Interim call on TMI BFF and had some
thoughts/feedback.
First of all, thanks Vittorio and Brian for the effort and allowing this
discussion. Given Vittorio's former employer I'm sure he's familiar with the
"rude Q&A" process, so this feedback is
Perhaps quite late, but a few comments/questions related to this:
1) When decoded, all the JWT samples are missing the "typ" claim from the
header, which I think should be "oauth.authz.req+jwt".
2) When validating the JAR if we are to validate the "typ" then this would be
incompatible with OIDC
I've seen the same. People have user-centric authorization systems where they
have a "service user" that they attach permissions to. In client credentials
they don't want to have to special case a client credentials caller (vs. a code
flow client) and instead just use the calling "user" to look
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 piece of the
application, as any other normal server-side client would. The result wo
> IdentityServer allows a choice of behavior on refresh token expiration time.
>It can have a absolute expiration time, or use a sliding window.
FWIW, in addition, those can be used together -- sliding & absolute. Finally,
refresh tokens can be re-use or one-time use only. These are all per-clie
> Interestingly I was told that switching to AppAuth increased login
>conversions for them with YouTube. That was a while ago.
I think you just said the magic words that marketing folks like to hear. Thanks
all.
-Brock___
OAuth mailing list
OAuth@iet
I often have push back from customers (mainly the marketing department/UX
folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They ask
for examples of any other popular or well known apps that follow this practice.
Does anyone on this list have examples?
TIA
-Brock
__
would typically suggest both killing
the code in the referrer as part of processing, and a server-wide Referrer
Policy of never or origin (as those have reasonably broad support) as
server-wide response headers are easier to operationally audit.
-DW
On Dec 8, 2018, at 3:53 PM, Brock
> How would the token endpoint detect login status of the user?
Oddball idea: why not use the cookie? If the assumption is that the RT is being
used from a client-side browser-based app, and CORS allows for credentials,
then perhaps this is a way to bind the RT to the user's browser session. The
is not where PKCE is
defined, PKCE has its own RFC.
- Aaron
On Sat, Dec 8, 2018 at 10:33 AM Brock Allen mailto:brockal...@gmail.com]> wrote:
For the same reason the implicit flow uses it -- to reduce exposure of the
response params. I know the code is protected with the code_verifie
this response type? Are you aware of any
OAuth (not OIDC) clients that do this today?
- Aaron
On Sat, Dec 8, 2018 at 7:29 AM Brock Allen mailto:brockal...@gmail.com]> wrote:
Should the BCP suggest using OIDC's response_type=fragment as the mechanism for
returning the code from the AS? Or s
Should the BCP suggest using OIDC's response_type=fragment as the mechanism for
returning the code from the AS? Or simply suggest using the fragment component
of the redirect_uri for the code, without a response_type parameter (IOW don't
allow it to be dynamic)?
-Brock
> Going from Implicit to Code deals with the problem of sending RT in the URL,
>which I agree is a plus. Is there anything else in a way of an improvement?
As far as I can tell, that's the only additional security feature (beyond what
we already use for mitigations today) that code flow adds. T
> Could you please expand on what you are achieving with replacing the URL
>using the history API? Removing the token from the browser's history, or any
>protection beyond that?
Just this block of code which would be run on the redirect_uri page loaded in
the client (after id_token/token valida
> It still lacks the ability to issue sender constraint access tokens.
So you mean at the resource server ensuring the token was really issued to the
client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP
token binding, which is still some time off)? Resource servers don't k
> Helps to prevent leakage, not injection in the authorization response.
So then wording and its motivation could get updated to correctly reflect that.
>> "OAuth 2.0 provides no mechanism for a client to verify that an access token
>> was issued to it, which could lead to misuse and possible im
> Finally, my last real concern (which is why I'm pushing back so much on code
>flow), is that this implies refresh tokens in the browser. My sense is that
>given the danger of this, the original OAuth2 RFC (via the implicit flow) was
>designed to limit the client's ability to obtain new access
Hello all --
I also have some thoughts/feedback on this document.
Personally I agree with some of the conclusions, but as it stands I think the
document's main conclusion that code flow is the real solution is not
sufficiently convincing.
I would like to see a brief summary of the current conc
endering HTML. So you can set those globally in your OP/AS and it can still
handle prompt=none properly. Unless I'm misunderstanding your last point.
-Brock
On 5/18/2018 2:21:06 PM, David Waite wrote:
On May 18, 2018, at 11:55 AM, Brock Allen mailto:brockal...@gmail.com]> wrote:
> I do
> I don’t believe code flow today with an equivalent token policy as you have
>with implicit causes any new security issues, and it does correct _some_
>problems. The problem is that you immediately want to change token policy to
>get around hidden iframes and special parameters.
Hidden frames
wer is yet.
John B.
Sent from Mail [https://go.microsoft.com/fwlink/?LinkId=550986] for Windows 10
From: Brock Allen [mailto:brockal...@gmail.com]
Sent: Friday, May 18, 2018 6:36 PM
To: John Bradley [mailto:ve7...@ve7jtb.com]; David Waite
[mailto:da...@alkaline-solutions.com]; Hannes
y new recommendation.
John B.
From: Brock Allen
Sent: Friday, May 18, 2:46 PM
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
To: David Waite, Hannes Tschofenig
Cc: oauth@ietf.org
One thing I maybe should have listed in the pros/cons in my original email is
session managemen
en too far.
IMHO it would be great to have a document.
Ciao
Hannes
From: OAuth [mailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]] On
Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org [mailto:oauth@ietf.org]
Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
Much like updated guidance was provided with the "OAuth2 for native apps" RFC,
should there be one for "browser-based client-side JS apps"? I ask because
google is actively discouraging the use of implicit flow:
https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290
>From what I
Why is TLS to the intospection endpoint not sufficient? Are you thinking there
needs to be some multi-tenancy support of some kind?
-Brock
On 3/18/2018 3:33:16 PM, Torsten Lodderstedt wrote:
Hi all,
I just submitted a new draft that Vladimir Dzhuvinov and I have written. It
proposes a JWT-ba
Doesn’t the recent PoP work address many of these concerns?
Also, as for developers disabling SSL — does anyone still do this and think
it’s safe? Or are people just being lazy? Or are there certain contexts that
I’m unaware of where this is valid?
-Brock
From: OAuth on behalf of Dick Hardt
, February 28, 2016 8:13 PM
To: Brock Allen
Cc:
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP
message inside the JWS envelope, because then you end up with a SOAP kind of
approach where
Now that I’m thinking about this, the only thing that comes to mind is a hash
of the value included somehow (which I’m sure you’ve already thought of).
That’s obviously more complexity and overhead for all scenarios to support this
edge case.
-Brock
From: Brock Allen [mailto:brockal
Another question related to HTTP signing.
It's not clear to me from the RFC if the resource server should be using the
incoming pop token JWS to know what to verify, or if the resource server
should have a preconceived notion of what should be sent in the pop token.
For example, the query param
Ok, missed that – thanks.
For now in my implementation I’m also ignoring this problem :)
-Brock
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen
Cc:
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
Given that the client can iterate over the query/headers in any order to
generate the concatenated value to hash, I think there's an issue with query
string or header values with repeated keys. I'll stick with query params for
simplicity in my sample.
If a client signs this concatenated query:
Question about the HTTP signing spec - why is there no nonce (and just a
timestamp)?
TIA
-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
In section 3.2 under calculating header list hash, there's an example of
hashed headers. For the values:
content-type: application/json
etag: 742-3u8f34-3r2nvv3
this is shown as the example:
"h": [["content-type", "etag"],
"bZA981YJBrPlIzOvplbu3e7ueREXXr38vSkxIBYOaxI"]
I believe th
Yep, my mistake. Apologies for the spam (including this apology email).
-Brock
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, January 12, 2015 8:21 AM
To: Brock Allen
Cc: OAuth@ietf.org
Subject: Re: [OAUTH-WG] session status change notification questions
If you are
A couple of questions about the session management spec related to the status
change notifications (section 4):
1) Is there a working reference implementation of the JavaScript that goes with
the current draft of the spec?
2) For the statement from section 4.2: “The OP iframe MUST enf
48 matches
Mail list logo
