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

Phishing filters can simply handle all OAuth AuthZ request like URLs in emails malicious. > 2021/12/18 6:45、Brian Campbell > のメール: > >  > Yeah, I think it has been discussed before. And if I'm understanding > correctly, it is unfortunately a tricky area. It sounds like more or less the >

Re: [OAUTH-WG] Questions about error cases on RFC 7523

Sorry, please ignore 2nd question. WWW-Authenticate header isn’t needed in this case. > 2021/07/29 10:08、nov matake のメール: > > Hi, > > I have 2 questions about RFC 7523’s error cases. > > 1st one is about section 3.2, which requires “invalid_client” error when > client

[OAUTH-WG] Questions about error cases on RFC 7523

Hi, I have 2 questions about RFC 7523’s error cases. 1st one is about section 3.2, which requires “invalid_client” error when client assertion JWT is invalid. In such case, what scheme is expected for WWW-Authentication header? I believe it’s not Basic, but not sure what is appropriate.

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

> deleted on 7days in safari. > > Is there any workaround? or Is there any misunderstanding on my concerns? > > > 2021年3月13日(土) 13:05 Nov Matake : >> Your mechanism seems work fine. >> >> However, do you need OAuth in such situation? >> Same-sit

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

Your mechanism seems work fine. However, do you need OAuth in such situation? Same-site cookie seems much simpler there. iPadから送信 > 2021/03/13 0:45、Tatsuya Karino のメール: > >  > Hi all, > > I'm looking for the specification to generate a new Access Token with > authentication session in a

Re: [OAUTH-WG] Authorization handover from mobile app to website

You can make your app an OIDC self-issued IdP for your website. One of my clients are using the mechanism for Native App SSO, where an OIDC self-issued IdP embedded in the Native App is acting as IdP for the backend IdP server. Unfortunately I have no english document now, but this slide

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

client: DPoP? > > access_token : > -> presenter : Client > -> consumer : RS > -> sender PoP : >--> confidential client: private_key_jwt, mTLS >--> public client: DPoP? > > Is this correct? > > On Sun, Jun 7, 2020 at 8:42 AM Nov M

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

ot;PKCE + DPoP". * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only. * sender-constrained code, bearer access token and bearer refresh token, use PKCE only. * bearer code, bearer access token and bearer refresh token, use none of them. >

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

Yeah, both PKCE and Client Credential provide sender-constrained code... lots of choices Sent from my iPhone > On Jun 7, 2020, at 21:26, Neil Madden wrote: > >  > Answers inline: > >>> On 7 Jun 2020, at 13:07, Nov Matake wrote: >>> >> So, you mean…

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

clients. > > Besides, this ship already sailed with mTLS cert-bound refresh tokens. > > Neil > >> On 7 Jun 2020, at 12:34, Nov Matake wrote: >> >> Confidential clients can also use DPoP. >> >>> 2020/06/07 20:25、Torsten Lodderstedt >> &

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

> Am 07.06.2020 um 13:04 schrieb Nov Matake : >> >> Since each client instance has at least one key, those are same level of >> state management. >> >>> 2020/06/07 16:24、Torsten Lodderstedt >> <mailto:tors...@lodderstedt.net>>のメール: >>

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

e management in > particular. > >> Am 07.06.2020 um 05:41 schrieb Nov Matake : >> >> DPoP-bound refresh token seems feature duplication with dynamic client >> registration. >> >>> 2020/06/07 7:57、Francis Pouatcha >> <mailto:fpo=40adors

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

DPoP-bound refresh token seems feature duplication with dynamic client registration. > 2020/06/07 7:57、Francis Pouatcha のメール: > > > > Am 05.06.2020 um 22:17 schrieb George Fletcher > > http://ietf.org/>>: > > > > Secondly, I do think we need a way to allow for the refresh_token to be > >

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

