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 specification describes this validati

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

The specification describes this validation method (comparison of the issuer received to the issuer recorded at registration time) in step 2 of Section 4 (Validating the Response). In fact, I added this in response to your feedback on an earlier draft, Hans. -Original Message- From: Ha

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

I disagree that validating endpoints "at this step" (which refers to right before making the token request) should be the default way of handling this. The vast majority of OAuth client deployments connecting to more than one AS will have a static configuration of the ASes issuer/endpoint infor

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

Correct From: George Fletcher [mailto:gffle...@aol.com] Sent: Monday, January 11, 2016 12:13 PM To: Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation So just to make sure I understand... This specification requires the response from the Authorization Server to an s

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

So just to make sure I understand... This specification requires the response from the Authorization Server to an successful /authorize call to pass back code=, state= and jwt= (?) or individually iss= and aud= as URL parameters on the 302 to the redirect_url. This way, before the client issue

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

The alternatives for the code flow are to return them either in a new JWT added to the reply containing them in the "iss" and "aud" claims or to return them in new individual "client_id" and "iss" authorization response parameters. Both alternatives are described in the draft. I'm sure that we

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

Thanks Mike. One question after reading about the different attack vectors and this spec... How are the 'iss' and 'aud' values returned with the 'code' and 'state' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the c

[OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany

In context of the recent findings from researchers related to OAuth and OpenID Connect, see announcement at http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html, we are convinced that the wider Internet security community can help to improve the security of Internet protocols. In an at

[OAUTH-WG] Cross-Area Review Request for RDAP Authentication

I'd like to ask folks who are more familiar with OAuth than I am to please review an I-D I've written that describes an approach to using OpenID Connect with the Registration Data Access Protocol (RDAP, a product of the WEIRDS WG). Those of you who are familiar with WHOIS will understand the mot

[OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up. This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attack