Re: [OAUTH-WG] Request to add a profile parameter to +jwt and +sd-jwt

Media type parameters are useful for subtypes that add a multitude of expansion options, such as multimedia formats with a multitude of codecs, encoding options, and profiles to define feature sets. The best usages of them I’ve seen is supplemental. A baseline JWT isn’t really able to be

Re: [OAUTH-WG] A Discussion of Multiple Suffixes

wMy concern is higher level, that we may be promoting over-expression of types. My interpretation of historical decisions/retconning was that +xml made sense because XML documents form an object model that can be processable independently of the document. For the example of SVG data in an

Re: [OAUTH-WG] Call for adoption - Identity Chaining

I support adoption -DW > On Nov 14, 2023, at 4:59 AM, Rifaat Shekh-Yusef > wrote: > >  > All, > > This is an official call for adoption for the Identity Chaining draft: > https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ > > Please, reply on the mailing list

Re: [OAUTH-WG] SD-JWT explicit guidance on parsing json strings

> On Oct 13, 2023, at 6:57 PM, Orie Steele wrote: > > > riffing on this, if it's possible to use a "simple and safe parser on the > untrusted data", before using a "maybe safe / probably fast " parser on the > trusted data, maybe do that : ) > >> This is also not dissimilar to additional

Re: [OAUTH-WG] SD-JWT explicit guidance on parsing json strings

> On Oct 13, 2023, at 3:52 PM, Orie Steele wrote: > > Inline (and sorry for repeating points / rambling) : > > On Fri, Oct 13, 2023 at 1:25 PM Brian Campbell > wrote: >> That makes sense in principle but is maybe not particularly actionable or >> helpful

Re: [OAUTH-WG] Reservations and observations about draft JWT and CWT Status List

From JWT RFC 7519, section-4: The Claim Names within a JWT Claims Set MUST be unique; JWT parsers MUST either reject JWTs with duplicate Claim Names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

> On Sep 27, 2023, at 1:18 PM, Atul Tulshibagwale wrote: > Now if MyCrazyLottery's OPRM says it needs "super admin privileges to your > Apple account", the resulting consent dialog from Google is going to say > "Apple is requesting super admin privileges to your Apple account". This >

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

On Aug 28, 2023, at 9:51 AM, Yannick Majoros wrote: > > You really have a point about refresh tokens here, but they are a separate, > real issue. Refresh tokens should be avoided whenever you can do without. Any > pattern that can keep them safe is on the same level, but their safety is >

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

I support adoption > On Aug 23, 2023, at 11:44 PM, Aaron Parecki > wrote: > > I support adoption. > > Aaron > > > On Wed, Aug 23, 2023 at 8:02 PM Rifaat Shekh-Yusef > wrote: >> All, >> >> This is an official call for adoption for the Protected Resource

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

> On Aug 23, 2023, at 12:33 PM, Watson Ladd wrote: > > On Wed, Aug 23, 2023 at 10:02 AM David Waite > mailto:da...@alkaline-solutions.com>> wrote: >> For example, are you talking about properties for anonymous credentials from >> the academic space as set

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

> On Aug 23, 2023, at 10:16 AM, Watson Ladd wrote: > > On Wed, Aug 23, 2023, 3:35 AM Daniel Fett wrote: >> >> Hi Watson, >> >> can you please be specific about the "standard, 22 year old security >> definitions" and "schemes of this type"? >> >> Not having to make assumptions would

Re: [OAUTH-WG] OAuth Trust model

> On Aug 15, 2023, at 11:40 AM, Rodrigo Speller > wrote: > > So, during the flight, I reflected on Matthias' insistence: "What could we be > missing?" Brilliantly, I think Matthias raised a very important and fixable > point: “That the user MUST allow the connection on both sides on the

Re: [OAUTH-WG] OAuth Trust model

From an OAuth perspective, there isn’t much here - I can’t log into GitHub or stack overflow with OAuth, I need extensions such as those provided by OpenID Connect (or something more bespoke in Github’s case). From a general standards perspective, this would be more implementation guidance for

Re: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials

I support adoption -DW > On Jul 29, 2023, at 1:25 PM, Rifaat Shekh-Yusef > wrote: > > All, > > This is an official call for adoption for the SD-JWT-based Verifiable > Credentials draft discussed in SF. > https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/

Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

I’m in favor of adoption. -DW > On Jul 29, 2023, at 1:27 PM, Rifaat Shekh-Yusef > wrote: > > All, > > This is an official call for adoption for the Attestation-Based Client > Authentication draft discussed in SF. >

Re: [OAUTH-WG] A proposal for a new Internet Draft

This seems like something more appropriate for a group focused closer to the needs of groupware implementers (such as JMAP) to define. I would be worried about whether we are capturing the appropriate level of complexity for these as well as defining interoperable usage - for examples around

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

> On Mar 9, 2023, at 11:00 AM, Jaimandeep Singh > wrote: > > Dear All, > > IMO it is not recommended to add this section because of the following: > (a) It is a very specific use case for SPAs or similar design approach and > does not warrant mentioning the same in the security BPC as it is

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

> On Mar 9, 2023, at 1:57 AM, Vittorio Bertocci > wrote: > > On CORS for the authorization endpoint. I thought the MUST NOT was aimed at > preventing programmatic access to the authorization endpoint from user > agents. Flipping around: are there any other scenarios involving the >

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

I would suggest SHOULD guidance for CORS for OAuth token endpoints and authorization endpoints which are publicly accessible. There are a lot of misconceptions about the security properties of CORS, and in particular the security properties from disabling CORS for an otherwise safe resource.

Re: [OAUTH-WG] OAuth 2.0 Protected Resource Metadata

I support adoption by the working group. -DW > On Jan 24, 2023, at 2:38 AM, Giuseppe De Marco wrote: > > Hello everybody, > > I would like to bring to your attention this expired draft: > https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ > > I propose the take up this

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

e JSON object that forms its header. -David Waite (DW) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP - IPR Disclosure

I also am unaware of any IPR. -DW > On Aug 10, 2022, at 3:37 PM, Rifaat Shekh-Yusef > wrote: > > Daniel, Brian, John, Torsten, Mike, and David, > > As part of the shepherd write-up for the DPoP document, there is a need for > an IPR disclosure from the authors. >

Re: [OAUTH-WG] Call for adoption - SD-JWT

I can’t speak to what group or charter the JWP work would eventually be under, but the JWT specification is one of several examples of a specification that heavily leveraged the JOSE work but which was started here at OAUTH, outside of the (at the time active) JOSE WG. Without perusing old

Re: [OAUTH-WG] Call for adoption - SD-JWT

> On Jul 29, 2022, at 5:35 AM, Warren Parad > wrote: > > I too do not support adoption. > > Something is "off" for me, I don't quite get the expectation on the secure > flow, in this draft, doesn't the issuer have to know the claims that could be > requested up front? If the goal is to not

Re: [OAUTH-WG] Last Call: (JWK Thumbprint URI) to Proposed Standard

On May 11, 2022, at 6:45 AM, Rifaat Shekh-Yusef wrote: > On Wed, May 11, 2022 at 4:53 AM David Waite <mailto:da...@alkaline-solutions.com>> wrote: > The information dropping of the canonicalization in JWK thumbprints results > in a few important properties - in particular, a

Re: [OAUTH-WG] Last Call: (JWK Thumbprint URI) to Proposed Standard

RFC 7517 does define an "application/jwk+json" media type which could be used with the ct= query parameter for ni-scheme uri. The resulting ni-scheme URI could be used to refer to a specific generated JWK document. However, I do not believe this would be a sufficient way to indicate that this

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

I support the working group adopting this work. > On Apr 26, 2022, at 3:46 AM, Rifaat Shekh-Yusef > wrote: > > This is a call for adoption for the Step-up Authentication document > https://datatracker.ietf.org/doc/draft-bertocci-oauth-step-up-authn-challenge/ > >

Re: [OAUTH-WG] Listing OAuth Access Token Metadata

