[OAUTH-WG] session status change notification questions

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

Re: [OAUTH-WG] session status change notification questions

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

[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

[OAUTH-WG] HTTP signing and parameter validation

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

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

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 <brockal...@gmail.com> Cc: <oauth@ietf.org> <OAuth@ietf.org> Subj

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

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

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

, February 28, 2016 8:13 PM To: Brock Allen <brockal...@gmail.com> Cc: <oauth@ietf.org> <OAuth@ietf.org> 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

[OAUTH-WG] HTTP signing spec and nonce

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

[OAUTH-WG] HTTP signing spec typo

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

Re: [OAUTH-WG] TAuth

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

[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

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

ortant, before any 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

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

f what the correct answer 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];

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

ome guidance but so far we haven’t gotten 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

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

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 <da...@alkaline-solutions.com> wrote: On May 18, 2018, at 11:55 AM, Brock Allen <brockal...@gmail.com [mailto:brockal...@gmail.co

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

> 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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> 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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> 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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> 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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> 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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> 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.

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment

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 simply sugg

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment

ined, 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_verifier, but it wouldn't hurt

[OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment

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

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> 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.

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps and response_type/fragment

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 Allen

Re: [OAUTH-WG] popular apps that use appauth?

> 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-WG] popular apps that use appauth?

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

Re: [OAUTH-WG] Refresh tokens

> 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

Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

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

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

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

[OAUTH-WG] draft-ietf-oauth-jwsreq-21

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

[OAUTH-WG] thoughts on TMI BFF

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" process, so this feedback is

Re: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits

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

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

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.org Subject

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

nything 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: Thursday 17 March 2

[OAUTH-WG] PAR request_uri questions/guidance

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/#

Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

> 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

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

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

[OAUTH-WG] DPoP proof keys, token renewal, and confidential clients

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

Re: [OAUTH-WG] WGLC for Browser-based Apps

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

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

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 other IdPs then this mi

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

(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 relationships. Thi

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

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

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

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 redire