om: OAuth mailto:oauth-boun...@ietf.org>> On > Behalf Of Nov Matake > Sent: Monday, May 18, 2020 11:50 PM > To: Daniel Fett mailto:f...@danielfett.de>> > Cc: oauth@ietf.org <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAu

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

I'm guessing such behavior is relatively rare-case, hopefully. iPadから送信 > 2020/05/19 15:43、Daniel Fett のメール: >  > Hi, > > Am 19.05.20 um 04:55 schrieb Nov Matake: >> I thought the server MUST reject such token requests, but I couldn’t find >> such definition in RFC

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

f >> 2.1 with that language intact, as I believe it represents at least a local >> point of hard-won consensus. Let's get that language into the record of >> drafts. >> >> There's always time to debate it and change it later in subsequent drafts, >> but let's not now lo

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

at should just be a new spec. > > Aaron Parecki > > >> On Thu, May 14, 2020 at 3:18 AM Nov Matake wrote: >> There is no specific mechanism right now. >> But future developers won’t be able to read the reason why the extension >> point is given only for confi

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

ince from my perspective > this clause is mainly intended to allow existing OpenID Connect deployments > to use nonce instead of PKCE in combination with OAuth 2.1. It’s a > compromise. I think we should not encourage others to invent their own OAuth > security mechanisms. > >&g

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Hi, Why not allowing public clients use "other suitable mechanisms” then? OAuth WG can allow both type of clients do so, then OIDF will define nonce as the alternative only for confidential clients. > 2020/05/14 15:56、Torsten Lodderstedt > のメール: > > Hi all, > > I would also like to thank

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

of the issuer or be globally unique. >>>>The processing of this claim is generally application specific" >>>> >>>> which kind of spells "client" in case of the client credentials grant but >>>> I also do worry about Resource Servers thin

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

Hi Vittorio, Thanks for the good starting point of standardizing JWT-ized AT. One feedback. The “sub” claim can include 2 types of identifier, end-user and client, in this spec. It requires those 2 types of identifiers to be unique each other in the IdP context. I prefer omitting “sub” claim

Re: [OAUTH-WG] OTP-flow use case (sharing energy data)

send a > user_code to the user that the user can give to the client for > authorization. Hopefully, this can shift most of the complex UI/UX > development cost away from the utility and onto the third party clients. > >> > >> Unfortunately, the energy industry can be quite behind on the latest > and greatest OAuth developments, but we're trying to get better :) > >> > >> Thanks very much, > >> Daniel Roesler > >> dan...@utilityapi.com > >> > >> ___ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- nov matake ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

Hi Torsten, > On Dec 8, 2018, at 22:20, Torsten Lodderstedt wrote: > > Hi Nov, > >> Am 08.12.2018 um 00:20 schrieb Nov Matake : >> >> For me, it seems very hard to issue TB-bound token for JS app and >> MTLS-bound token for its backend server at same

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

Hi Vittorio, > did all the vendors on the list work on proof of concepts to ensure that the practices recommended here can work with your product, end to end? I’m not currently working on SPA apps nor apps using implicit flow. However, my previous client is using hybrid flow to fetch access

Re: [OAUTH-WG] Recommendations for browser-based apps

you have redirect uri restriction there. nov > On Sep 20, 2017, at 9:44, Bill Burke <bbu...@redhat.com> wrote: > > Cookies are vulnerable to CXRF. > >> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <mat...@gmail.com> wrote: >> Why not using http-on

Re: [OAUTH-WG] Recommendations for browser-based apps

Why not using http-only cookies instead of refresh tokens? If the app can interact with AuthZ server through a hidden iframe with prompt=none param, you shouldn’t need refresh tokens. If your SAP is running on a different domain with the backend server, Safari’s Intelligent Tracking Prevention

Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS

>> HTTPS >> >> >> >> >> http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/ >> >> >> >> Access tokens included as a URL query parameter when accessing a resource >> are susceptible to this attack. >> >> >> >> Authorization codes are also visible. From what I know, we have not >> depended on the confidentiality of the authorization code. >> >> >> >> What are the best current practices that we can point people towards to >> ensure they are not susceptible to this attack? >> >> >> >> -- Dick >> >> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn >> about projects I am working on! >> >> >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- nov matake ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [scim] Simple Federation Deployment

I'm interested in too. nov > On Apr 7, 2016, at 07:14, Mike Jones wrote: > > For the record, I’m interested. > > From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick > Sent: Tuesday, April 5, 2016 7:26 PM > To: Phil Hunt (IDM)

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

It sounds like we want to return a list of available access tokens “aud” values from AS config discovery endpoint (and also via oauth-meta too?), doesn’t it? and RS config discovery endpoint will return acceptable access token “iss” values, a list of every RS endpoints, required scopes per

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

o tls). > > Phil > > On Jan 25, 2016, at 19:29, Phil Hunt (IDM) <phil.h...@oracle.com > <mailto:phil.h...@oracle.com>> wrote: > >> When the RP acting as the client issues a authorize redirect to the UA it >> has to make it with TLS >> >

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

>sign-in service). > > Section 10.5 talks about transmission of authorization codes in connection > with redirects. > > Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes. > > > Phil > > @independentid > www.independentid.com > p

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

The first assumption is coming from the original security report at http://arxiv.org/abs/1601.01229 . RFC 6749 requires TLS between RS and AS, and also between UA and AS, but not between UA and RS. The blog post is based on my Japanese post, and it describes

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Hum, even if the client uses different redirect_uri per each IdP, code phishing attack succeeds in Nat’s sample attack scenario. In such scenario, returning AuthZ endpoint URI as AuthZ response also won’t help. So it seems returning “iss" (with discovery support) or oauth-meta is MUST for such

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

think there should be one solution approach that we > work on for this, not two. > > Best wishes, > -- Mike >   <> > From: nov matake [mailto:mat...@gmail.com <mailto:mat...@gmail.com>] > Sent: Monday, Jan

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

If the OAuth server supports discovery, “iss” can be used. If not, attacker’s OAuth server can describe honest OAuth server’s “iss” in its developer document. So returning “iss” would require discovery support NOW, not in the future. > On Jan 22, 2016, at 10:04, Mike Jones

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

I prefer “code_challenge_methods_supported”, since the registered parameter name is “code_challenge_method”, not “pkce_method". > On Jan 19, 2016, at 11:58, William Denniss wrote: > > Seems like we agree this should be added. How should it look? > > Two ideas: > >

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Hi Mike, Isn’t Nat’s "OAuth Response Metadata” spec enough to solve those issues? https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt > On Jan 12, 2016, at 05:40, Mike Jones wrote: > > The

Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us

Hi Mike, I’m planning to use Token Exchange spec for a use-case described bewlow. 1. a native app obtains an access_token & an id_token from an IdP 2. the native app passes the id_token to its own backend component 3. the backend component obtains an access token from the IdP using the id_token

[OAUTH-WG] allowing offline access for native app & its backend server

Hi OAuthers, I’m thinking the way to issue refresh tokens both to native app and its backend server at same time. I have 2 ideas currently. 1. including 2 audience in a single authorization code, and allow using the code once per the audience. 2. issuing 2 code one for native app, one for

Re: [OAUTH-WG] allowing offline access for native app & its backend server

that for a refresh token. > > I can see giving out two codes and we have discussed that in the past. > > This topic should perhaps be added to the list of things for rechartering. > There are a lot of interactions and posable security side effects that need > to be looked

Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

+1 On 2013/05/21, at 5:23, Edmund Jay e...@mgi1.com wrote: +1 for keeping names as is. From: Justin Richer jric...@mitre.org To: oauth@ietf.org oauth@ietf.org Sent: Mon, May 20, 2013 8:10:13 AM Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Phil Hunt's review of

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt

otherwise. :) Can you suggest how to make this clearer for developers in the text? -- Justin On 03/29/2013 11:57 PM, nov matake wrote: oops sorry, not draft07, but draft06. On 2013/03/30, at 12:55, nov matake mat...@gmail.com wrote: Hi Justin, I read the latest draft and found endpoints

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt

, at 2:23, nov matake mat...@gmail.com wrote: Thanks for your clarification. After reading the editor's note in draft06, I felt 401 is more natural than 403. (assuming you don't want to use 404 for security reason) The editor's note is enough detail for the reason of using 401. Using 403

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt

Hi Justin, I read the latest draft and found endpoints described in the spec returns 403 in no such clients case. I also read the draft07's editor note below, so I can understand the situation. [[ Editor's note: If the client doesn't exist, then the Refresh Access Token shouldn't be valid,

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-09.txt

oops sorry, not draft07, but draft06. On 2013/03/30, at 12:55, nov matake mat...@gmail.com wrote: Hi Justin, I read the latest draft and found endpoints described in the spec returns 403 in no such clients case. I also read the draft07's editor note below, so I can understand

Re: [OAUTH-WG] OAuth Feature Matrix

Hi Mike, This is my OpenID Connect OP's case. https://docs.google.com/spreadsheet/ccc?key=0Alz2DOj-3mbldGc1bDVCN3lwZnBqSUFFVGp4dWVnaWcusp=sharing Cheers, nov On 2013/03/13, at 0:28, Nat Sakimura sakim...@gmail.com wrote: I have asked several Japanese developers to fill the form. Nat

[OAUTH-WG] Question on diff between draft31 and RFC6749

Hi all, I couldn't understand why their became the third party's in the diff between draft31 and RFC6749 below. === Resource owners cannot revoke access to an individual third-party third party without revoking access to all third-parties, third parties, and must do so by changing their the

Re: [OAUTH-WG] Question on diff between draft31 and RFC6749

. -- Justin On 01/07/2013 06:53 AM, nov matake wrote: Hi all, I couldn't understand why their became the third party's in the diff between draft31 and RFC6749 below. === Resource owners cannot revoke access to an individual third-party third party without revoking access to all

Re: [OAUTH-WG] Report an authentication issue

Subject: Re: [OAUTH-WG] Report an authentication issue This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it access_token phishing attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake has

[OAUTH-WG] Clarification of client application consisting of multiple components

Hi, I just found this sentence in the latest draft. Does it mean an application consisting of server-side and client-side component (eg. foursquare iPhone app) MUST have separate client_id for each component ? Or can I image something like Facebook is doing right now? (register each component

Re: [OAUTH-WG] Clarification of client application consisting of multiple components

...@ietf.org] On Behalf Of nov matake Sent: Sunday, March 11, 2012 8:25 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Clarification of client application consisting of multiple components Hi, I just found this sentence in the latest draft. Does it mean an application consisting of server-side

Re: [OAUTH-WG] Clarification of client application consisting of multiple components

available in the future, and how it will apply the security policies. IOW, those proposing such an extension in the future will have to figure out how this should be handled. EH -Original Message- From: nov matake [mailto:n...@matake.jp] Sent: Sunday, March 11, 2012 10:21 AM To: Eran

[OAUTH-WG] Quick question about error response for response_type=unknown

Hi OAuthers, My apologies if you already discussed this. When OAuth server received unknown response_type, how should the server handle the error? 1. Show the error to the user without redirecting back to the client 2. Redirect back to the client including the error in query 3. Redirect back

[OAUTH-WG] small typo in core draft 22

If it's already reported, my apologies. In section 8.4, If a response type contains one of more space characters. It should be one or more. Thanks -- nov matake ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh Token and Expires_in

Yeah, your way is much better, especially for client developers. All mixi access_tokens expire in 15 mins, I'm not sure the details of their security policy though. And there are no way to know the lifetime of refresh_token when client get an access_token. On 2011/02/04, at 9:45, Eran