> On Apr 1, 2022, at 3:24 AM, Dhaura Pathirana > wrote: > > I would like to know if anyone has seen this (listing token metadata) as a > common use case in OAuth2 and a standard way of doing it had been proposed > before? OAuth Token Introspection (RFC 7662) defines a way to query for

Re: [OAUTH-WG] WGLC for DPoP Document

I also support publication of this specification -DW > On Mar 29, 2022, at 3:12 PM, Mike Jones > wrote: > > I support publication of the specification. > >-- Mike > > From: OAuth On Behalf Of Rifaat Shekh-Yusef > Sent: Monday, March

Re: [OAUTH-WG] WGLC for DPoP Document

> On Mar 28, 2022, at 8:28 AM, Denis wrote: >The primary aim of DPoP is to bind a token to a public key upon > issuance and requiring that the client proves possession >of the corresponding private key when using the token. This does not > demonstrate that the client

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

> On Mar 1, 2022, at 10:18 AM, Daniel Fett wrote: > > * The core of OAuth is easy to implement. The need to create or use a > library might not be obvious to developers. Of course, if you want a proper > implementation with correct error handling, observing all the security >

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

I support publication as well. -DW > On Feb 23, 2022, at 5:53 AM, Tim Cappalli > wrote: > > +1 in support of publication! > > > > Tim Cappalli | @timcappalli > did:ion:EiBgPHSLu66o1hQWT7ejtsV73PfrzeKphDXpgbLchRi32w > > > > > From: OAuth on

Re: [OAUTH-WG] DPoP and OpenID Connect

Hello Dmitry! AFAIK there isn’t any accepted work within OpenID Foundation defining an interaction between id_tokens and DPoP. Like most of the OAuth additions which have come out after OpenID Connect 1.0, one could expect that it would layer on top transparently as something which pertains

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

> On Feb 4, 2022, at 6:32 PM, Mike Jones > wrote: > > Kristina and I spoke about it today and we agreed that it makes sense to make > the hash algorithm explicit. So for instance, we’d propose that the example > urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

Re: [OAUTH-WG] Implicit Grant Flow for authentication on both Client UI and Back End by OIDC id_token verification

Sent from my iPhone > On Jan 18, 2022, at 3:54 PM, Sergey Ponomarev wrote: > > The Implicit grant flow was intended for authorising clients which > can't store the `client_secret` like SPA. It is orthogonal to that, you can do code flow without client secrets as well. OAuth was released at

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

> On Dec 17, 2021, at 2:44 PM, Brian Campbell > wrote: > > Relax how aggressively OAuth demands that the AS automatically redirect in > error conditions. And either respond with a 400 directly (which just stops > things at that point) or provide a meaningful interstitial page to the user

Re: [OAUTH-WG] can a resource server provide indications about expected access tokens?

> On Dec 11, 2021, at 3:35 AM, Nikos Fotiou wrote: > > Hi, > > I have a use case where a resource server is protected and can only be > accessed if a JWT is presented. Is there any way for the server to "indicate" > the "expected" format of the JWT. For example, respond to unauthorized >

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

> On Dec 9, 2021, at 2:35 PM, Neil Madden wrote: > > On 9 Dec 2021, at 20:36, Justin Richer > wrote: >> >> I disagree with this take. If there are confirmation methods at all, it’s no >> longer a Bearer token, and pretending that it is doesn’t help anyone. I >>

Re: [OAUTH-WG] JWK Thumbprint URI Specification

I would investigate whether there are advantages of having this be a URN vs a URI in a new base scheme (e.g. jkt:bTz_1…). I haven’t seen much URN namespacing of dynamic values (e.g. values not being maintained by the entity responsible for the namespace or sub-spaces), and a new scheme is a

Re: [OAUTH-WG] [EXTERNAL] Rotating RTs and grace periods

My perspective is that the rotation of refresh tokens is an AS mechanism to push for one-time-usage and break idempotency. This is specifically employed to reduce the impact in scenarios where the refresh token can be leaked and used by a third party attacker. A leaked refresh token can only be

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

> On Oct 15, 2021, at 7:23 PM, Ash Narayanan wrote: > ... > >> As I see it, the retry in case of network failures should happen by >> performing a new authorization request – not by trying to reuse an >> authorization code – which is indistinguishable from an attack. > This offers no

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

> focused effort. > > Mike [Jones]: The usage of TLS for sender constraint is not deployable > > OAuth WG Interim Meeting – 2021-03-15 > <https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-01-202103151200/>: > Francis [Pouatcha]: DPoP should be by no way a repla

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

> On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle > wrote: > > Those issues that could be addressed without completely redesigning DPoP have > been discussed within the Working Group multiple times. (See quotes and > meeting notes references in my previous message) The authors

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

I agree that PKCE (with a non-plain operational mode) protects the code from attacker use by the security BCP model (but not necessarily stronger models) Would the prevalence for ASs which cannot enforce an atomic code grant warrant further language against plain PKCE? -DW > On Oct 13, 2021,

Re: [OAUTH-WG] convert to credentialed client... ( was OAuth2.1 credentialed client )

> On Oct 11, 2021, at 11:52 AM, Dick Hardt wrote: > >  > Thanks for the feedback Brian. We have struggled in how to concisely describe > credentialed clients. > > "identifying a client" can be interpreted a number of ways. > > The intent is that the AS knows a credentialed client is the

Re: [OAUTH-WG] DPoP, how will it be implemented in a browser?

Public clients can create their own ephemeral key (say, non-exportable keys made with WebCrypto) to have bound to the access and refresh tokens at issuance time. DPoP is independent of the client authentication to the AS. -DW > On Oct 11, 2021, at 11:40 AM, Nikos Fotiou wrote: > > Hi, > How

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

I do not support adopting this work as proposed, with the caveat that I am a co-editor of the DPoP work. We unfortunately do not have a single approach for PoP which works for all scenarios and deployments, why we have had several proposals and standards such as Token Binding, mutual TLS, and

Re: [OAUTH-WG] self-issued access tokens

> On Oct 1, 2021, at 11:06 AM, Dick Hardt wrote: > If there is really only one service, then there is little value in an AS. I > would have the client post a JWT that has the request payload in it, or a > detached signature if it is a large payload. Personally, I like sending the > request

Re: [OAUTH-WG] self-issued access tokens

Are you using DPoP at issuance of the credential and embedding the public key as the means to verify the subject? Are you going so far as using DPoP in lieu of Verifiable Presentation wrappers? -DW > On Sep 30, 2021, at 12:47 AM, Nikos Fotiou wrote: > > FYI, this is exactly what we are doing

Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application

> On Mar 14, 2021, at 8:36 PM, Tatsuya Karino wrote: > > On Safari, you have no workaround. > 3rd-party cookie is dead, and all JS-writable data is removed in 7 days there. > > As you stated, option 1 does not work in cross-site scenarios in Safari & > Brave at the moment. Other browsers are

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

> On Feb 26, 2021, at 9:32 AM, Aaron Parecki wrote: > The point is that basically nobody uses it because they don't want to allow > arbitrary client registration at their ASs. That's likely due to a > combination of pre-registration being the default model in OAuth for so long > (the

Re: [OAUTH-WG] Implementation questions around refresh token rotation

An AS may decide refresh token rotation is useful for other reasons (such as if the token is an encrypted value and the AS cluster does key rotation), or may decide to rotate all tokens for consistency. Eventually best practices may indicate sender constrained tokens for public clients. At

Re: [OAUTH-WG] Implementation questions around refresh token rotation

On Oct 6, 2020, at 16:05, Aaron Parecki wrote: > However that also kind of defeats the purpose since attacks within that grace > period would be hard to detect. I'm looking for an idea of where people have > landed on that issue in practice. This is effectively a race condition, and a grace

Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session

ssion) -DW > On Apr 30, 2020, at 20:29, Mike Jones > wrote: > > Daniel Fett and David Waite (DW) hosted a great session on OAuth 2.0 > Demonstration of Proof-of-Possession at the Application Layer (DPoP) > <https://tools.ietf.org/html/draft-ietf-oauth-dpop-00> at

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

There are a number of ambiguities and statements around using JWTs in various contexts: 1. Some implementations interpret “iat" to also have the meaning of “nbf” in the absence of “nbf”, although this is AFAIK not prescribed by any spec 2. The DPoP draft’s client-generated tokens have the

Re: [OAUTH-WG] OAuth Security BCP -15

On Apr 5, 2020, at 12:42 PM, Aaron Parecki wrote: > Aside from that, I'm struggling to understand what this section is actually > saying to do. Since this is in the "Authorization Code Grant" section, is > this saying that using response_type=code is fine as long as the client > checks the

Re: [OAUTH-WG] Full Third-Party Cookie Blocking

More specifically, SSO will not work anymore without either: - prompting the user (via Storage Access API) - using explicit front-channel mechanisms (popups and redirects) - using back-channel mechanisms (refresh tokens and some backchannel logout infrastructure) (FWIW, I proposed a back-channel

Re: [OAUTH-WG] Corona Virus and Vancouver

I will be there in person. > On Mar 9, 2020, at 12:33 PM, Daniel Fett wrote: > > Hi all, > > can we do a quick roll call on who is coming or not coming to Vancouver? > > For me, at the current point in time, it depends on whether a significant > portion of the working group is attending

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

token. -DW > > Regards, > Andrii > > On Sun, Mar 1, 2020 at 7:38 PM David Waite > wrote: >> >> I would expect the AS to invalidate the refresh token in this case, which >> would not require a refresh token mode nor necessarily any signaling back to >> the re

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

I would expect the AS to invalidate the refresh token in this case, which would not require a refresh token mode nor necessarily any signaling back to the resource. -DW > On Mar 1, 2020, at 12:12 AM, Andrii Deinega wrote: > > Hello Bill, > > I'm just thinking out loud about possible

Re: [OAUTH-WG] PKCE and refresh tokens

> On Feb 28, 2020, at 8:46 AM, Albin Nilsson wrote: > > Hello, > > I'm having some trouble with oauth and the Authorization Code flow and PKCE. > How can I get a refresh token? The refresh token flow requires a > client_secret, but PKCE prohibits client_secret. Is refresh token a no go?

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

I support the adoption of PAR > On Dec 17, 2019, at 5:59 AM, Rifaat Shekh-Yusef wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >

Re: [OAUTH-WG] Meeting Minutes

+1 to adopting PAR. For RAR I have a number of questions myself with the approach and with some of the ramifications. I’m most concerned with the coupling of business-specific presentation, process validation and workflow within the AS, but also with the mixing of single transactional approval

Re: [OAUTH-WG] DPoP symmetric key idea

There seems two prevailing approaches: 1. The AS generates a symmetric key and encrypts it to a specific audience as part of/associated with the access token (KDC-type model). 2. The client attempts asymmetric use, and the resource server negotiates a symmetric key specific to it. The first

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On Nov 15, 2019, at 8:32 AM, Paul Querna wrote: > Supporting `HS256` or similar signing of the proof would be one way to > reduce the CPU usage concerns. There are a number of other potential asymmetrically signed messages, such as the access token. Is the assumption that these are also

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

On Nov 10, 2019, at 2:02 PM, Lee McGovern wrote: > > > 3.1 - "Clients MUST memorize which authorization server they sent an > authorization request to" - is memorize the best synonym here, perhaps store > or retain is more aligned with computational language? Store, retain, persist are all

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

On Nov 9, 2019, at 1:08 PM, Torsten Lodderstedt wrote: > But what does „same client“ mean? Is it the client_id? Sounds reasonable for > a web app, but would also mean instances of the same native app residing on > different devices could share the consent. That’s great from a convenience >

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

Hello Daniel! > 1. The client makes an ajax HEAD request to the OAuth authorization > endpoint, which will silently create the authorization grant (this was > the security exploit that was patched). > Anyway, I'm trying to find guidance on transparent redirects for > authorization code grants.

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> On Jul 24, 2019, at 3:03 PM, Aaron Parecki wrote: > > On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier > wrote: > >> I would rather say that ANY JS app should use CSP to lock down the browser >> features to a minimal attack surface. In addition, if refresh or access >> tokens are

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> On Jul 23, 2019, at 12:47 PM, Brian Campbell > wrote: > > > > On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt > wrote: > > 2) Regarding architectures: I think this BCP should focus on recommendations > for securely implementing OAuth in the different

Re: [OAUTH-WG] Refresh tokens

> On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: > > Access tokens and refresh tokens, stored browser-side, are equally vulnerable > to theft, because the storage options are identical. > > We are more concerned about the theft of the refresh token, because it > (commonly) has a longer

Re: [OAUTH-WG] Refresh tokens

can logout to lockout the >> attacker. However, that is a lot of "ifs" and still provides the attacker >> with time to leverage access via the compromised refresh_token. >> >> In principle, I agree with the recommendation that SPAs shouldn't have >> refresh_tokens

Re: [OAUTH-WG] Refresh tokens

> On Jul 8, 2019, at 8:39 PM, Aaron Parecki wrote: > > These are all very good points! I think the challenge here is figuring out > where this kind of guidance is most appropriate. > > It does seem like some of these issues are unique to a browser environment > (particularly where the

Re: [OAUTH-WG] Refresh tokens

> On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: > Re 8. Refresh Tokens > >"For public clients, the risk of a leaked refresh token is much >greater than leaked access tokens, since an attacker can potentially >continue using the stolen refresh token to obtain new access without >

Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices

> On Jul 3, 2019, at 1:44 AM, da...@davidsautter.de wrote: > I understood, that you could also secure this variant of the Authorization > Code Flow with PKCE in order to protect the redirect steps. I noticed, that > this is rarely discussed "in public" (e.g. blogs, Stackoverflow etc)

Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices

On Jun 10, 2019, at 2:06 AM, David Sautter wrote: > I understood the following: Using a backend service for doing the exchange of > the auth code for the token with the IdP is considered more secure, because > one cannot trust the browser to store the tokens securely. The drawback is > that

Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps

> On May 8, 2019, at 1:37 AM, Emond Papegaaij wrote: > > On maandag 6 mei 2019 22:42:09 CEST David Waite wrote: >> On May 6, 2019, at 1:42 PM, Emond Papegaaij > >> You could also trigger re-authorization with a user click, thus allowing >> opening the AS in

Re: [OAUTH-WG] MTLS and Native apps Best practices

> On May 7, 2019, at 8:02 AM, John Bradley wrote: > > I believe that for a native app to use mtls via a chrome custom tab or Safari > view controller you need to provision a certificate and private key to the > system keystore. It is not something that can happen dynamically from the >

Re: [OAUTH-WG] MTLS vs. DPOP

> On May 7, 2019, at 8:12 AM, George Fletcher > wrote: > > To compromise an MTLS bound token the attacker has to compromise the private > key. To compromise a DPOP bound token, depending on what HTTP request > elements are signed, and whether the DPOP is managed as one-time-use etc, >

Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps

On May 6, 2019, at 1:42 PM, Emond Papegaaij wrote: > > Hi all, > > For a browser-based app, we try to follow the recommendations set in draft- > ietf-oauth-browser-based-apps-01. This does allow us to create a secure OAuth > 2.0 browser-based application, but at the moment it comes at a cost

Re: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback

> On May 2, 2019, at 12:32 AM, Paul Querna wrote: > Jumping into specific items: > > cnf in DPoP-Proof >> o "cnf": Confirmation claim as per [RFC7800] containing a member >> "dpop+jwk", representing the public key chosen by the client in >> JWK format (REQUIRED for DPoP Binding JWTs,

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

My understanding: The proof-of-possession needs to have a limited destination to prevent replay against other resources. Similar to resource indicators and to distributed OAuth, the client is expected to use a resource URL view of the world rather than an access-token-specific audience or

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

Multiple concepts often get tacked onto a particular term, which both aids and hinders communication. From RFC 6749, a public client is defined as: "Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Do we know if there is a justifying use case for auth_time, acr, and amr to be available in OAuth JWT access tokens? These are meant to be messages about the client, either directly (in the case of client credentials) or about its delegated authorization of the user. Embedding attributes about

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

> On Feb 25, 2019, at 4:56 AM, Vittorio Bertocci wrote: > > The callbacks do avoid the loopback, which is great, but the usability > remains harder than mobile and the embedded case: the auth tab appears among > others, the modal windows remain a possibility, etc - the level of >

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

> On Feb 24, 2019, at 10:43 AM, William Denniss > wrote: > > For 1P sign-in, there are several good reasons to go with > ASWebAuthenticationSession, like syncing the signed-in session with Safari > and using it if it already exists. With enterprise 3P, you’ll have to use some web agent for

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

Offhand, Google Apps on iOS. Also the Facebook SDK uses a similar pattern. I believe third party apps which use Google for SSO are mandated to use it as well. Slack and Pokémon Go, for examples. A few apps will also use it or a similar pattern (for SAML) once they have determined it is an

Re: [OAUTH-WG] Correct error code for rate limiting?

I don’t believe that any of the currently registered error codes are appropriate for indicating that the password request is invalid, let alone a more specific behavior like rate limiting. It is also my opinion that 400 Bad Request shouldn’t be used for known transient errors, but rather for

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

My understanding is that a permanent redirect would be telling the client (and any other clients getting cached results from an intermediary) to now stop using the original endpoint in perpetuity for all cases. I don’t think that is appropriate (in the general case) for an endpoint with request

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

> On Jan 11, 2019, at 3:32 AM, Neil Madden wrote: > > On 9 Jan 2019, at 05:54, David Waite wrote: >> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>> wrote: >>> >> >> >>> All of that is meant as an explanation of sort

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

> On Dec 28, 2018, at 3:55 PM, Brian Campbell > wrote: > > All of that is meant as an explanation of sorts to say that I think that > things are actually okay enough as is and that I'd like to retract the > proposal I'd previously made about the MTLS draft introducing a new AS > metadata

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

> On Dec 28, 2018, at 3:55 PM, Brian Campbell > wrote: > > I spent some time this holiday season futzing around with a few different > browsers to see what kind of UI, if any, they present to the user when seeing > different variations of the server requesting a client certificate during

Re: [OAUTH-WG] expires_in

My understanding was that this parameter was advisory to the client - it neither mandated the client discard the token after the expires_in time, nor has a requirement that the token is no longer honored by protected resouces at that point in time (vs earlier or later). Is there meaning that

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

> On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci > wrote: > > > Can you give a concrete example? To me it feels like you are explaining > > scenarios where OAuth is used for login. > > That's one of the scenarios of interest here. We can debate on whether that's > proper or not, but the

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

> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> > >> On Dec 6, 2018, at 12:24 PM, David Waite > <mailto:da...@alkaline-solutions.com>> wrote: >> >> One benefit of moving to code flow is that the r

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

One benefit of moving to code flow is that the refresh token can be used to check the validity of the user session (or rather, it allows the AS another avenue to force authentication events if the AS considers the user session to be expired (or has a drop in confidence). There are indeed

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

> On Dec 5, 2018, at 5:16 AM, Torsten Lodderstedt > wrote: > > Hi Tomek, > >> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki : >> >> Thanks Torsten! >> So if I am putting myself in the shoes of somebody who sets out to do that - >> switch an existing SPA client (no backend) > > I would

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

> On Dec 3, 2018, at 1:25 AM, Torsten Lodderstedt > wrote: > > I think the BCP needs to point out there are solutions beyond an app directly > interacting with AS and RSs from the browser. Otherwise people get the wrong > impression this is the only way to go. To the contrary and as I

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

Agreed, if the BCP is meant to describe javascript behavior for best practices as respect to being an OAuth client, I’m unsure what would belong in this document for javascript which is instead interacting over non-standard mechanisms with an OAuth client. Instead, it would be generalized

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

> On Nov 21, 2018, at 12:08 AM, Hans Zandbelt > wrote: > > I think of this as somewhat similar to: > a) a grant type where a cookie grant is exchanged at an "RP token endpoint" > for an associated access and refresh token; the protocol between SPA and the > API to do so would benefit from

  1   2   >