Re: [OAUTH-WG] Does Facebook login OAuth 2.0 compatible ?

[Antonio Sanso]

Hi Prabath,

As long as I know Facebook implement OAuth 2.0 draft 10 (so a pretty old 
version of the spec).
The RFC was based on draft 31.

Regards

Antonio


On Feb 5, 2013, at 5:54 PM, Prabath Siriwardena wrote:

Here are some references that I found they do not.. thoughts appreciated...

1. https://developers.facebook.com/docs/howtos/login/login-as-app/
2. https://developers.facebook.com/docs/howtos/login/extending-tokens/
3. https://developers.facebook.com/docs/howtos/login/login-as-page/

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.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

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Antonio Sanso]

Hi Hannes,

how this session key "differs" from the key described in the current draft [0]?

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:

> Hi Bill, 
> 
> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
> 
>> Is key distribution how AS and PR share keys  for token 
>> encryption/decryption or specifically about the keys for the HOK tokens?
>> 
> In order for the client to compute the keyed message digest it needs to have 
> the session key. This session key is sent from the authorization server to 
> the client and everyone on the call agreed that this has to be standardized. 
> 
> The resource server who receives the message from the client also needs to 
> have the session key to verify the message. How the resource server obtains 
> this session key was subject for some discussion on the call. I presented 
> three different ways of how the resource server is able to obtain that key. 
> We have to decide on one mandatory-to-implement mechanism. The open issue is 
> which one? 
> 
>> For the MAC token spec, I don't actually care whether we use JSON or now, 
>> but I'm in full agreement that we do NOT duplicate any HTTP info into the 
>> JSON.  Just signatures of that stuff.
>> 
> I believe the folks on the call also agreed with you on that aspect that the 
> content of the HTTP message should not be replicated in the JSON payload 
> itself. 
> 
> Ciao
> Hannes
> 
>> From: Hannes Tschofenig 
>> To: IETF oauth WG  
>> Sent: Tuesday, February 12, 2013 1:10 AM
>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
>> 11th February 2013
>> 
>> Here are my notes. 
>> 
>> Participants:
>> 
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>> 
>> Notes: 
>> 
>> My slides are available here: 
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>> 
>> Slide #2 summarizes earlier discussions during the conference calls. 
>> 
>> -- HTTP vs. JSON
>> 
>> Phil noted that he does not like to use the MAC Token draft as a starting 
>> point because it does not re-use any of the work done in the JOSE working 
>> group and in particular all the libraries that are available today. He 
>> mentioned that earlier attempts to write the MAC Token code lead to problems 
>> for implementers. 
>> 
>> Justin responded that he does not agree with using JSON as a transport 
>> mechanism since this would replicate a SOAP style. 
>> 
>> Phil noted that he wants to send JSON but the signature shall be computed 
>> over the HTTP header field. 
>> 
>> -- Flexibility for the keyed message digest computation
>> 
>> From earlier discussion it was clear that the conference call participants 
>> wanted more flexibility regarding the keyed message digest computation. For 
>> this purpose Hannes presented the DKIM based approach, which allows 
>> selective header fields to be included in the digest. This is shown in slide 
>> #4. 
>> 
>> After some discussion the conference call participants thought that this 
>> would meet their needs. Further investigations would still be useful to 
>> determine the degree of failed HMAC calculations due to HTTP proxies 
>> modifying the content. 
>> 
>> -- Key Distribution
>> 
>> Hannes presented the open issue regarding the choice of key distribution. 
>> Slides #6-#8 present three techniques and Hannes asked for feedback 
>> regarding the preferred style. Justin and others didn't see the need to 
>> decide on one mechanism - they wanted to keep the choice open. Derek 
>> indicated that this will not be an acceptable approach. Since the resource 
>> server and the authorization server may, in the OAuth 2.0 framework, be 
>> entities produced by different vendors there is an interoperability need. 
>> Justin responded that he disagrees and that the resource server needs to 
>> understand the access token and referred to the recent draft submission for 
>> the token introspection endpoint. Derek indicated that the resource server 
>> has to understand the content of the access token and the token 
>> introspection endpoint just pushes the problem around: the resource server 
>> has to send the access token to the authorization server and then the 
>> resource server gets the result back (which he the
 n
>  a
>> gain needs to underst

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Antonio Sanso]

Thanks Hannes

On Feb 12, 2013, at 12:06 PM, Hannes Tschofenig wrote:

> The transport of the session key from the authorization server is described 
> in Section 5.1 and is called "mac_key". 
> 
> The mechanism to transport the session key from the authorization server to 
> the resource server is not yet described in the document. This has historical 
> reasons: OAuth 1.0 did not separate the authorization server from the 
> resource server in the way OAuth 2.0 does.

but why do not we hit this same issue in the JWS case? In this situation there 
is as well a key for sign... And AS and RS can be as well two different 
entities...

Regards

Antonio



> 
> Ciao
> Hannes
> 
> On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:
> 
>> Hi Hannes,
>> 
>> how this session key "differs" from the key described in the current draft 
>> [0]?
>> 
>> Thanks and regards
>> 
>> Antonio
>> 
>> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>> 
>> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
>> 
>>> Hi Bill, 
>>> 
>>> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>>> 
>>>> Is key distribution how AS and PR share keys  for token 
>>>> encryption/decryption or specifically about the keys for the HOK tokens?
>>>> 
>>> In order for the client to compute the keyed message digest it needs to 
>>> have the session key. This session key is sent from the authorization 
>>> server to the client and everyone on the call agreed that this has to be 
>>> standardized. 
>>> 
>>> The resource server who receives the message from the client also needs to 
>>> have the session key to verify the message. How the resource server obtains 
>>> this session key was subject for some discussion on the call. I presented 
>>> three different ways of how the resource server is able to obtain that key. 
>>> We have to decide on one mandatory-to-implement mechanism. The open issue 
>>> is which one? 
>>> 
>>>> For the MAC token spec, I don't actually care whether we use JSON or now, 
>>>> but I'm in full agreement that we do NOT duplicate any HTTP info into the 
>>>> JSON.  Just signatures of that stuff.
>>>> 
>>> I believe the folks on the call also agreed with you on that aspect that 
>>> the content of the HTTP message should not be replicated in the JSON 
>>> payload itself. 
>>> 
>>> Ciao
>>> Hannes
>>> 
>>>> From: Hannes Tschofenig 
>>>> To: IETF oauth WG  
>>>> Sent: Tuesday, February 12, 2013 1:10 AM
>>>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
>>>> 11th February 2013
>>>> 
>>>> Here are my notes. 
>>>> 
>>>> Participants:
>>>> 
>>>> * John Bradley
>>>> * Derek Atkins
>>>> * Phil Hunt
>>>> * Prateek Mishra
>>>> * Hannes Tschofenig
>>>> * Mike Jones
>>>> * Antonio Sanso
>>>> * Justin Richer
>>>> 
>>>> Notes: 
>>>> 
>>>> My slides are available here: 
>>>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>>> 
>>>> Slide #2 summarizes earlier discussions during the conference calls. 
>>>> 
>>>> -- HTTP vs. JSON
>>>> 
>>>> Phil noted that he does not like to use the MAC Token draft as a starting 
>>>> point because it does not re-use any of the work done in the JOSE working 
>>>> group and in particular all the libraries that are available today. He 
>>>> mentioned that earlier attempts to write the MAC Token code lead to 
>>>> problems for implementers. 
>>>> 
>>>> Justin responded that he does not agree with using JSON as a transport 
>>>> mechanism since this would replicate a SOAP style. 
>>>> 
>>>> Phil noted that he wants to send JSON but the signature shall be computed 
>>>> over the HTTP header field. 
>>>> 
>>>> -- Flexibility for the keyed message digest computation
>>>> 
>>>> From earlier discussion it was clear that the conference call participants 
>>>> wanted more flexibility regarding the keyed message digest computation. 
>>>> For this purpose Hannes presented the DKIM based approach, which allows 
>>>> selective header fields to be included in the digest. This is shown in 
>>

Re: [OAUTH-WG] OAuth2 attack surface....

[Antonio Sanso]

And a different one (still exploiting redirection and still implementation 
mistake) 
http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html

Regards

Antonio

On Feb 25, 2013, at 11:42 PM, William Mills wrote:



DOH!!!  
http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html


From: Phil Hunt mailto:phil.h...@oracle.com>>
To: William Mills mailto:wmills_92...@yahoo.com>>
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills 
mailto:wmills_92...@yahoo.com>> wrote:

I think this is worth a read, I don't have time to dive into this :(
___
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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

[Antonio Sanso]

Hi Hannes,

apologies if I do the same question again but there is still one point that is 
a little obscure to me.

As long I did understand the situation for MAC is the following one.

The communication between the client and the authentication server must be 
https but this is not true for the communication between authentication server 
and resource server.
Hence the need of this key exchange.

Is it correct? Should be the case why we do not have the same problem in the 
JWT Bearer case? Is because in that case https is as well mandatory between 
authentication server and resource server?

Thanks a lot and regards

Antonio


On Feb 28, 2013, at 11:28 AM, Hannes Tschofenig wrote:

> Hi Bill, 
> 
> I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac 
> the client still uses the MAC when it accesses a protected resource. 
> The only place where the JWT comes into the picture is with the description 
> of the access token. This matters from a key distribution point of view. The 
> session key for the MAC is included in the encrypted JWT. The JWT is 
> encrypted by the authorization server and decrypted by the resource server. 
> 
> Information about how header fields get included in the MAC is described in 
> Section 5.
> 
> The nonce isn't killed it is just called differently: seq-nr. The stuff in 
> the original MAC specification actually wasn't a nonce (from the semantic 
> point of view). 
> The extension parameter is there implicitly by allowing additional header 
> fields to be included in the MAC computation.
> 
> I need to look at the port number field again. 
> 
> Ciao
> Hannes
> 
> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
> 
>> Just read the draft quickly.  
>> 
>> Since we're now leaning on JWT do we need to include the token in this?  Why 
>> not just make an additional "Envelope MAC" thing and have the signature 
>> include the 3 JWT parts in the signature base string?  That object then just 
>> becomes a JSON container for the kid, timestamp, signature method, signature 
>> etc. That thing then is a 4th base64 encoded JSON thing in the auth header.
>> 
>> How header fields get included in the signature needs definition.
>> 
>> Why did you kill the port number, nonce, and extension parameter out of the 
>> signature base string?
>> 
>> The BNF appears to have no separators between values.
>> 
>> -bill
>> 
>> 
>> From: "internet-dra...@ietf.org" 
>> To: i-d-annou...@ietf.org 
>> Cc: oauth@ietf.org 
>> Sent: Monday, February 25, 2013 4:46 AM
>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Web Authorization Protocol Working Group of 
>> the IETF.
>> 
>>Title  : OAuth 2.0 Message Authentication Code (MAC) Tokens
>>Author(s)  : Justin Richer
>>  William Mills
>>  Hannes Tschofenig
>>Filename: draft-ietf-oauth-v2-http-mac-03.txt
>>Pages  : 26
>>Date: 2013-02-25
>> 
>> Abstract:
>>  This specification describes how to use MAC Tokens in HTTP requests
>>  to access OAuth 2.0 protected resources.  An OAuth client willing to
>>  access a protected resource needs to demonstrate possession of a
>>  crytographic key by using it with a keyed message digest function to
>>  the request.
>> 
>>  The document also defines a key distribution protocol for obtaining a
>>  fresh session key.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 attack surface....

[Antonio Sanso]

On Mar 1, 2013, at 4:00 PM, prateek mishra wrote:

Yup, use of confidential clients and full checking of redirect URIs would 
mitigate these attacks.

I think there is an issue of providing guidance to developers/deployers, about 
making secure choices, that needs to be addressed someplace. A test suite
would also be a good complement to a document.

do you mean having a TCK for OAuth 2.0?



One challenge is that OAuth addresses such a broad class of clients - from 
angry birds all the way to transactional apps. I am a mostly interested
in the latter, it would be good to have a resource that i can point people to 
(and, yes, the TM document is good but I dont see it as something most 
developers/deployers would
 benefit from).

- prateek

While implicit is what they are attacking, this is in principal also possible 
to do with a code flow if the client is public.
It is only confidential clients using the code flow that have reasonable 
protection from open redirectors.

In openID Connect we made registered redirect_uri and full comparison of the 
URI including query parameters a requirement.

Allowing path or query parameters outside of the redirect comparison leaves too 
large of an uncontrolled attack surface.

Implementation mistakes are almost inevitable.

John B.
On 2013-02-28, at 2:56 PM, prateek mishra 
mailto:prateek.mis...@oracle.com>> wrote:

Characteristics of both these attacks -

1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility here)
3) applications with long-lived access tokens with broad scope (in one case 
only)

- prateek
And a different one (still exploiting redirection and still implementation 
mistake) 
http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html

Regards

Antonio

On Feb 25, 2013, at 11:42 PM, William Mills wrote:



DOH!!!  
http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html


From: Phil Hunt mailto:phil.h...@oracle.com>>
To: William Mills mailto:wmills_92...@yahoo.com>>
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills 
mailto:wmills_92...@yahoo.com>> wrote:

I think this is worth a read, I don't have time to dive into this :(
___
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




___
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


___
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

[OAUTH-WG] JWT spec

[Antonio Sanso]

Hi *,

the example plaintext in the JWT specification [0] has a "weird" JWT claims Set:


 {"iss":"joe",
  "exp":1300819380,
  "http://example.com/is_root":true}

The "http://example.com/is_root":true part looks a bit odd to me. Is it a typo?

Regards

Antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07#section-4.1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Recap of two well known OAuth related attacks

[Antonio Sanso]

Hi *,

I wrote a blog post showing two well known OAuth related attacks. I paste here 
the link for your consideration:

http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-devil-wears.html

Any comment is more than appreciated.

Regards

Antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recap of two well known OAuth related attacks

[Antonio Sanso]

Hi *,


I was wondering what you thing about the second "issue" described (the "Lassie 
come home").

I have encountered lately in one enterprise installation and I think is fairly 
easy to make it wrong as well.

Regards

Antonio

On May 17, 2013, at 5:46 PM, John Bradley wrote:

> The implicit flow is secure in Connect, but we added a number of things to 
> make it so.
> 
> The reason to have it in OAuth 2 is for clients in the browser there are use 
> cases for that and it allows the browser to receive and extract the token 
> without passing it to a web server backend.
> Used as intended it is fine as the browser based JS App is receiving the the 
> token directly over TLS so there is no substitution attack possible.   
> 
> The problem is when the client is not in the browser the browser itself is an 
> attack surface, that an attacker can use to confuse a client.
> 
> If people want to do SSO based on OAuth they need to follow the example of 
> Google, PayPal and others who are implementing Connect rather than rolling 
> there own protocol on top of OAuth 2.
> 
> John B.
> 
> 
> On 2013-05-17, at 5:22 PM, Lewis Adam-CAL022 
>  wrote:
> 
>> One wonders that - if in hindsight - the implicit flow was a mistake to 
>> include in the framework.  Yes it saves a single round trip for use cases 
>> where the tokens are exposed to the UA, but it's not clear that optimization 
>> is worth the security headaches that are going to be caused down the road 
>> (or are already going on for that matter) by people using it in scenarios 
>> where it should not be (because as stated, it is easier).  Probably would 
>> have been better to let the subset of cases that didn't need the extra step 
>> of the code just go ahead and implement it anyway, and ensure that the 
>> majority of native apps use cases would have been implemented with better 
>> security. 
>> 
>> adam
>> 
>> -----Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>> Richer, Justin P.
>> Sent: Wednesday, May 15, 2013 3:22 PM
>> To: Antonio Sanso
>> Cc: "WG "@il06exr01.mot.com
>> Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks
>> 
>> The biggest problem with this attack is the passing of the access token to a 
>> backend server (and its subsequent passing of that token to someone else) 
>> and the assumption that the presentation of the access token means that the 
>> user is authenticated and present. It simply doesn't mean that, and this is 
>> a bad assumption that unfortunately many people make thanks to providers 
>> like Facebook using OAuth (or, mostly-OAuth since they're not actually RFC 
>> compliant) in the authentication protocol.
>> 
>> It's also a problem that so many people are using the implicit flow "because 
>> it's easy", missing the point of why it's there in the first place. The 
>> implicit flow is really only intended for cases where you can't hide secrets 
>> from the user agent, cases like an in-browser application. The flow diagrams 
>> that you have don't fit the implicit flow very well at all, since the access 
>> token is getting passed back to some other service. 
>> 
>> -- Justin
>> 
>> On May 13, 2013, at 11:14 AM, Antonio Sanso 
>> wrote:
>> 
>>> Hi *,
>>> 
>>> I wrote a blog post showing two well known OAuth related attacks. I paste 
>>> here the link for your consideration:
>>> 
>>> http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-devil-wears.html
>>> 
>>> Any comment is more than appreciated.
>>> 
>>> Regards
>>> 
>>> Antonio
>>> ___
>>> 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
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

[OAUTH-WG] JWS encoding Appendix A

[Antonio Sanso]

Hi *,

while testing my encoding routine against JWS I spot a difference between my 
encoding and the one in the spec.

More specifically I am referring to Appendix A.1.1 [0] of the JWS spec.
Now it could easily be that the library I wrote is wrong but it works fine with 
the encoding in the JWT spec for example.
If somebody would like to give a look just for the record the encoding for the 
header in the spec looks like \


eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

while for me would look like

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Same for the payload, spec

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

my library

eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

Now the difference is probably given from the fact I did not take care in 
consideration carriage return in my input.
I am on a huge JSON expert but what is the correct way to handle it?

Regards

Antonio



[0] 
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#appendix-A.1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWS encoding Appendix A

[Antonio Sanso]

Thanks a lot Axel!!

Regards

Antonio

On Jun 5, 2013, at 3:37 PM, 
mailto:axel.nenn...@telekom.de>> wrote:

Antonio,
Please have a look at this
https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104

The \r\n is the important.

Please make sure you have this byte representation of the payload.
The following octet sequence contains the UTF-8 representation of the
   JWS Header:

   [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
   34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]


Best regards
Axel

From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org] On Behalf Of Antonio Sanso
Sent: Wednesday, June 05, 2013 3:27 PM
To: oauth@ietf.org<mailto:oauth@ietf.org> WG
Subject: [OAUTH-WG] JWS encoding Appendix A

Hi *,

while testing my encoding routine against JWS I spot a difference between my 
encoding and the one in the spec.

More specifically I am referring to Appendix A.1.1 [0] of the JWS spec.
Now it could easily be that the library I wrote is wrong but it works fine with 
the encoding in the JWT spec for example.
If somebody would like to give a look just for the record the encoding for the 
header in the spec looks like \


eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

while for me would look like

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Same for the payload, spec

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

my library

eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

Now the difference is probably given from the fact I did not take care in 
consideration carriage return in my input.
I am on a huge JSON expert but what is the correct way to handle it?

Regards

Antonio



[0] 
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#appendix-A.1

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

[Antonio Sanso]

Hi Hannes,

thanks a lot for your notes.

As suggested from you guys yesterday I'd like to bring on my little point :) 
(that is really orthogonal to the whole discussion).

IMHO since the dynamic registration is still on a design phase it would be 
really nice to include something that Google already implemented in order to 
allow server-to-server communication [0].

In order to allow this, in the registration phase, there is the option to 
download a private key (in order to allow the client to sign self produced 
signed JWT without 'human interaction'), quoting [0]

"During the creation of a Service Account, you will be prompted to download a 
private key. Be sure to save this private key in a secure location. After the 
Service Account has been created, you will also have access to the client_id 
associated with the private key." 


IMHO this is a really clever way to use OAuth and would be nice to see this 
standardized and having it on the big picture. Obviously this should be just an 
optional field.

Just my 0.02 $

Thanks and regards

Antonio

[0] https://developers.google.com/accounts/docs/OAuth2ServiceAccount



On Aug 23, 2013, at 10:24 AM, Hannes Tschofenig wrote:

> Thank you all for joining yesterday's conference call. I took some notes 
> during the call.
> 
>  Meeting Minutes 
> 
> Participants:
> - William Kim
> - John Bradley
> - Antonio Sanso
> - Mike Jones
> - Phil Hunt
> - Justin Richer
> - Hannes Tschofenig
> - Derek Atkins
> - Amanda Anganes
> - Morteza Ansari
> - Brian Campbell
> - Thomas Hardjono
> - Prateek Mishra
> - George Fletcher
> - Tony Nadalin
> 
> Minutes
> 
> Justin started with a discussion about what is described in Section 1.3 
> of the protocol specification and Appendix B describes the use cases.
> 
> Dynamic client registration is one way to introduce a client to an 
> authorization server.
> A client is the relationship between a client piece software and a piece 
> of software on the authorization server side.
> The client needs a client_id and the authorization server needs to get 
> various other piece of information (such as a redirect_uri, display_name).
> 
> The group then started a discussion about what the minimal amount of 
> information is the authorization server needs to have.
> 
> The discussion then shifted to uses cases where trust is established 
> a-priori (out-of-band) and is conveyed via an assertion to the dyn-reg 
> exchange (protected registration) and the case where there is no trust 
> (=open registration); the latter case would push the obligation to the 
> user.
> 
> There seems to be agreement (on the call) that both use cases are valid.
> 
> The following examples for protected registration have been discussed:
> 
>  * manual page where the developer obtains a developer key and register 
> there; they end up with an initial access token (in the form of an 
> bearer token)
>  * UMA case where there is someone who is introducing the two parties 
> to each other. (Currently not described in the document)
>  * Developer Automation: Who holds the client registration information? 
> The developer makes the call and you get the client_id back. The client 
> is not doing the dyn. registration. (This use case is described in 
> Appendix B.3)
>  * John's use case: 
> http://www.ietf.org/mail-archive/web/oauth/current/msg12008.html
> 
> Phil Hunt starts with his presentation slides, which he had distributed 
> to the mailing list earlier:
> http://www.ietf.org/mail-archive/web/oauth/current/msg12007.html
> 
> Phil says that the client_id does not need to be provided by the AS - it 
> could be provided by the client. John says that the client_id has to be 
> tied to the redirect_uri since otherwise attacks are possible.
> 
> Phil says we are lacking good terminology for client, and for client 
> instance.
> 
> George claims that the client instance concept came up when mobile 
> clients and Web clients got mixed in deployments and people wanted to 
> have a way to distinguish the two since they were different in their 
> ability to keep a secret.
> 
> A discussion started about whether an evolution had happened regarding 
> different types of clients. The client id is a proxy for some release of 
> some software. Someone claimed that with dynamic client registration we 
> have the ability to turn public clients back into confidential clients.
> 
> Phil argues that service providers want to know the class of 
> applications and the instances. A problem with a client can be a 
> compromise and you want to disable it. There may also be a bug in the 
> software and then one may want to disable the entire class of clients.
> 
> Phil asks whether 

Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

[Antonio Sanso]

Thanks a lot John for your answer. 

How about the server to server flow per se as in [0].

Is it standardized anywhere (OAuth/OIDC)? Or is just custom at Google?

I think this is kind of clever and really suites case where there is not "human 
interaction"

regards

Antonio


From: John Bradley [ve7...@ve7jtb.com]
Sent: 23 August 2013 18:16
To: Antonio Sanso
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting 
Minutes (22. Aug)

We have that in the OIDC version where the client publishes it's public key.  
That is in general better from a security point of view if you believe clients 
can securely generate key pairs.

It is not in the IETF version because we were asked not to include 
authentication methods not defined in the core spec, as they were thought best 
to be extensions.

It currently looks like the pressure is on to remove confuguration options 
rather than add them.

I agree that client registration is a reasonable place to exchange keys and 
avoid having symmetric secrets,  that is the preferred OIDC implementation for 
clients that can support it.

John B.


On 2013-08-23, at 4:55 AM, Antonio Sanso  wrote:

> Hi Hannes,
>
> thanks a lot for your notes.
>
> As suggested from you guys yesterday I'd like to bring on my little point :) 
> (that is really orthogonal to the whole discussion).
>
> IMHO since the dynamic registration is still on a design phase it would be 
> really nice to include something that Google already implemented in order to 
> allow server-to-server communication [0].
>
> In order to allow this, in the registration phase, there is the option to 
> download a private key (in order to allow the client to sign self produced 
> signed JWT without 'human interaction'), quoting [0]
>
> "During the creation of a Service Account, you will be prompted to download a 
> private key. Be sure to save this private key in a secure location. After the 
> Service Account has been created, you will also have access to the client_id 
> associated with the private key."
>
>
> IMHO this is a really clever way to use OAuth and would be nice to see this 
> standardized and having it on the big picture. Obviously this should be just 
> an optional field.
>
> Just my 0.02 $
>
> Thanks and regards
>
> Antonio
>
> [0] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>
>
>
> On Aug 23, 2013, at 10:24 AM, Hannes Tschofenig wrote:
>
>> Thank you all for joining yesterday's conference call. I took some notes
>> during the call.
>>
>>  Meeting Minutes 
>>
>> Participants:
>> - William Kim
>> - John Bradley
>> - Antonio Sanso
>> - Mike Jones
>> - Phil Hunt
>> - Justin Richer
>> - Hannes Tschofenig
>> - Derek Atkins
>> - Amanda Anganes
>> - Morteza Ansari
>> - Brian Campbell
>> - Thomas Hardjono
>> - Prateek Mishra
>> - George Fletcher
>> - Tony Nadalin
>>
>> Minutes
>>
>> Justin started with a discussion about what is described in Section 1.3
>> of the protocol specification and Appendix B describes the use cases.
>>
>> Dynamic client registration is one way to introduce a client to an
>> authorization server.
>> A client is the relationship between a client piece software and a piece
>> of software on the authorization server side.
>> The client needs a client_id and the authorization server needs to get
>> various other piece of information (such as a redirect_uri, display_name).
>>
>> The group then started a discussion about what the minimal amount of
>> information is the authorization server needs to have.
>>
>> The discussion then shifted to uses cases where trust is established
>> a-priori (out-of-band) and is conveyed via an assertion to the dyn-reg
>> exchange (protected registration) and the case where there is no trust
>> (=open registration); the latter case would push the obligation to the
>> user.
>>
>> There seems to be agreement (on the call) that both use cases are valid.
>>
>> The following examples for protected registration have been discussed:
>>
>> * manual page where the developer obtains a developer key and register
>> there; they end up with an initial access token (in the form of an
>> bearer token)
>> * UMA case where there is someone who is introducing the two parties
>> to each other. (Currently not described in the document)
>> * Developer Automation: Who holds the client registration information?
>> The developer makes the call and you get the client_id back. The client

[OAUTH-WG] Oauth Server to Server was: Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

[Antonio Sanso]

anyone :) ?

Begin forwarded message:

From: Antonio Sanso mailto:asa...@adobe.com>>
Date: August 23, 2013 6:42:18 PM GMT+02:00
To: John Bradley mailto:ve7...@ve7jtb.com>>
Cc: Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>>, 
"oauth@ietf.org<mailto:oauth@ietf.org> WG" 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting 
Minutes (22. Aug)

Thanks a lot John for your answer.

How about the server to server flow per se as in [0].

Is it standardized anywhere (OAuth/OIDC)? Or is just custom at Google?

I think this is kind of clever and really suites case where there is not "human 
interaction"

regards

Antonio


From: John Bradley [ve7...@ve7jtb.com]
Sent: 23 August 2013 18:16
To: Antonio Sanso
Cc: Hannes Tschofenig; oauth@ietf.org<mailto:oauth@ietf.org> WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting 
Minutes (22. Aug)

We have that in the OIDC version where the client publishes it's public key.  
That is in general better from a security point of view if you believe clients 
can securely generate key pairs.

It is not in the IETF version because we were asked not to include 
authentication methods not defined in the core spec, as they were thought best 
to be extensions.

It currently looks like the pressure is on to remove confuguration options 
rather than add them.

I agree that client registration is a reasonable place to exchange keys and 
avoid having symmetric secrets,  that is the preferred OIDC implementation for 
clients that can support it.

John B.


On 2013-08-23, at 4:55 AM, Antonio Sanso 
mailto:asa...@adobe.com>> wrote:

Hi Hannes,

thanks a lot for your notes.

As suggested from you guys yesterday I'd like to bring on my little point :) 
(that is really orthogonal to the whole discussion).

IMHO since the dynamic registration is still on a design phase it would be 
really nice to include something that Google already implemented in order to 
allow server-to-server communication [0].

In order to allow this, in the registration phase, there is the option to 
download a private key (in order to allow the client to sign self produced 
signed JWT without 'human interaction'), quoting [0]

"During the creation of a Service Account, you will be prompted to download a 
private key. Be sure to save this private key in a secure location. After the 
Service Account has been created, you will also have access to the client_id 
associated with the private key."


IMHO this is a really clever way to use OAuth and would be nice to see this 
standardized and having it on the big picture. Obviously this should be just an 
optional field.

Just my 0.02 $

Thanks and regards

Antonio

[0] https://developers.google.com/accounts/docs/OAuth2ServiceAccount



On Aug 23, 2013, at 10:24 AM, Hannes Tschofenig wrote:

Thank you all for joining yesterday's conference call. I took some notes
during the call.

 Meeting Minutes 

Participants:
- William Kim
- John Bradley
- Antonio Sanso
- Mike Jones
- Phil Hunt
- Justin Richer
- Hannes Tschofenig
- Derek Atkins
- Amanda Anganes
- Morteza Ansari
- Brian Campbell
- Thomas Hardjono
- Prateek Mishra
- George Fletcher
- Tony Nadalin

Minutes

Justin started with a discussion about what is described in Section 1.3
of the protocol specification and Appendix B describes the use cases.

Dynamic client registration is one way to introduce a client to an
authorization server.
A client is the relationship between a client piece software and a piece
of software on the authorization server side.
The client needs a client_id and the authorization server needs to get
various other piece of information (such as a redirect_uri, display_name).

The group then started a discussion about what the minimal amount of
information is the authorization server needs to have.

The discussion then shifted to uses cases where trust is established
a-priori (out-of-band) and is conveyed via an assertion to the dyn-reg
exchange (protected registration) and the case where there is no trust
(=open registration); the latter case would push the obligation to the
user.

There seems to be agreement (on the call) that both use cases are valid.

The following examples for protected registration have been discussed:

* manual page where the developer obtains a developer key and register
there; they end up with an initial access token (in the form of an
bearer token)
* UMA case where there is someone who is introducing the two parties
to each other. (Currently not described in the document)
* Developer Automation: Who holds the client registration information?
The developer makes the call and you get the client_id back. The client
is not doing the dyn. registration. (This use case is described in
Appendix B.3)
* John's use case:
http://www.ietf.org/mail-archive/web/oauth

[OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good to 
have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth server to server 
is to use [0] namely Resource Owner Password Credentials Grant.

Let me tell I am not a big fun of this particular flow :) (but this is another 
story).

An arguable better way to solve this scenario is to user (and why not to 
standardise :S?) the method used by Google (or a variant of it) see [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to standardise 
it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in 
consideration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

Hi Brian,

thanks a lot for your pointer.

What the custom Google flow provides more than the oauth jwt bearer draft is 
IMHO an explicit way to build JWT without any 'human interaction' so a server 
can handle the construction of an expired JWT bearer token on his own.

This can of course be figured out by any implementer (as the Google folks 
obviously did) but it would be nice to provide this black on white on a spec 
IMHO

regards

Antonio


On Sep 24, 2013, at 2:35 PM, Brian Campbell  wrote:

> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what 
> you're looking for?
> 
> 
> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso  wrote:
> Hi *,
> 
> apologis to be back to this argument :).
> 
> Let me try to better explain one use case that IMHO would be really good to 
> have in the OAuth specification family :)
> 
> At the moment the only "OAuth standard" way I know to do OAuth server to 
> server is to use [0] namely Resource Owner Password Credentials Grant.
> 
> Let me tell I am not a big fun of this particular flow :) (but this is 
> another story).
> 
> An arguable better way to solve this scenario is to user (and why not to 
> standardise :S?) the method used by Google (or a variant of it) see [1].
> 
> Couple of more things:
> 
> - I do not know if Google would be interested to put some effort to 
> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
> - I am not too familiar with IETF process. Would the OAuth WG take in 
> consideration such proposal draft??
> 
> Thanks and regards
> 
> Antonio
> 
> [0] http://tools.ietf.org/html/rfc6749#section-4.3
> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
> ___
> 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

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

Hi chuck,


On Sep 24, 2013, at 4:57 PM, Chuck Mortimore  wrote:

> I'm not sure I understand your point here.   I don't believe there is 
> anything custom or special about the google implementation here vs JWT.   It 
> looks identical to our implementation.  
> 
> Can you elaborate?

sure.

What is novel IMHO in the Google approach is not the bearer format , that is 
still JWT (or JWS in this case) but the overall scenario.

As I see OAuth 2 is really good to cover use cases where there is human 
interaction (so an user namely the resource owner can provider username and 
password to the AS but not to the client and get back the Bearer Token).
This is obviously covered from [2] and [3] namely Authorization Code Grant and 
Implicit grant flow.

When there is not human interaction involved what RFC6749 offers is the already 
cited Resource Owner Password Credentials Grant that IMHO is a no go since it 
required the resource owner to share his password with the client.

The way as Google offers to solve the same situation (namely obtain , or create 
in this case, a bearer token without having the resource owner password) is 
using asymmetric cryptography. What is happening is that quoting

"During the creation of a Service Account, you will be prompted to download a 
private key. Be sure to save this private key in a secure location. After the 
Service Account has been created, you will also have access to the client_id 
associated with the private key."

An alternative mentioned from John Bradley previously is that clients can 
securely generate key pairs but in terms of security would be identical.

I hope is a bit clearer now  :)

regards

antonio


[2] http://tools.ietf.org/html/rfc6749#section-4.1
[3] http://tools.ietf.org/html/rfc6749#section-4.2

> 
> - cmort
> 
> On Sep 24, 2013, at 5:57 AM, Antonio Sanso  wrote:
> 
>> Hi Brian,
>> 
>> thanks a lot for your pointer.
>> 
>> What the custom Google flow provides more than the oauth jwt bearer draft is 
>> IMHO an explicit way to build JWT without any 'human interaction' so a 
>> server can handle the construction of an expired JWT bearer token on his own.
>> 
>> This can of course be figured out by any implementer (as the Google folks 
>> obviously did) but it would be nice to provide this black on white on a spec 
>> IMHO
>> 
>> regards
>> 
>> Antonio
>> 
>> 
>> On Sep 24, 2013, at 2:35 PM, Brian Campbell  
>> wrote:
>> 
>>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what 
>>> you're looking for?
>>> 
>>> 
>>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso  wrote:
>>> Hi *,
>>> 
>>> apologis to be back to this argument :).
>>> 
>>> Let me try to better explain one use case that IMHO would be really good to 
>>> have in the OAuth specification family :)
>>> 
>>> At the moment the only "OAuth standard" way I know to do OAuth server to 
>>> server is to use [0] namely Resource Owner Password Credentials Grant.
>>> 
>>> Let me tell I am not a big fun of this particular flow :) (but this is 
>>> another story).
>>> 
>>> An arguable better way to solve this scenario is to user (and why not to 
>>> standardise :S?) the method used by Google (or a variant of it) see [1].
>>> 
>>> Couple of more things:
>>> 
>>> - I do not know if Google would be interested to put some effort to 
>>> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>>> - I am not too familiar with IETF process. Would the OAuth WG take in 
>>> consideration such proposal draft??
>>> 
>>> Thanks and regards
>>> 
>>> Antonio
>>> 
>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>> ___
>>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

On Sep 24, 2013, at 5:22 PM, Bill Mills  wrote:

> So they are using client authentication as defined on OAuth 2 then?


good point indeed :) My main point is that all the pieces of the puzzle to 
solve this scenario are probably there beetwen the OAuth core the JWT and the 
JWT bearer token specifications but it would be tough to an OAuth newbie to 
figure out all this on his own….

regards

antonio

> 
> 
> On Tuesday, September 24, 2013 8:18 AM, Antonio Sanso  
> wrote:
> Hi chuck,
> 
> 
> On Sep 24, 2013, at 4:57 PM, Chuck Mortimore  
> wrote:
> 
>> I'm not sure I understand your point here.   I don't believe there is 
>> anything custom or special about the google implementation here vs JWT.   It 
>> looks identical to our implementation.  
>> 
>> Can you elaborate?
> 
> sure.
> 
> What is novel IMHO in the Google approach is not the bearer format , that is 
> still JWT (or JWS in this case) but the overall scenario.
> 
> As I see OAuth 2 is really good to cover use cases where there is human 
> interaction (so an user namely the resource owner can provider username and 
> password to the AS but not to the client and get back the Bearer Token).
> This is obviously covered from [2] and [3] namely Authorization Code Grant 
> and Implicit grant flow.
> 
> When there is not human interaction involved what RFC6749 offers is the 
> already cited Resource Owner Password Credentials Grant that IMHO is a no go 
> since it required the resource owner to share his password with the client.
> 
> The way as Google offers to solve the same situation (namely obtain , or 
> create in this case, a bearer token without having the resource owner 
> password) is using asymmetric cryptography. What is happening is that quoting
> 
> "During the creation of a Service Account, you will be prompted to download a 
> private key. Be sure to save this private key in a secure location. After the 
> Service Account has been created, you will also have access to the client_id 
> associated with the private key."
> 
> An alternative mentioned from John Bradley previously is that clients can 
> securely generate key pairs but in terms of security would be identical.
> 
> I hope is a bit clearer now  :)
> 
> regards
> 
> antonio
> 
> 
> [2] http://tools.ietf.org/html/rfc6749#section-4.1
> [3] http://tools.ietf.org/html/rfc6749#section-4.2
> 
>> 
>> - cmort
>> 
>> On Sep 24, 2013, at 5:57 AM, Antonio Sanso  wrote:
>> 
>>> Hi Brian,
>>> 
>>> thanks a lot for your pointer.
>>> 
>>> What the custom Google flow provides more than the oauth jwt bearer draft 
>>> is IMHO an explicit way to build JWT without any 'human interaction' so a 
>>> server can handle the construction of an expired JWT bearer token on his 
>>> own.
>>> 
>>> This can of course be figured out by any implementer (as the Google folks 
>>> obviously did) but it would be nice to provide this black on white on a 
>>> spec IMHO
>>> 
>>> regards
>>> 
>>> Antonio
>>> 
>>> 
>>> On Sep 24, 2013, at 2:35 PM, Brian Campbell  
>>> wrote:
>>> 
>>>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what 
>>>> you're looking for?
>>>> 
>>>> 
>>>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso  wrote:
>>>> Hi *,
>>>> 
>>>> apologis to be back to this argument :).
>>>> 
>>>> Let me try to better explain one use case that IMHO would be really good 
>>>> to have in the OAuth specification family :)
>>>> 
>>>> At the moment the only "OAuth standard" way I know to do OAuth server to 
>>>> server is to use [0] namely Resource Owner Password Credentials Grant.
>>>> 
>>>> Let me tell I am not a big fun of this particular flow :) (but this is 
>>>> another story).
>>>> 
>>>> An arguable better way to solve this scenario is to user (and why not to 
>>>> standardise :S?) the method used by Google (or a variant of it) see [1].
>>>> 
>>>> Couple of more things:
>>>> 
>>>> - I do not know if Google would be interested to put some effort to 
>>>> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>>>> - I am not too familiar with IETF process. Would the OAuth WG take in 
>>>> consideration such proposal draft??
>>>> 
>>>> Thanks and regards
>>>> 
>>>> Antonio
>>>> 
>>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>>> ___
>>>> 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
> 
> 
> ___
> 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

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

Hi Chuck,

On Sep 24, 2013, at 6:56 PM, Chuck Mortimore  wrote:

> What you're describing is exactly what the JWT bearer flow specs out
> 
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer 
> 
> We've got the exact same flow, and there are other implementations out there. 
>   http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm


thanks this is indeed the same :) What it looks to me though is that the 
information contained in the second link you shared 
(http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm) are 
complementary to the jet bearer spec draft.

People that will only read that spec would need to figure out all on their own 
. Is there any chance the oauth bearer draft will cover the actual use case as 
well or it would be too much ?

Regards

Antonio

> 
> 
> On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso  wrote:
> Hi chuck,
> 
> 
> On Sep 24, 2013, at 4:57 PM, Chuck Mortimore  
> wrote:
> 
>> I'm not sure I understand your point here.   I don't believe there is 
>> anything custom or special about the google implementation here vs JWT.   It 
>> looks identical to our implementation.  
>> 
>> Can you elaborate?
> 
> sure.
> 
> What is novel IMHO in the Google approach is not the bearer format , that is 
> still JWT (or JWS in this case) but the overall scenario.
> 
> As I see OAuth 2 is really good to cover use cases where there is human 
> interaction (so an user namely the resource owner can provider username and 
> password to the AS but not to the client and get back the Bearer Token).
> This is obviously covered from [2] and [3] namely Authorization Code Grant 
> and Implicit grant flow.
> 
> When there is not human interaction involved what RFC6749 offers is the 
> already cited Resource Owner Password Credentials Grant that IMHO is a no go 
> since it required the resource owner to share his password with the client.
> 
> The way as Google offers to solve the same situation (namely obtain , or 
> create in this case, a bearer token without having the resource owner 
> password) is using asymmetric cryptography. What is happening is that quoting
> 
> "During the creation of a Service Account, you will be prompted to download a 
> private key. Be sure to save this private key in a secure location. After the 
> Service Account has been created, you will also have access to the client_id 
> associated with the private key."
> 
> An alternative mentioned from John Bradley previously is that clients can 
> securely generate key pairs but in terms of security would be identical.
> 
> I hope is a bit clearer now  :)
> 
> regards
> 
> antonio
> 
> 
> [2] http://tools.ietf.org/html/rfc6749#section-4.1
> [3] http://tools.ietf.org/html/rfc6749#section-4.2
> 
>> 
>> - cmort
>> 
>> On Sep 24, 2013, at 5:57 AM, Antonio Sanso  wrote:
>> 
>>> Hi Brian,
>>> 
>>> thanks a lot for your pointer.
>>> 
>>> What the custom Google flow provides more than the oauth jwt bearer draft 
>>> is IMHO an explicit way to build JWT without any 'human interaction' so a 
>>> server can handle the construction of an expired JWT bearer token on his 
>>> own.
>>> 
>>> This can of course be figured out by any implementer (as the Google folks 
>>> obviously did) but it would be nice to provide this black on white on a 
>>> spec IMHO
>>> 
>>> regards
>>> 
>>> Antonio
>>> 
>>> 
>>> On Sep 24, 2013, at 2:35 PM, Brian Campbell  
>>> wrote:
>>> 
>>>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what 
>>>> you're looking for?
>>>> 
>>>> 
>>>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso  wrote:
>>>> Hi *,
>>>> 
>>>> apologis to be back to this argument :).
>>>> 
>>>> Let me try to better explain one use case that IMHO would be really good 
>>>> to have in the OAuth specification family :)
>>>> 
>>>> At the moment the only "OAuth standard" way I know to do OAuth server to 
>>>> server is to use [0] namely Resource Owner Password Credentials Grant.
>>>> 
>>>> Let me tell I am not a big fun of this particular flow :) (but this is 
>>>> another story).
>>>> 
>>>> An arguable better way to solve this scenario is to user (and why not to 
>>>> standardise :S?) the method used by Google (or a variant of it) see [1].
>>>> 
>>>> Couple of more things:
>

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

On Sep 26, 2013, at 2:34 PM, Sergey Beryozkin  wrote:

> On 24/09/13 13:08, Antonio Sanso wrote:
>> Hi *,
>> 
>> apologis to be back to this argument :).
>> 
>> Let me try to better explain one use case that IMHO would be really good to 
>> have in the OAuth specification family :)
>> 
>> At the moment the only "OAuth standard" way I know to do OAuth server to 
>> server is to use [0] namely Resource Owner Password Credentials Grant.
>> 
>> Let me tell I am not a big fun of this particular flow :) (but this is 
>> another story).
>> 
>> An arguable better way to solve this scenario is to user (and why not to 
>> standardise :S?) the method used by Google (or a variant of it) see [1].
> 
> 2-way TLS and Resource Owner Password Credentials should be secure 
> enough, right ?
> 

secure is secure what I do not like of that flow though is the fact that the 
resource owner should give the AS username/password to the client

regards

antonio

> Cheers, Sergey
>> 
>> Couple of more things:
>> 
>> - I do not know if Google would be interested to put some effort to 
>> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>> - I am not too familiar with IETF process. Would the OAuth WG take in 
>> consideration such proposal draft??
>> 
>> Thanks and regards
>> 
>> Antonio
>> 
>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>> ___
>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

On Sep 26, 2013, at 3:40 PM, Justin Richer  wrote:

> From what I read, it sounds like you want either the assertion flow 
> (which is defined in extensions)

I do agree the assertion flow + JWT bearer token will suffice

> or the client credentials flow

not too sure about this though since it requires human interaction on input 
username/password

regards

antonio

> (not the 
> resource owner password flow). In either of these, the client 
> authenticates on its own behalf and gets a token directly with no user 
> involved, and both are fully specified.
> 
>  -- Justin
> 
> On 09/24/2013 08:08 AM, Antonio Sanso wrote:
>> Hi *,
>> 
>> apologis to be back to this argument :).
>> 
>> Let me try to better explain one use case that IMHO would be really good to 
>> have in the OAuth specification family :)
>> 
>> At the moment the only "OAuth standard" way I know to do OAuth server to 
>> server is to use [0] namely Resource Owner Password Credentials Grant.
>> 
>> Let me tell I am not a big fun of this particular flow :) (but this is 
>> another story).
>> 
>> An arguable better way to solve this scenario is to user (and why not to 
>> standardise :S?) the method used by Google (or a variant of it) see [1].
>> 
>> Couple of more things:
>> 
>> - I do not know if Google would be interested to put some effort to 
>> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>> - I am not too familiar with IETF process. Would the OAuth WG take in 
>> consideration such proposal draft??
>> 
>> Thanks and regards
>> 
>> Antonio
>> 
>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>> ___
>> 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

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

Thanks Chuck

On Sep 24, 2013, at 6:56 PM, Chuck Mortimore  wrote:

> Open to how it can be improved.   What information do you think would be 
> helpful?   ( we may be too close to the situation to know what's missing )

I am reading carefully the 2 specs now (assertion and JWT bearer) and will try 
to provide my feedback :)

A couple of (early) consideration so far:

- in order for somebody to easily achieve/understand what is clearly described 
in http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm only 
reading the IETF materials is needed to read 3 specs (OAuth Core, Assertion 
spec and JWT bearer). IT would be nice for example if the JWT bearer spec would 
add some more hands on example (I do not know if it is possible though)
- The assertion spec 
(http://tools.ietf.org/html/draft-ietf-oauth-assertions-12) contains terms like 
and include those terms in the flow charts as Relying party , Token Service 
that I know are really common in the Identity jargon (or Open ID Connect specs) 
but this nomenclature doesn't match with the OAuth core specs (namely RFC 6749)

just my 0.02 $ so far (more to come)

regards

antonio

> 
> 
> On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso  wrote:
> Hi Chuck,
> 
> On Sep 24, 2013, at 6:56 PM, Chuck Mortimore  
> wrote:
> 
>> What you're describing is exactly what the JWT bearer flow specs out
>> 
>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer 
>> 
>> We've got the exact same flow, and there are other implementations out 
>> there.   
>> http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm
> 
> 
> thanks this is indeed the same :) What it looks to me though is that the 
> information contained in the second link you shared 
> (http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm) are 
> complementary to the jet bearer spec draft.
> 
> People that will only read that spec would need to figure out all on their 
> own . Is there any chance the oauth bearer draft will cover the actual use 
> case as well or it would be too much ?
> 
> Regards
> 
> Antonio
> 
>> 
>> 
>> On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso  wrote:
>> Hi chuck,
>> 
>> 
>> On Sep 24, 2013, at 4:57 PM, Chuck Mortimore  
>> wrote:
>> 
>>> I'm not sure I understand your point here.   I don't believe there is 
>>> anything custom or special about the google implementation here vs JWT.   
>>> It looks identical to our implementation.  
>>> 
>>> Can you elaborate?
>> 
>> sure.
>> 
>> What is novel IMHO in the Google approach is not the bearer format , that is 
>> still JWT (or JWS in this case) but the overall scenario.
>> 
>> As I see OAuth 2 is really good to cover use cases where there is human 
>> interaction (so an user namely the resource owner can provider username and 
>> password to the AS but not to the client and get back the Bearer Token).
>> This is obviously covered from [2] and [3] namely Authorization Code Grant 
>> and Implicit grant flow.
>> 
>> When there is not human interaction involved what RFC6749 offers is the 
>> already cited Resource Owner Password Credentials Grant that IMHO is a no go 
>> since it required the resource owner to share his password with the client.
>> 
>> The way as Google offers to solve the same situation (namely obtain , or 
>> create in this case, a bearer token without having the resource owner 
>> password) is using asymmetric cryptography. What is happening is that quoting
>> 
>> "During the creation of a Service Account, you will be prompted to download 
>> a private key. Be sure to save this private key in a secure location. After 
>> the Service Account has been created, you will also have access to the 
>> client_id associated with the private key."
>> 
>> An alternative mentioned from John Bradley previously is that clients can 
>> securely generate key pairs but in terms of security would be identical.
>> 
>> I hope is a bit clearer now  :)
>> 
>> regards
>> 
>> antonio
>> 
>> 
>> [2] http://tools.ietf.org/html/rfc6749#section-4.1
>> [3] http://tools.ietf.org/html/rfc6749#section-4.2
>> 
>>> 
>>> - cmort
>>> 
>>> On Sep 24, 2013, at 5:57 AM, Antonio Sanso  wrote:
>>> 
>>>> Hi Brian,
>>>> 
>>>> thanks a lot for your pointer.
>>>> 
>>>> What the custom Google flow provides more than the oauth jwt bearer draft 
>>>> is IMHO an explicit way to build JWT without any 'human interaction' 

Re: [OAUTH-WG] Oauth Server to Server

[Antonio Sanso]

On Sep 27, 2013, at 10:35 AM, Antonio Sanso  wrote:

> 
> On Sep 26, 2013, at 3:40 PM, Justin Richer  wrote:
> 
>> From what I read, it sounds like you want either the assertion flow 
>> (which is defined in extensions)
> 
> I do agree the assertion flow + JWT bearer token will suffice
> 
>> or the client credentials flow
> 
> not too sure about this though since it requires human interaction on input 
> username/password

ops apologies you are off course right. I wrongly mixed the client credentials 
flow with the implicit grant (sometime also called client-side... :s)

regards

Antonio
> 
> regards
> 
> antonio
> 
>> (not the 
>> resource owner password flow). In either of these, the client 
>> authenticates on its own behalf and gets a token directly with no user 
>> involved, and both are fully specified.
>> 
>> -- Justin
>> 
>> On 09/24/2013 08:08 AM, Antonio Sanso wrote:
>>> Hi *,
>>> 
>>> apologis to be back to this argument :).
>>> 
>>> Let me try to better explain one use case that IMHO would be really good to 
>>> have in the OAuth specification family :)
>>> 
>>> At the moment the only "OAuth standard" way I know to do OAuth server to 
>>> server is to use [0] namely Resource Owner Password Credentials Grant.
>>> 
>>> Let me tell I am not a big fun of this particular flow :) (but this is 
>>> another story).
>>> 
>>> An arguable better way to solve this scenario is to user (and why not to 
>>> standardise :S?) the method used by Google (or a variant of it) see [1].
>>> 
>>> Couple of more things:
>>> 
>>> - I do not know if Google would be interested to put some effort to 
>>> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>>> - I am not too familiar with IETF process. Would the OAuth WG take in 
>>> consideration such proposal draft??
>>> 
>>> Thanks and regards
>>> 
>>> Antonio
>>> 
>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>> ___
>>> 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

Re: [OAUTH-WG] Resource Owner Password Credential error response question

[Antonio Sanso]

On Jan 28, 2014, at 5:08 PM, George Fletcher 
mailto:gffle...@aol.com>> wrote:

I have a situation where some "trusted" clients would like to use the ROPC 
flow. However, there are a number of external circumstances that can block the 
request even though the user's credentials are actually valid. Basically, from 
a back-end perspective we want to force the user through a web flow. I looked 
through the list of error responses and none seem to fit. 'invalid_grant' is 
the closest but that wouldn't give the client any indication that the user 
might be able to successfully complete the authorization flow if the client 
sends the user through a web flow instead of the ROPC flow.

Now I know one answer... which is... to just always use the web flow :)

+1, :) why can’t you use this in your case?

regards

antonio


Has any one else run into this? Do I register a new error response via Section 
11.4? In looking at the template it doesn't appear possible to add error 
responses to an existing flow.

Does that mean I'd need to create an extension grant that is basically the same 
as the ROPC but because it's an extension now can have additional error 
responses?

Best practice guidance greatly appreciated! :)

Thanks,
George


--

___
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

[OAUTH-WG] Some OAuth related vulnerability in Google and Facebook

[Antonio Sanso]

hi *,

just sharing with you some implementation OAuth related leak in Google and 
Facebook. Some details in:

http://intothesymmetry.blogspot.ch/2014/02/oauth-2-attacks-and-bug-bounties.html

regards

antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] JSON Web Token (JWT) Profile

[Antonio Sanso]

hi *,

JSON Web Token (JWT) Profile section 3 [0] explicitely says


The JWT MUST contain a "sub" (subject) claim

Now IMHO there are cases where having the sub is either not needed or redundant 
(since it might overlap with the issuer).\

As far as I can see “even Google” currently violates this spec [1] ( I know 
that this doesn’t matter, just wanted to bring a real use case scenario).

WDYT might the “sub” be optional in some situation?

regards

antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3
[1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

[Antonio Sanso]

hi Hannes,

I am aware of the 2 documents,

I might be wrong but http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 
is also about Authorization Grant Processing (this is the part I do use in my 
implementation ) and not only Client Authentication Processing.

Just my 0.02 $ but this seems to be a place where different implementer have 
the same issue :)

regards

antonio

On Mar 11, 2014, at 3:36 PM, Hannes Tschofenig  
wrote:

> Hi Manfred, Hi Antonio,
> 
> Note that there are two documents that talk about the JWT and you guys
> might be looking at the wrong document.
> 
> The main JWT document (see
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines
> the subject claim as optional (see Section 4.1.2).
> 
> The JWT bearer assertion document (see
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does indeed
> define it as mandatory but that's intentional since the purpose of the
> spec is to authenticate the client (or the resource owner for an
> authorization grant).
> 
> The assertion documents are used for interworking with "legacy" identity
> infrastructure (such as SAML federations).
> 
> So, are you sure you are indeed looking at the right document?
> 
> Ciao
> Hannes
> 
> 
> On 03/11/2014 03:13 PM, Antonio Sanso wrote:
>> hi *,
>> 
>> JSON Web Token (JWT) Profile section 3 [0] explicitely says 
>> 
>> The JWT MUST contain a "sub" (subject) claim 
>> 
>> 
>> Now IMHO there are cases where having the sub is either not needed or
>> redundant (since it might overlap with the issuer).\
>> 
>> As far as I can see “even Google” currently violates this spec [1] ( I
>> know that this doesn’t matter, just wanted to bring a real use case
>> scenario).
>> 
>> WDYT might the “sub” be optional in some situation?
>> 
>> regards
>> 
>> antonio 
>> 
>> [0] http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3
>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>> 
>> 
>> ___
>> 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

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

[Antonio Sanso]

On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig  
wrote:

> Thanks for clarifying.
> 
> I took a quick look at the Google API and it seems that in their use
> case the client creates the JWT and consequently the subject and the
> issue would actually be the same. I suspect that this is the reason why
> they omitted the subject.

agreed that is why in my mail I said the subject might overlap with the issuer.
The subject in the google case is still called with its obsolete name (prn) and 
it is actually listed as ‘additional claims’ hence not mandatory.

regards

antonio

> 
> Could you explain why you would like to omit the subject claim in the JWT?
> 
> Ciao
> Hannes
> 
> PS: Your feedback on the  draft-ietf-oauth-jwt-bearer-07 spec is timely
> since we are about to finish all three assertion specs.
> 
> 
> On 03/11/2014 03:56 PM, Antonio Sanso wrote:
>> hi Hannes,
>> 
>> I am aware of the 2 documents,
>> 
>> I might be wrong but 
>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also about 
>> Authorization Grant Processing (this is the part I do use in my 
>> implementation ) and not only Client Authentication Processing.
>> 
>> Just my 0.02 $ but this seems to be a place where different implementer have 
>> the same issue :)
>> 
>> regards
>> 
>> antonio
>> 
>> On Mar 11, 2014, at 3:36 PM, Hannes Tschofenig  
>> wrote:
>> 
>>> Hi Manfred, Hi Antonio,
>>> 
>>> Note that there are two documents that talk about the JWT and you guys
>>> might be looking at the wrong document.
>>> 
>>> The main JWT document (see
>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines
>>> the subject claim as optional (see Section 4.1.2).
>>> 
>>> The JWT bearer assertion document (see
>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does indeed
>>> define it as mandatory but that's intentional since the purpose of the
>>> spec is to authenticate the client (or the resource owner for an
>>> authorization grant).
>>> 
>>> The assertion documents are used for interworking with "legacy" identity
>>> infrastructure (such as SAML federations).
>>> 
>>> So, are you sure you are indeed looking at the right document?
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> 
>>> On 03/11/2014 03:13 PM, Antonio Sanso wrote:
>>>> hi *,
>>>> 
>>>> JSON Web Token (JWT) Profile section 3 [0] explicitely says 
>>>> 
>>>> The JWT MUST contain a "sub" (subject) claim 
>>>> 
>>>> 
>>>> Now IMHO there are cases where having the sub is either not needed or
>>>> redundant (since it might overlap with the issuer).\
>>>> 
>>>> As far as I can see “even Google” currently violates this spec [1] ( I
>>>> know that this doesn’t matter, just wanted to bring a real use case
>>>> scenario).
>>>> 
>>>> WDYT might the “sub” be optional in some situation?
>>>> 
>>>> regards
>>>> 
>>>> antonio 
>>>> 
>>>> [0] http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3
>>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>>> 
>>>> 
>>>> ___
>>>> 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

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

[Antonio Sanso]

Ok this is my use case:

- I  am John Doe and going to AS to register my app named app1
- I then either upload my public key or download a private key
- at this point I am ready to build my assertion, the issuer claim is going to 
be app1 and should suffice.

is the subject really needed in this use case? 

regards

antonio


On Mar 11, 2014, at 4:25 PM, John Bradley  wrote:

> The missing scheme especially on JWT issued by google is something I 
> understand they are working on but need to be careful about breaking existing 
> code, so will possibly need new endpoints that are spec compliant. 
> 
> While in this google case the subject and the issuer happen to be the same 
> they may well not be even in the self signed case.   In WG discussions being 
> consistent in providing the subject was considered to be better for 
> interoperability than optimizing for the case where sub or issuer could be 
> dropped.  
> 
> John B.
> 
> On Mar 11, 2014, at 12:05 PM, Hannes Tschofenig  
> wrote:
> 
>> Maintaining both information in the JWT is IMHO valuable since it gives
>> you some information about the security properties. Needless to say that
>> there is a substantial difference between a self-created JWT and a JWT
>> from a third party the relying party has some confidence in.
>> 
>> Why Google has an old implementation and whether they are planning to
>> update their code remains to be seen.
>> 
>> More importantly, however, is why you argue that the subject claim has
>> to be optional.
>> 
>> Ciao
>> Hannes
>> 
>> Ps: I also noticed in the examples that all URIs have their URI scheme
>> missing. While that might be OK I am not entirely sure...
>> 
>> On 03/11/2014 04:08 PM, Antonio Sanso wrote:
>>> 
>>> On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig  
>>> wrote:
>>> 
>>>> Thanks for clarifying.
>>>> 
>>>> I took a quick look at the Google API and it seems that in their use
>>>> case the client creates the JWT and consequently the subject and the
>>>> issue would actually be the same. I suspect that this is the reason why
>>>> they omitted the subject.
>>> 
>>> agreed that is why in my mail I said the subject might overlap with the 
>>> issuer.
>>> The subject in the google case is still called with its obsolete name (prn) 
>>> and it is actually listed as ‘additional claims’ hence not mandatory.
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>>> 
>>>> Could you explain why you would like to omit the subject claim in the JWT?
>>>> 
>>>> Ciao
>>>> Hannes
>>>> 
>>>> PS: Your feedback on the  draft-ietf-oauth-jwt-bearer-07 spec is timely
>>>> since we are about to finish all three assertion specs.
>>>> 
>>>> 
>>>> On 03/11/2014 03:56 PM, Antonio Sanso wrote:
>>>>> hi Hannes,
>>>>> 
>>>>> I am aware of the 2 documents,
>>>>> 
>>>>> I might be wrong but 
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also about 
>>>>> Authorization Grant Processing (this is the part I do use in my 
>>>>> implementation ) and not only Client Authentication Processing.
>>>>> 
>>>>> Just my 0.02 $ but this seems to be a place where different implementer 
>>>>> have the same issue :)
>>>>> 
>>>>> regards
>>>>> 
>>>>> antonio
>>>>> 
>>>>> On Mar 11, 2014, at 3:36 PM, Hannes Tschofenig 
>>>>>  wrote:
>>>>> 
>>>>>> Hi Manfred, Hi Antonio,
>>>>>> 
>>>>>> Note that there are two documents that talk about the JWT and you guys
>>>>>> might be looking at the wrong document.
>>>>>> 
>>>>>> The main JWT document (see
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines
>>>>>> the subject claim as optional (see Section 4.1.2).
>>>>>> 
>>>>>> The JWT bearer assertion document (see
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does indeed
>>>>>> define it as mandatory but that's intentional since the purpose of the
>>>>>> spec is to authenticate the client (or the resource owner for an
>>>>>> authorization grant).
>>>>>> 
>>>>>> T

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

[Antonio Sanso]

agree, but in some cases the subject is not only same as the issuer but simply 
it doesn’t matter.

In my example below all it matters is that the assertion signed by app1 is 
valid…. 

Continue in my probably not relevant “Google example” if I set the prn same as 
the issuer it would not work (keeping only the issuer without any subject gives 
me back a correct access token instead).

Again this is not relevant spec wise. AFIU there is consensus in the working 
group to keep the subject mandatory. Would it make sense at least to add a 
little not that in some situations the issuer and the subject are the same?
This might clarify at least something to people that do wonder...

regards

antonio

On Mar 11, 2014, at 8:12 PM, John Bradley  wrote:

> The specification is intended to allow the interoperation of standard 
> libraries.  
> 
> In some cases the subject and the iss may be the same, however the underlying 
> OAuth library may be a general one and always require a subject for security 
> processing.
> 
> It is possible that all libraries could have a special rule for when sub is 
> not present and use the value of iss as sub.  This will save some bytes in 
> the JWT but it is probably not worth creating an extra code path in libraries 
> for the size optimization. 
> 
> I don't think your saying there is no subject just that it is redundant with 
> iss in some cases.
> 
> John B.
> 
> On Mar 11, 2014, at 2:11 PM, Antonio Sanso  wrote:
> 
>> Ok this is my use case:
>> 
>> - I  am John Doe and going to AS to register my app named app1
>> - I then either upload my public key or download a private key
>> - at this point I am ready to build my assertion, the issuer claim is going 
>> to be app1 and should suffice.
>> 
>> is the subject really needed in this use case? 
>> 
>> regards
>> 
>> antonio
>> 
>> 
>> On Mar 11, 2014, at 4:25 PM, John Bradley  wrote:
>> 
>>> The missing scheme especially on JWT issued by google is something I 
>>> understand they are working on but need to be careful about breaking 
>>> existing code, so will possibly need new endpoints that are spec compliant. 
>>> 
>>> While in this google case the subject and the issuer happen to be the same 
>>> they may well not be even in the self signed case.   In WG discussions 
>>> being consistent in providing the subject was considered to be better for 
>>> interoperability than optimizing for the case where sub or issuer could be 
>>> dropped.  
>>> 
>>> John B.
>>> 
>>> On Mar 11, 2014, at 12:05 PM, Hannes Tschofenig  
>>> wrote:
>>> 
>>>> Maintaining both information in the JWT is IMHO valuable since it gives
>>>> you some information about the security properties. Needless to say that
>>>> there is a substantial difference between a self-created JWT and a JWT
>>>> from a third party the relying party has some confidence in.
>>>> 
>>>> Why Google has an old implementation and whether they are planning to
>>>> update their code remains to be seen.
>>>> 
>>>> More importantly, however, is why you argue that the subject claim has
>>>> to be optional.
>>>> 
>>>> Ciao
>>>> Hannes
>>>> 
>>>> Ps: I also noticed in the examples that all URIs have their URI scheme
>>>> missing. While that might be OK I am not entirely sure...
>>>> 
>>>> On 03/11/2014 04:08 PM, Antonio Sanso wrote:
>>>>> 
>>>>> On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig 
>>>>>  wrote:
>>>>> 
>>>>>> Thanks for clarifying.
>>>>>> 
>>>>>> I took a quick look at the Google API and it seems that in their use
>>>>>> case the client creates the JWT and consequently the subject and the
>>>>>> issue would actually be the same. I suspect that this is the reason why
>>>>>> they omitted the subject.
>>>>> 
>>>>> agreed that is why in my mail I said the subject might overlap with the 
>>>>> issuer.
>>>>> The subject in the google case is still called with its obsolete name 
>>>>> (prn) and it is actually listed as ‘additional claims’ hence not 
>>>>> mandatory.
>>>>> 
>>>>> regards
>>>>> 
>>>>> antonio
>>>>> 
>>>>>> 
>>>>>> Could you explain why you would like to omit the subject claim in the 
>>&g

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

[Antonio Sanso]

+1

thanks

antonio

On Mar 12, 2014, at 8:08 AM, Manfred Steyer  wrote:

> Hi John,
> 
> thx for this explanation. It helps me to see, why this decision has been
> made.
> 
> Wishes,
> Manfred
> 
> 
> -Ursprüngliche Nachricht-
> Von: John Bradley [mailto:ve7...@ve7jtb.com] 
> Gesendet: Dienstag, 11. März 2014 20:49
> An: Manfred Steyer
> Cc: Hannes Tschofenig; Antonio Sanso; oauth@ietf.org
> Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile
> 
> Company X will likely care about the subject being asserted by company A for
> auditing and possible revocation.
> 
> It may be that the extension claim accessLevel=Accounting is sufficient to
> grant the access token.  
> 
> By Policy A could make sub itself, or an identifier for the user of the
> client in it's namespace.  
> 
> Yes there are some cases where it may be redundant or not disclosed for a
> privacy reason, but the current decision is to keep the library consistent
> and push that decision to the application logic.
> 
> You can make the case the decision was wrong.  
> 
> The other reason for it is that the JWT and SAML assertions are parallel and
> in SAML subject is required.   That was the other consistency reason for
> making it mandatory.  
> 
> John B.
> 
> 
> On Mar 11, 2014, at 4:28 PM, Manfred Steyer  wrote:
> 
>> Hi,
>> 
>> perhaps you can show that I'm wrong, but I still think, that there are
>> cases, where the subject is unknown cause it's not relevant. Let's
> consider
>> the following federation-scenario:
>> 
>> 1. Bob has a Token T1 that says, that he works  for Company A on Project
> B.
>> The Subject of this token is "Bob".
>> 2. Company X says, that everyone in Company A working for Project B gets
>> access to Accounting-Information.
>> 3. Bob exchanges this Token T1 at Company X's AuthServer for another Token
>> T2. T2 contains a claim AccessLevel=Accouting. T2 could also get a copy of
>> the subj-claim, but Company X doesn't care about that, cause no one in
>> Company B knows Bob.
>> 
>> The only reason I can imagine, why the sub-claim should be copied into T2
> is
>> because of tracing and finding out, that there is a correlation between T2
>> und T1. But this could be accomplished with other mechanisms too.
>> 
>> Did I oversee something? If there is another reason, why sub is mandatory,
> I
>> think, it would not hurt too much to copy the sub-claim from T1 to T2 (and
>> from T2 to T3 etc.)...
>> 
>> Wishes
>> Manfred
>> 
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: OAuth [mailto:oauth-boun...@ietf.org] Im Auftrag von Hannes
> Tschofenig
>> Gesendet: Dienstag, 11. März 2014 16:05
>> An: Antonio Sanso
>> Cc: oauth@ietf.org
>> Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile
>> 
>> Maintaining both information in the JWT is IMHO valuable since it gives
> you
>> some information about the security properties. Needless to say that there
>> is a substantial difference between a self-created JWT and a JWT from a
>> third party the relying party has some confidence in.
>> 
>> Why Google has an old implementation and whether they are planning to
> update
>> their code remains to be seen.
>> 
>> More importantly, however, is why you argue that the subject claim has to
> be
>> optional.
>> 
>> Ciao
>> Hannes
>> 
>> Ps: I also noticed in the examples that all URIs have their URI scheme
>> missing. While that might be OK I am not entirely sure...
>> 
>> On 03/11/2014 04:08 PM, Antonio Sanso wrote:
>>> 
>>> On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig
> 
>> wrote:
>>> 
>>>> Thanks for clarifying.
>>>> 
>>>> I took a quick look at the Google API and it seems that in their use 
>>>> case the client creates the JWT and consequently the subject and the 
>>>> issue would actually be the same. I suspect that this is the reason 
>>>> why they omitted the subject.
>>> 
>>> agreed that is why in my mail I said the subject might overlap with the
>> issuer.
>>> The subject in the google case is still called with its obsolete name
>> (prn) and it is actually listed as 'additional claims' hence not
> mandatory.
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>>> 
>>>> Could you explain why you would like to omit the subject claim in the
>> JWT?
>>>> 
>>>> Ciao
>>>> Hannes
&g

[OAUTH-WG] JWE with A128CBC-HS256

[Antonio Sanso]

hi *,

in the JWT specification [0] there is an example of a JWE that use 
A128CBC-HS256 for content encrpyption.
Now I am not a cryptographer my self but IIUC the same CEK is used for 
encrypting with AES and authentication HMAC.

AFAIK is better to use two different keys for those 2 different primitives 
(this will not obviously apply to AES_GCM).

Unless I am missing something... :)

regards

antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#appendix-A.1
[1] 
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-24#appendix-A.2
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWE with A128CBC-HS256

[Antonio Sanso]

thanks a lot John,

On Mar 28, 2014, at 5:09 PM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

This reference may be useful to you. 
http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2

The part of the spec you need is  
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-24#page-23

We originally used a KDF as you mention.  In order to simplify the alg and 
align with draft-mcgrew-aead-aes-cbc-hmac-sha2.

K is the concatenation of the AES key and teh HMAC Key.

question,  are the examples in the spec already updated to use the new 
mechanism?
There are some obsolete references in the JWE spec. E.g. in [2] says:


as described where this algorithm is
   defined in Sections 
4.8<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-24#section-4.8>
 and 
4.8.3<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-24#section-4.8.3>
 of JWA,

These sections seems to point to on old version of the spec (Section 4.8.3 
doesn’t even exist anymore in JWA)

regards

antonio

[2] http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-24#appendix-B


John B.


On Mar 28, 2014, at 11:19 AM, Antonio Sanso 
mailto:asa...@adobe.com>> wrote:

hi *,

in the JWT specification [0] there is an example of a JWE that use 
A128CBC-HS256 for content encrpyption.
Now I am not a cryptographer my self but IIUC the same CEK is used for 
encrypting with AES and authentication HMAC.

AFAIK is better to use two different keys for those 2 different primitives 
(this will not obviously apply to AES_GCM).

Unless I am missing something... :)

regards

antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#appendix-A.1
[1] 
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-24#appendix-A.2
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Session cookies in OAuth2 flow

[Antonio Sanso]

hi Andrei,

AFAIU session cookie management is beyond the scope of the OAuth2 specification.

regards

antonio

On Apr 24, 2014, at 6:39 PM, Andrei Shakirin  wrote:

> Hi,
> 
> My name is Andrei Shakirin, I am working with OAuth2 implementation in Apache 
> CXF project.
> Could you please help me to verify my understanding regarding of using 
> session cookies in OAuth2 flow.
> OAuth2 specification mentions session cookies in:
> 1) Section 3.1. Authorization Endpoint as possible way to authenticate 
> resource owner against authorization server
> 2) Section 10.12. Cross-Site Request Forgery as possible attack where 
> end-user follows a malicious URI to a trusting server including a valid 
> session cookie
> 
> My current understanding is:
> a) using sessions between user-agent and authorization server is optional and 
> authorization server is not obligated to keep user state (in case if 
> user-agent provide authentication information with every request).
> b) in case if sessions are used (because of any reasons), authorization 
> server have to care about additional protection like hidden form fields in 
> order to uniquely identify the actual authorization request.
> 
> Is this correct?
> 
> Regards,
> Andrei.
> 
> ___
> 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

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

[Antonio Sanso]

Hi Torsten,

Adobe also  has an implementation.

regards

antonio

On Apr 25, 2014, at 7:26 AM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:

Deutsche Telekom also has an implementation.

regards,
Torsten.


 Ursprüngliche Nachricht 
Von: Chuck Mortimore
Datum:25.04.2014 01:31 (GMT+01:00)
An: Mike Jones
Cc: oauth@ietf.org
Betreff: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Salesforce Implementation: 
https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm&language=en_US


On Thu, Apr 24, 2014 at 3:41 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
I am aware of these implementations:
Microsoft Azure Active Directory:  
http://azure.microsoft.com/en-us/services/active-directory/
Google Service Account: 
https://developers.google.com/accounts/docs/OAuth2ServiceAccount

I believe that Ping Identity and Salesforce also have implementations, but I'll 
let Brian and Chuck authoritatively speak to those.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of Hannes Tschofenig
Sent: Wednesday, April 23, 2014 1:40 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Hi all,

I am working on the shepherd writeup for the JWT bearer document. The shepherd 
write-ups for the assertion draft and the SAML bearer document have been 
completed a while ago already, see 
http://www.ietf.org/mail-archive/web/oauth/current/msg12410.html

A few requests:

- To the document authors: Please confirm that any and all appropriate IPR 
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed.

- To all: Are you aware of implementations of this specification? If so, I 
would like to reference them in my write-up.

- To all: Please also go through the text to make sure that I correctly reflect 
the history and the status of this document.

Here is the most recent version of the write-up:
https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/shepherd-writeups/Writeup_OAuth_JWT-Assertion-Profile.txt


(The copy-and-paste of the full version is below.)

Ciao
Hannes

PS: Note that I have send a mail about a pending issue to the list. In response 
to my question I will update the write-up accordingly.



Writeup for "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication 
and Authorization Grants" 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet 
Standard, Informational, Experimental, or Historic)? Why is this the proper 
type of RFC? Is this type of RFC indicated in the title page header?

The RFC type is 'Standards Track' and the type is indicated in the title page. 
This document defines an instantiation for the OAuth assertion framework using 
JSON Web Tokens.

(2) The IESG approval announcement includes a Document Announcement Write-Up. 
Please provide such a Document Announcement Write-Up. Recent examples can be 
found in the "Action" announcements for approved documents. The approval 
announcement contains the following sections:

Technical Summary:

   This specification defines the use of a JSON Web Token (JWT) Bearer
   Token as a means for requesting an OAuth 2.0 access token as well as
   for use as a means of client authentication.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there 
controversy about particular points or were there decisions where the consensus 
was particularly rough?

This document belongs to the OAuth assertion document bundle consisting of the 
abstract OAuth assertion framework, and the SAML assertion profile. Due to the 
use of the JSON-based encoding of the assertion it also relies on the work in 
the JOSE working group (such as JWE/JWS) indirectly through the use of the JWT. 
This document has intentionally been kept in sync with the SAML-based version.

Document Quality:

This document has gone through many iterations and has received substantial 
feedback.

[[Add implementation list here.]]

Personnel:

The document shepherd is Hannes Tschofenig and the responsible area director is 
Kathleen Moriarty.

(3) Briefly describe the review of this document that was performed by the 
Document Shepherd. If this version of the document is not ready for 
publication, please explain why the document is being forwarded to the IESG.

The draft authors believe that this document is ready for publication.
The document has had received review comments from working group members, and 
from the OAuth working group chairs. These review comments have been taken into 
account.

(4) Does the document Shepherd have any concerns about the depth or breadth of 
the reviews that have been performed?

This document has gotten feedback from the working group and given the focused 
use cases 

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 - Examples

[Antonio Sanso]

hi Hannes.


On Apr 25, 2014, at 12:37 PM, Hannes Tschofenig  
wrote:

> Hi all,
> 
> As a document shepherd I have to verify the entire document and this
> includes the examples as well.
> 
> Section 3.1:
> 
> You write:
> 
> "
>   The following octet sequence is the UTF-8 representation of the JWT
>   Header/JWS Header above:
> 
>   [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
>   34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
> "
> 
> The values IMHO are represented in Decimal code point rather than Octal
> UTF-8 bytes, as stated above.
> See the following online tool to see the difference:
> http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=%22&mode=char
> 
> Note that you could also show a hex encoding instead (e.g., via
> http://ostermiller.org/calc/encode.html). Hixie's decoder would then
> produce the correct decoding. Here is the link to his software:
> http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder
> (Note that this program seems to have flaws for most other options.)
> 
> When do a Base64URL encoding of
> 
> {"typ":"JWT","alg":"HS256"}
> 
> then I get
> 
> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
> 
> but your spec says:
> 
> eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
> 
> Same with {"iss":"joe","exp":1300819380,"http://example.com/is_root":true}.
> 
> My result:
> eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
> 
> Your result:
> eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

see http://www.ietf.org/mail-archive/web/oauth/current/msg11599.html

regards

antonio

> 
> Note: I am using this online tool for Base64URL encoding:
> http://kjur.github.io/jsjws/tool_b64uenc.html.
> Interestingly, when I dump the data into http://jwt.io/ then I get a
> correct decoding. It might well be that the kjur.github.io has a flaw.
> 
> Just wanted to check what tool you have used to create these encodings.
> 
> 
> Section 6.1:
> 
> The example in Section 6.1 is the same as in 3.1. Maybe it would be
> useful to show something different here.
> 
> The example in Appendix A.1 is more sophisticated since it demonstrates
> encryption. To verify it I would need to have a library that supports
> JWE and RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256. Which library
> have you been using?
> 
> I was wondering whether it would make sense to add two other examples,
> namely for integrity protection. One example showing an HMAC-based keyed
> message digest and another one using a digital signature.
> 
> Here is a simple example to add that almost all JWT libraries seem to be
> able to create and verify:
> 
> Header:
> {"alg":"HS256","typ":"JWT"}
> 
> I use the HS256 algorithm with a shared secret '12345'.
> 
> Body:
> 
> {"iss":"https://as.example.com","sub":"mailto:j...@example.com","nbf":1398420753,"exp":1398424353,"iat":1398420753}
> 
> jwt.encode({"iss":"https://as.example.com","sub":"mailto:j...@example.com","nbf":1398420753,"exp":1398424353,"iat":1398420753},"12345";,
> "HS256")
> 
> I used http://www.onlineconversion.com/unix_time.htm to create the
> date/time values:
> "nbf":1398420753 --> Fri, 25 Apr 2014 10:12:33 GMT
> "exp":1398424353 --> Fri, 25 Apr 2014 11:12:33 GMT
> "iat":1398420753 --> Fri, 25 Apr 2014 10:12:33 GMT
> 
> Here is the output created with https://github.com/progrium/pyjwt/ and
> verified with http://jwt.io/:
> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tIiwiaWF0IjoxMzk4NDIwNzUzLCJzdWIiOiJtYWlsdG86am9obkBleGFtcGxlLmNvbSIsImV4cCI6MTM5ODQyNDM1MywibmJmIjoxMzk4NDIwNzUzfQ.0gfRUIley70bMP7hN6sMWkHwHezdrv2E1LAVcNdTsq4
> 
> Ciao
> Hannes
> 
> 
> ___
> 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

Re: [OAUTH-WG] JWT and JOSE have won a Special European Identity Award

[Antonio Sanso]

nice one Mike et al!!

well deserved!

regards

antonio

On May 14, 2014, at 8:19 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE) 
specifications were granted a Special European Identity Award for Best 
Innovation for Security in the API Economy.  I was honored to accept the award, 
along with Nat Sakimura and John Bradley, on behalf of the contributors to and 
implementers of these specifications at the European Identity and Cloud 
Conference.

It’s great to see this recognition for the impact that these specs are having 
by making it easy to use simple JSON-based security tokens and other 
Web-friendly cryptographically protected data structures.  Special thanks are 
due to all of you have built and deployed implementations and provided feedback 
on the specs throughout their development; they significantly benefitted from 
your active involvement!

These specifications are:
•JSON Web Token 
(JWT)
•JSON Web Signature 
(JWS)
•JSON Web Encryption 
(JWE)
•JSON Web Key 
(JWK)
•JSON Web Algorithms 
(JWA)

The authors are:
•John Bradley
•Joe Hildebrand
•Michael B. Jones
•Nat Sakimura

Dirk Balfanz, Yaron 
Goland, John 
Panzer, and Eric 
Rescorla also deserve thanks for their significant 
contributions to creating these specifications.

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1223 and as 
@selfissued.

___
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

[OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]


If the request fails due to a missing, invalid, or mismatching
   redirection URI, or if the client identifier is missing or invalid,
   the authorization server SHOULD inform the resource owner of the
   error and MUST NOT automatically redirect the user-agent to the
   invalid redirection URI.

   If the resource owner denies the access request or if the request
   fails for reasons other than a missing or invalid redirection URI,
   the authorization server informs the client by adding the following
   parameters to the query component of the redirection URI using the
   "application/x-www-form-urlencoded" format, per Appendix 
B:

Now let’s assume this.
I am registering a new client to the victim.com provider.
I register redirect uri attacker.com.

According to [0] if I pass e.g. the wrong scope I am redirected back to 
attacker.com.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this doesn’t 
apply since the resource owner MUST approve the app via the consent screen (at 
least once).

A solution would be to return error 400 rather than redirect to the redirect 
URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

On Sep 3, 2014, at 6:10 PM, Bill Burke 
mailto:bbu...@redhat.com>> wrote:

I don't understand.  The redirect uri has to be valid in order for a redirect 
to happen.  The spec explicitly states this.

the redirect uri is indeed valid. The wrong parameter is the scope.

So if the attacker is the person that registers the app and register as 
redirect uri attacker.com<http://attacker.com> he can redirect anybody to 
attacker.com<http://attacker.com> levering the provider website uri…



On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
   redirection URI, or if the client identifier is missing or invalid,
   the authorization server SHOULD inform the resource owner of the
   error and MUST NOT automatically redirect the user-agent to the
   invalid redirection URI.

   If the resource owner denies the access request or if the request
   fails for reasons other than a missing or invalid redirection URI,
   the authorization server informs the client by adding the following
   parameters to the query component of the redirection URI using the
   "application/x-www-form-urlencoded" format, perAppendix B  
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to the victim.com<http://victim.com/> 
<http://victim.com<http://victim.com/>>
provider.
I register redirect uri attacker.com<http://attacker.com/> 
<http://attacker.com<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com<http://attacker.com/> <http://attacker.com<http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn’t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<http://bill.burkecentral.com/>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

In the example the redirect_uri is vlid for the attacker.

The issue is that the AS may be allowing client registrations with arbitrary 
redirect_uri.

In the spec it is unspecified how a AS validates that a client controls the 
redirect_uri it is registering.

I think that if anything it may be the registration step that needs the 
security consideration.

(this is the first time :p) but I do disagree with you. It would be pretty 
unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely returning 400 with 
the cause of the error..


400. That’s an error.

Error: invalid_scope

Some requested scopes were invalid. {invalid=[l]}

said that I hope you all agree this is an issue in the spec so far….

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke 
mailto:bbu...@redhat.com>> wrote:

I don't understand.  The redirect uri has to be valid in order for a redirect 
to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
  redirection URI, or if the client identifier is missing or invalid,
  the authorization server SHOULD inform the resource owner of the
  error and MUST NOT automatically redirect the user-agent to the
  invalid redirection URI.

  If the resource owner denies the access request or if the request
  fails for reasons other than a missing or invalid redirection URI,
  the authorization server informs the client by adding the following
  parameters to the query component of the redirection URI using the
  "application/x-www-form-urlencoded" format, perAppendix B  
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to the victim.com<http://victim.com> 
<http://victim.com>
provider.
I register redirect uri attacker.com<http://attacker.com> <http://attacker.com>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com<http://attacker.com> <http://attacker.com>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn’t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>> wrote:

Let me try and approach this from a different angle: why would you call it an 
open redirect when an invalid scope is provided and call it correct protocol 
behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope is 
provided) the resource owner MUST approve the app via the consent screen (at 
least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley 
mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>> wrote:

In the example the redirect_uri is vlid for the attacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That’s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=[l]}

said that I hope you all agree this is an issue in the spec so far….

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke 
mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>> wrote:

I don't understand.  The redirect uri has to be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
 redirection URI, or if the client identifier is missing or invalid,
 the authorization server SHOULD inform the resource owner of the
 error and MUST NOT automatically redirect the user-agent to the
 invalid redirection URI.

 If the resource owner denies the access request or if the request
 fails for reasons other than a missing or invalid redirection URI,
 the authorization server informs the client by adding the following
 parameters to the query component of the redirection URI using the
 "application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to the victim.com<http://victim.com/> 
<http://victim.com<http://victim.com/>>
<http://victim.com<http://victim.com/>>
provider.
I register redirect uri attacker.com<http://attacker.com/> 
<http://attacker.com<http://attacker.com/>>
<http://attacker.com<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com<http://attacker.com/> <http://attacker.com<http://attacker.com/>> 
<http://attacker.com<http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn’t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


--
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com<mailto:hzandb...@pingidentity.com> | Ping Identity

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt  wrote:

> Is your concern clients that were registered using dynamic client 
> registration?

yes

> 
> Otherwise the positive case is returning a response to a valid URL that 
> belongs to a client that was registered explicitly by the resource owner

well AFAIK the resource owner doesn’t register clients…


> and the negative case is returning an error to that same URL.

the difference is the consent screen… in the positive case you need to approve 
an app.. for the error case no approval is needed,,,

> 
> I fail to see the open redirect.

why?

> 
> Hans.
> 
> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>> 
>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > <mailto:hzandb...@pingidentity.com>> wrote:
>> 
>>> Let me try and approach this from a different angle: why would you
>>> call it an open redirect when an invalid scope is provided and call it
>>> correct protocol behavior (hopefully) when a valid scope is provided?
>> 
>> as specified below in the positive case (namely when the correct scope
>> is provided) the resource owner MUST approve the app via the consent
>> screen (at least once).
>> 
>> 
>>> 
>>> Hans.
>>> 
>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>> hi John,
>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>> <mailto:ve7...@ve7jtb.com>
>>>> <mailto:ve7...@ve7jtb.com>> wrote:
>>>> 
>>>>> In the example the redirect_uri is vlid for the attacker.
>>>>> 
>>>>> The issue is that the AS may be allowing client registrations with
>>>>> arbitrary redirect_uri.
>>>>> 
>>>>> In the spec it is unspecified how a AS validates that a client
>>>>> controls the redirect_uri it is registering.
>>>>> 
>>>>> I think that if anything it may be the registration step that needs
>>>>> the security consideration.
>>>> 
>>>> (this is the first time :p) but I do disagree with you. It would be
>>>> pretty unpractical to block this at registration time….
>>>> IMHO the best approach is the one taken from Google, namely returning
>>>> 400 with the cause of the error..
>>>> 
>>>> *400.* That’s an error.
>>>> 
>>>> *Error: invalid_scope*
>>>> 
>>>> Some requested scopes were invalid. {invalid=[l]}
>>>> 
>>>> said that I hope you all agree this is an issue in the spec so far….
>>>> 
>>>> regards
>>>> 
>>>> antonio
>>>> 
>>>>> 
>>>>> John B.
>>>>> 
>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>> <mailto:bbu...@redhat.com>
>>>>> <mailto:bbu...@redhat.com>> wrote:
>>>>> 
>>>>>> I don't understand.  The redirect uri has to be valid in order for a
>>>>>> redirect to happen.  The spec explicitly states this.
>>>>>> 
>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote:
>>>>>>> hi *,
>>>>>>> 
>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to open
>>>>>>> redirect.
>>>>>>> Let me explain, reading [0]
>>>>>>> 
>>>>>>> If the request fails due to a missing, invalid, or mismatching
>>>>>>> redirection URI, or if the client identifier is missing or invalid,
>>>>>>> the authorization server SHOULD inform the resource owner of the
>>>>>>> error and MUST NOT automatically redirect the user-agent to the
>>>>>>> invalid redirection URI.
>>>>>>> 
>>>>>>> If the resource owner denies the access request or if the request
>>>>>>> fails for reasons other than a missing or invalid redirection URI,
>>>>>>> the authorization server informs the client by adding the following
>>>>>>> parameters to the query component of the redirection URI using the
>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B
>>>>>>> <https://tools.ietf.org/html/rfc6749#appendix-B>:
>>>>>>> 
>>>>>>> Now let’s assume this.
>>>>>>> I am registering a new client to thevictim.com
>>>>>>> <http:/

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

Well,
I do not know if this is only dynamic registration...
let’s talk about real use cases, namely e.g. Google , Facebook , etc.. is that 
dynamic client registration? I do not know… :)

Said that what the other guys think?  :)
Would this deserve some “spec adjustment” ? I mean there is a reason if Google 
is by choice “violating” the spec right? (I assume to avoid open redirect…)
But other implementers do follow the spec hence they have this open redirector… 
and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>> wrote:

On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>> wrote:

Is your concern clients that were registered using dynamic client registration?

yes

I think your issue is then with the trust model of dynamic client registration; 
that is left out of scope of the dynreg spec (and the concept is not even part 
of the core spec), but unless you want everything to be open (which typically 
would not be the case), then it would involve approval somewhere in the process 
before the client is registered. Without dynamic client registration that 
approval is admin based or resource owner based, depending on use case.

Otherwise the positive case is returning a response to a valid URL that belongs 
to a client that was registered explicitly by the resource owner

well AFAIK the resource owner doesn’t register clients…

roles can collapse in use cases especially when using dynamic client 
registration

and the negative case is returning an error to that same URL.

the difference is the consent screen… in the positive case you need to approve 
an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly approved at some point

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>
<mailto:hzandb...@pingidentity.com>> wrote:

Let me try and approach this from a different angle: why would you
call it an open redirect when an invalid scope is provided and call it
correct protocol behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley 
mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>> wrote:

In the example the redirect_uri is vlid for the attacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That’s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=[l]}

said that I hope you all agree this is an issue in the spec so far….

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke 
mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>> wrote:

I don't understand.  The redirect uri has to be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to thevictim.com<http://thevictim.com>
<http://victim.com/><http://victim.com <http://victim.com/>>
<http://victim.com <http://victim.com/>>
provider.
I register redirect uriattacker.com<http://uriattacker.com>
<http://attacker.com/><http://attacker.com <http://attacker.com/>>
<http://attacker.com <http://atta

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Phil,
can you point out the relative paragraph that covers this specific case in 
RFC6819?
On Sep 3, 2014, at 9:23 PM, Phil Hunt  wrote:

> I do not believe this is a flaw specific to 6749. The flaw if any is within 
> HTTP itself (RFC7230). Covert redirect is a well known problem. There are 
> extensive recommendations that prevent this covered in 6749 and 6819.
> 
> There is no protocol fix that OAuth can make since it is a trait or feature 
> of HTTP.
> 
> Instead we’ve made security recommendations which are the appropriate 
> response to this issue. Further we published 6819 that provides further 
> guidance.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt  wrote:
> 
>> fine, you're talking security considerations about untrusted clients; that's 
>> a different use case than the protocol flaw reason why Google would not do 
>> rfc6749 as written
>> 
>> Hans.
>> 
>> On 9/3/14, 7:52 PM, John Bradley wrote:
>>> I agree that the error case where there is no UI is the problem, as it can 
>>> be used inside a Iframe.
>>> 
>>> However error responses are generally useful.
>>> 
>>> OAuth core is silent on how redirect_uri are registered and if they are 
>>> verified.
>>> 
>>> Dynamic registration should warn about OAuth errors to redirect_uri from 
>>> untrusted clients.
>>> 
>>> For other registration methods we should update the RFC.
>>> 
>>> John B.
>>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso  wrote:
>>>> 
>>>> 
>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt  
>>>>> wrote:
>>>>> 
>>>>> Is your concern clients that were registered using dynamic client 
>>>>> registration?
>>>> 
>>>> yes
>>>> 
>>>>> 
>>>>> Otherwise the positive case is returning a response to a valid URL that 
>>>>> belongs to a client that was registered explicitly by the resource owner
>>>> 
>>>> well AFAIK the resource owner doesn’t register clients…
>>>> 
>>>> 
>>>>> and the negative case is returning an error to that same URL.
>>>> 
>>>> the difference is the consent screen… in the positive case you need to 
>>>> approve an app.. for the error case no approval is needed,,,
>>>> 
>>>>> 
>>>>> I fail to see the open redirect.
>>>> 
>>>> why?
>>>> 
>>>>> 
>>>>> Hans.
>>>>> 
>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>> 
>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>> <mailto:hzandb...@pingidentity.com>> wrote:
>>>>>> 
>>>>>>> Let me try and approach this from a different angle: why would you
>>>>>>> call it an open redirect when an invalid scope is provided and call it
>>>>>>> correct protocol behavior (hopefully) when a valid scope is provided?
>>>>>> 
>>>>>> as specified below in the positive case (namely when the correct scope
>>>>>> is provided) the resource owner MUST approve the app via the consent
>>>>>> screen (at least once).
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Hans.
>>>>>>> 
>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>>> hi John,
>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>> <mailto:ve7...@ve7jtb.com>
>>>>>>>> <mailto:ve7...@ve7jtb.com>> wrote:
>>>>>>>> 
>>>>>>>>> In the example the redirect_uri is vlid for the attacker.
>>>>>>>>> 
>>>>>>>>> The issue is that the AS may be allowing client registrations with
>>>>>>>>> arbitrary redirect_uri.
>>>>>>>>> 
>>>>>>>>> In the spec it is unspecified how a AS validates that a client
>>>>>>>>> controls the redirect_uri it is registering.
>>>>>>>>> 
>>>>>>>>> I think that if anything it may be the regist

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Takahiko

On Sep 3, 2014, at 9:33 PM, Takahiko Kawasaki 
mailto:daru...@gmail.com>> wrote:

I think the point is that the registered redirect URI is evil, meaning that the 
person who registered the client application is evil. I don't think the spec 
can take any countermeasure against this case.

If the registered redirect URI is evil, the issue happens even in the case 
where the scope is valid and consent from the end-user has been obtained.

well in this case the consent screen is there …. in the case I pointed out the 
redirect happens automatically

That is, an attacker would prepare an HTML page at 
http://attacker.com<http://attacker.com/> which says "Sorry, an error occurred. 
Please re-authorize this application." and has a login form that mimics the 
login form of victim.com<http://victim.com/>.

IMHO, all we can do is to educate people like "Be cautious when you are 
requested to login again.”

this is another case different from a normal open redirect IMHO


Best Regards,
Takahiko Kawasaki


2014-09-04 4:23 GMT+09:00 Phil Hunt 
mailto:phil.h...@oracle.com>>:
I do not believe this is a flaw specific to 6749. The flaw if any is within 
HTTP itself (RFC7230). Covert redirect is a well known problem. There are 
extensive recommendations that prevent this covered in 6749 and 6819.

There is no protocol fix that OAuth can make since it is a trait or feature of 
HTTP.

Instead we’ve made security recommendations which are the appropriate response 
to this issue. Further we published 6819 that provides further guidance.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>



On Sep 3, 2014, at 11:42 AM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>> wrote:

> fine, you're talking security considerations about untrusted clients; that's 
> a different use case than the protocol flaw reason why Google would not do 
> rfc6749 as written
>
> Hans.
>
> On 9/3/14, 7:52 PM, John Bradley wrote:
>> I agree that the error case where there is no UI is the problem, as it can 
>> be used inside a Iframe.
>>
>> However error responses are generally useful.
>>
>> OAuth core is silent on how redirect_uri are registered and if they are 
>> verified.
>>
>> Dynamic registration should warn about OAuth errors to redirect_uri from 
>> untrusted clients.
>>
>> For other registration methods we should update the RFC.
>>
>> John B.
>>
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso 
>>> mailto:asa...@adobe.com>> wrote:
>>>
>>>
>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt 
>>>> mailto:hzandb...@pingidentity.com>> wrote:
>>>>
>>>> Is your concern clients that were registered using dynamic client 
>>>> registration?
>>>
>>> yes
>>>
>>>>
>>>> Otherwise the positive case is returning a response to a valid URL that 
>>>> belongs to a client that was registered explicitly by the resource owner
>>>
>>> well AFAIK the resource owner doesn’t register clients…
>>>
>>>
>>>> and the negative case is returning an error to that same URL.
>>>
>>> the difference is the consent screen… in the positive case you need to 
>>> approve an app.. for the error case no approval is needed,,,
>>>
>>>>
>>>> I fail to see the open redirect.
>>>
>>> why?
>>>
>>>>
>>>> Hans.
>>>>
>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>
>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt 
>>>>> mailto:hzandb...@pingidentity.com>
>>>>> <mailto:hzandb...@pingidentity.com<mailto:hzandb...@pingidentity.com>>> 
>>>>> wrote:
>>>>>
>>>>>> Let me try and approach this from a different angle: why would you
>>>>>> call it an open redirect when an invalid scope is provided and call it
>>>>>> correct protocol behavior (hopefully) when a valid scope is provided?
>>>>>
>>>>> as specified below in the positive case (namely when the correct scope
>>>>> is provided) the resource owner MUST approve the app via the consent
>>>>> screen (at least once).
>>>>>
>>>>>
>>>>>>
>>>>>> Hans.
>>>>>>
>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>> hi John,
>>>

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

thanks Phil for pointing the sections out but reading them I still think the 
case I brought up is still a different one :)
On Sep 3, 2014, at 9:49 PM, Phil Hunt  wrote:

> ooops,, that 6819 not 6810
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Sep 3, 2014, at 12:47 PM, Phil Hunt  wrote:
> 
>> in RFC6810, see section 3.5 and 4.1.5. 
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>> 
>> 
>> On Sep 3, 2014, at 12:36 PM, Antonio Sanso  wrote:
>> 
>>> hi Phil,
>>> can you point out the relative paragraph that covers this specific case in 
>>> RFC6819?
>>> On Sep 3, 2014, at 9:23 PM, Phil Hunt  wrote:
>>> 
>>>> I do not believe this is a flaw specific to 6749. The flaw if any is 
>>>> within HTTP itself (RFC7230). Covert redirect is a well known problem. 
>>>> There are extensive recommendations that prevent this covered in 6749 and 
>>>> 6819.
>>>> 
>>>> There is no protocol fix that OAuth can make since it is a trait or 
>>>> feature of HTTP.
>>>> 
>>>> Instead we’ve made security recommendations which are the appropriate 
>>>> response to this issue. Further we published 6819 that provides further 
>>>> guidance.
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> phil.h...@oracle.com
>>>> 
>>>> 
>>>> 
>>>> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt  
>>>> wrote:
>>>> 
>>>>> fine, you're talking security considerations about untrusted clients; 
>>>>> that's a different use case than the protocol flaw reason why Google 
>>>>> would not do rfc6749 as written
>>>>> 
>>>>> Hans.
>>>>> 
>>>>> On 9/3/14, 7:52 PM, John Bradley wrote:
>>>>>> I agree that the error case where there is no UI is the problem, as it 
>>>>>> can be used inside a Iframe.
>>>>>> 
>>>>>> However error responses are generally useful.
>>>>>> 
>>>>>> OAuth core is silent on how redirect_uri are registered and if they are 
>>>>>> verified.
>>>>>> 
>>>>>> Dynamic registration should warn about OAuth errors to redirect_uri from 
>>>>>> untrusted clients.
>>>>>> 
>>>>>> For other registration methods we should update the RFC.
>>>>>> 
>>>>>> John B.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt  
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Is your concern clients that were registered using dynamic client 
>>>>>>>> registration?
>>>>>>> 
>>>>>>> yes
>>>>>>> 
>>>>>>>> 
>>>>>>>> Otherwise the positive case is returning a response to a valid URL 
>>>>>>>> that belongs to a client that was registered explicitly by the 
>>>>>>>> resource owner
>>>>>>> 
>>>>>>> well AFAIK the resource owner doesn’t register clients…
>>>>>>> 
>>>>>>> 
>>>>>>>> and the negative case is returning an error to that same URL.
>>>>>>> 
>>>>>>> the difference is the consent screen… in the positive case you need to 
>>>>>>> approve an app.. for the error case no approval is needed,,,
>>>>>>> 
>>>>>>>> 
>>>>>>>> I fail to see the open redirect.
>>>>>>> 
>>>>>>> why?
>>>>>>> 
>>>>>>>> 
>>>>>>>> Hans.
>>>>>>>> 
>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>>>>> 
>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>> <mailto:

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi again *,

after thinking a bit further IMHO an alternative for the untrusted clients can 
also be to always present the consent screen (at least once) before any 
redirect.
Namely all providers I have seen show the consent screen if all the request 
parameters are correct and if the user accepts the redirect happens.
If one of the parameter  (with the exclusion of the client id and redirect uri 
that are handled differently as for spec) is wrong though the redirect happens 
without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso 
mailto:asa...@adobe.com>> wrote:

Well,
I do not know if this is only dynamic registration...
let’s talk about real use cases, namely e.g. Google , Facebook , etc.. is that 
dynamic client registration? I do not know… :)

Said that what the other guys think?  :)
Would this deserve some “spec adjustment” ? I mean there is a reason if Google 
is by choice “violating” the spec right? (I assume to avoid open redirect…)
But other implementers do follow the spec hence they have this open redirector… 
and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>> wrote:

On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>> wrote:

Is your concern clients that were registered using dynamic client registration?

yes

I think your issue is then with the trust model of dynamic client registration; 
that is left out of scope of the dynreg spec (and the concept is not even part 
of the core spec), but unless you want everything to be open (which typically 
would not be the case), then it would involve approval somewhere in the process 
before the client is registered. Without dynamic client registration that 
approval is admin based or resource owner based, depending on use case.

Otherwise the positive case is returning a response to a valid URL that belongs 
to a client that was registered explicitly by the resource owner

well AFAIK the resource owner doesn’t register clients…

roles can collapse in use cases especially when using dynamic client 
registration

and the negative case is returning an error to that same URL.

the difference is the consent screen… in the positive case you need to approve 
an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly approved at some point

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>
<mailto:hzandb...@pingidentity.com>> wrote:

Let me try and approach this from a different angle: why would you
call it an open redirect when an invalid scope is provided and call it
correct protocol behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley 
mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>> wrote:

In the example the redirect_uri is vlid for the attacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That’s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=[l]}

said that I hope you all agree this is an issue in the spec so far….

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke 
mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>> wrote:

I don't understand.  The redirect uri has to be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the follo

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

Hi Hans,

I really fail to see how this can be addressed at registration time for cases 
where registration is unrestricted (namely all the big Providers)

regards

antonio

On Sep 4, 2014, at 9:47 AM, Hans Zandbelt  wrote:

> Classifying like this must also mean that consent should not be stored until 
> the client is considered (admin) trusted, and admin policy would interfere 
> with user policy.
> 
> IMHO the security consideration would apply only to dynamically registered 
> clients where registration is unrestricted; any other form would involve some 
> form of admin/user approval at registration time, overcoming the concern at 
> authorization time: there's no auto-redirect flow possible for unknown 
> clients.
> 
> Hans.
> 
> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>> I think this advice isn't a bad idea, though it's of course up to the AS
>> what an "untrusted" client really is. In practice, this is something
>> that was registered by a non-sysadmin type person, either a dynamically
>> registered client or something available through self-service
>> registration of some type. It's also reasonable that a client, even
>> dynamically registered, would be considered "trusted" if enough time has
>> passed and enough users have used it without things blowing up.
>> 
>>  -- Justin
>> 
>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso > <mailto:asa...@adobe.com>> wrote:
>> 
>>> hi again *,
>>> 
>>> after thinking a bit further IMHO an alternative for the untrusted
>>> clients can also be to always present the consent screen (at least
>>> once) before any redirect.
>>> Namely all providers I have seen show the consent screen if all the
>>> request parameters are correct and if the user accepts the redirect
>>> happens.
>>> If one of the parameter  (with the exclusion of the client id and
>>> redirect uri that are handled differently as for spec) is wrong though
>>> the redirect happens without the consent screen being shown..
>>> 
>>> WDYT?
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >> <mailto:asa...@adobe.com>> wrote:
>>> 
>>>> Well,
>>>> I do not know if this is only dynamic registration...
>>>> let’s talk about real use cases, namely e.g. Google , Facebook ,
>>>> etc.. is that dynamic client registration? I do not know… :)
>>>> 
>>>> Said that what the other guys think?  :)
>>>> Would this deserve some “spec adjustment” ? I mean there is a reason
>>>> if Google is by choice “violating” the spec right? (I assume to avoid
>>>> open redirect…)
>>>> But other implementers do follow the spec hence they have this open
>>>> redirector… and this is not nice IMHO...
>>>> 
>>>> 
>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>> <mailto:hzandb...@pingidentity.com>> wrote:
>>>> 
>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote:
>>>>>> 
>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
>>>>>> mailto:hzandb...@pingidentity.com>> wrote:
>>>>>> 
>>>>>>> Is your concern clients that were registered using dynamic client
>>>>>>> registration?
>>>>>> 
>>>>>> yes
>>>>> 
>>>>> I think your issue is then with the trust model of dynamic client
>>>>> registration; that is left out of scope of the dynreg spec (and the
>>>>> concept is not even part of the core spec), but unless you want
>>>>> everything to be open (which typically would not be the case), then
>>>>> it would involve approval somewhere in the process before the client
>>>>> is registered. Without dynamic client registration that approval is
>>>>> admin based or resource owner based, depending on use case.
>>>>> 
>>>>>>> Otherwise the positive case is returning a response to a valid URL
>>>>>>> that belongs to a client that was registered explicitly by the
>>>>>>> resource owner
>>>>>> 
>>>>>> well AFAIK the resource owner doesn’t register clients…
>>>>> 
>>>>> roles can collapse in use cases especially when using dynamic client
>>>>> registration
>>>>> 
>>>>>>> and the negative case is returning a

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Hans

On Sep 4, 2014, at 10:58 AM, Hans Zandbelt  wrote:

> Agreed, I see you point about the big providers using exactly the 
> unrestricted flow for which the trust model (by definition) is out of scope 
> of the spec. This may be the reason for the implemented behavior indeed and a 
> security consideration is a good idea for other deployments; there's not much 
> more that can be done.
> 
> But Google also provides explicit registration for API clients (which is 
> where my mind was):
> https://developers.google.com/accounts/docs/OAuth2 (step 1)
> and they would not need to deviate from the spec for that, nor would the spec 
> need to change

I do really struggle to understand your point here :) (at least the "nor would 
the spec need to change part" :)).

Probably I need to explain myself better.
Since Google is “safe” (due the “deviation” from the spec) I would take Google 
as example here (I could point out open redirector in the wild to proof my 
point but I will not do…)

Let’s start from scratch…

If Google would have something like http://www.google.com?goto=attacker.com 
this is without any doubt an open redirector… see  also OWASP 10 [0].

Now if Google would have implemented the spec rfc6749 verbatim something like 

https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

would have redirect to http://attacker.com.

So why this is not an open redirect ? :)

Now maybe we are saying the same thing but I felt like better explain my point 
:)

regards

antonio

[0] 
https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards


> 
> Hans.
> 
> On 9/4/14, 9:50 AM, Antonio Sanso wrote:
>> Hi Hans,
>> 
>> I really fail to see how this can be addressed at registration time for 
>> cases where registration is unrestricted (namely all the big Providers)
>> 
>> regards
>> 
>> antonio
>> 
>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt  wrote:
>> 
>>> Classifying like this must also mean that consent should not be stored 
>>> until the client is considered (admin) trusted, and admin policy would 
>>> interfere with user policy.
>>> 
>>> IMHO the security consideration would apply only to dynamically registered 
>>> clients where registration is unrestricted; any other form would involve 
>>> some form of admin/user approval at registration time, overcoming the 
>>> concern at authorization time: there's no auto-redirect flow possible for 
>>> unknown clients.
>>> 
>>> Hans.
>>> 
>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>>>> I think this advice isn't a bad idea, though it's of course up to the AS
>>>> what an "untrusted" client really is. In practice, this is something
>>>> that was registered by a non-sysadmin type person, either a dynamically
>>>> registered client or something available through self-service
>>>> registration of some type. It's also reasonable that a client, even
>>>> dynamically registered, would be considered "trusted" if enough time has
>>>> passed and enough users have used it without things blowing up.
>>>> 
>>>>  -- Justin
>>>> 
>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>> <mailto:asa...@adobe.com>> wrote:
>>>> 
>>>>> hi again *,
>>>>> 
>>>>> after thinking a bit further IMHO an alternative for the untrusted
>>>>> clients can also be to always present the consent screen (at least
>>>>> once) before any redirect.
>>>>> Namely all providers I have seen show the consent screen if all the
>>>>> request parameters are correct and if the user accepts the redirect
>>>>> happens.
>>>>> If one of the parameter  (with the exclusion of the client id and
>>>>> redirect uri that are handled differently as for spec) is wrong though
>>>>> the redirect happens without the consent screen being shown..
>>>>> 
>>>>> WDYT?
>>>>> 
>>>>> regards
>>>>> 
>>>>> antonio
>>>>> 
>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>> <mailto:asa...@adobe.com>> wrote:
>>>>> 
>>>>>> Well,
>>>>>> I do not know if this is only dynamic registration...
>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook ,
>>>>>> etc.. is

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

I registered via the Google Developers Console [0]  :)

[0] https://console.developers.google.com/project
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt 
mailto:hzandb...@pingidentity.com>> wrote:

Maybe just to clarify my point: where did the client_id in the example that you 
gave come from?

Hans.

On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
yes, you are right about the unrestricted client use case; I just got
caught by the fact that you were talking about *unrestricted* client
registration all the time (standards-based or not) which deserves extra
caution whereas Google (and the spec) also provides *restricted* client
registration the deviation or caution is not needed

Hans.

On 9/4/14, 1:44 PM, Antonio Sanso wrote:
hi Hans

On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
mailto:hzandb...@pingidentity.com>> wrote:

Agreed, I see you point about the big providers using exactly the
unrestricted flow for which the trust model (by definition) is out of
scope of the spec. This may be the reason for the implemented
behavior indeed and a security consideration is a good idea for other
deployments; there's not much more that can be done.

But Google also provides explicit registration for API clients (which
is where my mind was):
https://developers.google.com/accounts/docs/OAuth2 (step 1)
and they would not need to deviate from the spec for that, nor would
the spec need to change

I do really struggle to understand your point here :) (at least the
"nor would the spec need to change part" :)).

Probably I need to explain myself better.
Since Google is “safe” (due the “deviation” from the spec) I would
take Google as example here (I could point out open redirector in the
wild to proof my point but I will not do…)

Let’s start from scratch…

If Google would have something like
http://www.google.com?goto=attacker.com this is without any doubt an
open redirector… see  also OWASP 10 [0].

Now if Google would have implemented the spec rfc6749 verbatim
something like

https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com


would have redirect to http://attacker.com.

So why this is not an open redirect ? :)

Now maybe we are saying the same thing but I felt like better explain
my point :)

regards

antonio

[0]
https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards




Hans.

On 9/4/14, 9:50 AM, Antonio Sanso wrote:
Hi Hans,

I really fail to see how this can be addressed at registration time
for cases where registration is unrestricted (namely all the big
Providers)

regards

antonio

On Sep 4, 2014, at 9:47 AM, Hans Zandbelt
 wrote:

Classifying like this must also mean that consent should not be
stored until the client is considered (admin) trusted, and admin
policy would interfere with user policy.

IMHO the security consideration would apply only to dynamically
registered clients where registration is unrestricted; any other
form would involve some form of admin/user approval at registration
time, overcoming the concern at authorization time: there's no
auto-redirect flow possible for unknown clients.

Hans.

On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
I think this advice isn't a bad idea, though it's of course up to
the AS
what an "untrusted" client really is. In practice, this is something
that was registered by a non-sysadmin type person, either a
dynamically
registered client or something available through self-service
registration of some type. It's also reasonable that a client, even
dynamically registered, would be considered "trusted" if enough
time has
passed and enough users have used it without things blowing up.

 -- Justin

On Sep 4, 2014, at 1:26 AM, Antonio Sanso mailto:asa...@adobe.com>> wrote:

hi again *,

after thinking a bit further IMHO an alternative for the untrusted
clients can also be to always present the consent screen (at least
once) before any redirect.
Namely all providers I have seen show the consent screen if all the
request parameters are correct and if the user accepts the redirect
happens.
If one of the parameter  (with the exclusion of the client id and
redirect uri that are handled differently as for spec) is wrong
though
the redirect happens without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso mailto:asa...@adobe.com>> wrote:

Well,
I do not know if this is only dynamic registration...
let’s talk about real use cases, namely e.g. Google , Facebook ,
etc.. is that dynamic client registration? I do not know… :)

Said that what the other guys think?  :)
Would this deserve some “spec adjustment” ? I mean there is a
reason
if Google is by choice “violating” the spec right? (I assume to
avoid
open redirect…)
But other implementers do follow the spec hence they have this open
redirector… and this is not nice IM

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

On Sep 4, 2014, at 2:22 PM, John Bradley  wrote:

> Registration requiring a valid email address is not sufficient to stop a 
> "bad" person from registering a client that appears to be perfectly 
> legitimate but is later used as a redirect.

totally agree!

> 
> So it is a bit slippery to differentiate good from bad.
> 
> In general clearing the referrer and fragment from incoming requests is a 
> good practice on redirects to prevent leakage of information across the 
> redirect.

+1

> 
> The other concern is using the redirect as part of a phishing attack to make 
> the target site look more legitimate.
> That is a more complicated problem unless you validate every client by 
> looking at them to make sure they are not bad in some way.

and here it comes the "error 400"  or the "always show the consent screen” 
approach

regards

antonio

> 
> John B.
> 
> 
> On Sep 4, 2014, at 2:09 PM, Hans Zandbelt  wrote:
> 
>> Maybe just to clarify my point: where did the client_id in the example that 
>> you gave come from?
>> 
>> Hans.
>> 
>> On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
>>> yes, you are right about the unrestricted client use case; I just got
>>> caught by the fact that you were talking about *unrestricted* client
>>> registration all the time (standards-based or not) which deserves extra
>>> caution whereas Google (and the spec) also provides *restricted* client
>>> registration the deviation or caution is not needed
>>> 
>>> Hans.
>>> 
>>> On 9/4/14, 1:44 PM, Antonio Sanso wrote:
>>>> hi Hans
>>>> 
>>>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
>>>>  wrote:
>>>> 
>>>>> Agreed, I see you point about the big providers using exactly the
>>>>> unrestricted flow for which the trust model (by definition) is out of
>>>>> scope of the spec. This may be the reason for the implemented
>>>>> behavior indeed and a security consideration is a good idea for other
>>>>> deployments; there's not much more that can be done.
>>>>> 
>>>>> But Google also provides explicit registration for API clients (which
>>>>> is where my mind was):
>>>>> https://developers.google.com/accounts/docs/OAuth2 (step 1)
>>>>> and they would not need to deviate from the spec for that, nor would
>>>>> the spec need to change
>>>> 
>>>> I do really struggle to understand your point here :) (at least the
>>>> "nor would the spec need to change part" :)).
>>>> 
>>>> Probably I need to explain myself better.
>>>> Since Google is “safe” (due the “deviation” from the spec) I would
>>>> take Google as example here (I could point out open redirector in the
>>>> wild to proof my point but I will not do…)
>>>> 
>>>> Let’s start from scratch…
>>>> 
>>>> If Google would have something like
>>>> http://www.google.com?goto=attacker.com this is without any doubt an
>>>> open redirector… see  also OWASP 10 [0].
>>>> 
>>>> Now if Google would have implemented the spec rfc6749 verbatim
>>>> something like
>>>> 
>>>> https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
>>>> 
>>>> 
>>>> would have redirect to http://attacker.com.
>>>> 
>>>> So why this is not an open redirect ? :)
>>>> 
>>>> Now maybe we are saying the same thing but I felt like better explain
>>>> my point :)
>>>> 
>>>> regards
>>>> 
>>>> antonio
>>>> 
>>>> [0]
>>>> https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> Hans.
>>>>> 
>>>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote:
>>>>>> Hi Hans,
>>>>>> 
>>>>>> I really fail to see how this can be addressed at registration time
>>>>>> for cases where registration is unrestricted (namely all the big
>>>>>> Providers)
>>>>>> 
>>>>>> regards
>>>>>> 
>>>>>> antonio
>>>>>> 
>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt
>>>>>&

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Bill 
On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:

> FWIW, Antonio convinced me and I'm going to change this in our IDM project.  
> Thanks Antonio.  What convinced me was that the user is probably expecting a 
> login screen.  Since there is this expectation, it might make it a little 
> easier for the attacker to convince the user that a spoofed login screen is 
> real.  I know this issue can only happen with unrestricted registration, but, 
> IMO, this proposed change doesn't really have much of an effect on usability 
> and is even backward compatible with the current RFC.
> 
> Wouldn't it better though to never do a redirect on an invalid request and 
> just display an error page?

thanks for sharing your thoughts :). Display an error 400 is what Google does :)

regards

antonio

> 
> On 9/4/2014 3:50 AM, Antonio Sanso wrote:
>> Hi Hans,
>> 
>> I really fail to see how this can be addressed at registration time for 
>> cases where registration is unrestricted (namely all the big Providers)
>> 
>> regards
>> 
>> antonio
>> 
>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt  wrote:
>> 
>>> Classifying like this must also mean that consent should not be stored 
>>> until the client is considered (admin) trusted, and admin policy would 
>>> interfere with user policy.
>>> 
>>> IMHO the security consideration would apply only to dynamically registered 
>>> clients where registration is unrestricted; any other form would involve 
>>> some form of admin/user approval at registration time, overcoming the 
>>> concern at authorization time: there's no auto-redirect flow possible for 
>>> unknown clients.
>>> 
>>> Hans.
>>> 
>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>>>> I think this advice isn't a bad idea, though it's of course up to the AS
>>>> what an "untrusted" client really is. In practice, this is something
>>>> that was registered by a non-sysadmin type person, either a dynamically
>>>> registered client or something available through self-service
>>>> registration of some type. It's also reasonable that a client, even
>>>> dynamically registered, would be considered "trusted" if enough time has
>>>> passed and enough users have used it without things blowing up.
>>>> 
>>>>  -- Justin
>>>> 
>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>> <mailto:asa...@adobe.com>> wrote:
>>>> 
>>>>> hi again *,
>>>>> 
>>>>> after thinking a bit further IMHO an alternative for the untrusted
>>>>> clients can also be to always present the consent screen (at least
>>>>> once) before any redirect.
>>>>> Namely all providers I have seen show the consent screen if all the
>>>>> request parameters are correct and if the user accepts the redirect
>>>>> happens.
>>>>> If one of the parameter  (with the exclusion of the client id and
>>>>> redirect uri that are handled differently as for spec) is wrong though
>>>>> the redirect happens without the consent screen being shown..
>>>>> 
>>>>> WDYT?
>>>>> 
>>>>> regards
>>>>> 
>>>>> antonio
>>>>> 
>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>> <mailto:asa...@adobe.com>> wrote:
>>>>> 
>>>>>> Well,
>>>>>> I do not know if this is only dynamic registration...
>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook ,
>>>>>> etc.. is that dynamic client registration? I do not know… :)
>>>>>> 
>>>>>> Said that what the other guys think?  :)
>>>>>> Would this deserve some “spec adjustment” ? I mean there is a reason
>>>>>> if Google is by choice “violating” the spec right? (I assume to avoid
>>>>>> open redirect…)
>>>>>> But other implementers do follow the spec hence they have this open
>>>>>> redirector… and this is not nice IMHO...
>>>>>> 
>>>>>> 
>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>> <mailto:hzandb...@pingidentity.com>> wrote:
>>>>>> 
>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote:
>>>>>>>> 
>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zan

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Hans

On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  wrote:

> I am convinced about the issue in the use case Antonio provided but I hope 
> not to close the door on returning errors to known and trusted clients. Not 
> sure anymore if that's possible though because the distinction can't be 
> "registered"…

an alternative is to show always the consent screen (at least once if the 
client id/redirect_uri is valid and accept the app) even if the scope or any 
other parameter is not valid before to redirect to the redirect uri.

regards

antonio

> 
> Hans.
> 
> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
>> hi Bill
>> On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:
>> 
>>> FWIW, Antonio convinced me and I'm going to change this in our IDM project. 
>>>  Thanks Antonio.  What convinced me was that the user is probably expecting 
>>> a login screen.  Since there is this expectation, it might make it a little 
>>> easier for the attacker to convince the user that a spoofed login screen is 
>>> real.  I know this issue can only happen with unrestricted registration, 
>>> but, IMO, this proposed change doesn't really have much of an effect on 
>>> usability and is even backward compatible with the current RFC.
>>> 
>>> Wouldn't it better though to never do a redirect on an invalid request and 
>>> just display an error page?
>> 
>> thanks for sharing your thoughts :). Display an error 400 is what Google 
>> does :)
>> 
>> regards
>> 
>> antonio
>> 
>>> 
>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote:
>>>> Hi Hans,
>>>> 
>>>> I really fail to see how this can be addressed at registration time for 
>>>> cases where registration is unrestricted (namely all the big Providers)
>>>> 
>>>> regards
>>>> 
>>>> antonio
>>>> 
>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt  
>>>> wrote:
>>>> 
>>>>> Classifying like this must also mean that consent should not be stored 
>>>>> until the client is considered (admin) trusted, and admin policy would 
>>>>> interfere with user policy.
>>>>> 
>>>>> IMHO the security consideration would apply only to dynamically 
>>>>> registered clients where registration is unrestricted; any other form 
>>>>> would involve some form of admin/user approval at registration time, 
>>>>> overcoming the concern at authorization time: there's no auto-redirect 
>>>>> flow possible for unknown clients.
>>>>> 
>>>>> Hans.
>>>>> 
>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>>>>>> I think this advice isn't a bad idea, though it's of course up to the AS
>>>>>> what an "untrusted" client really is. In practice, this is something
>>>>>> that was registered by a non-sysadmin type person, either a dynamically
>>>>>> registered client or something available through self-service
>>>>>> registration of some type. It's also reasonable that a client, even
>>>>>> dynamically registered, would be considered "trusted" if enough time has
>>>>>> passed and enough users have used it without things blowing up.
>>>>>> 
>>>>>>  -- Justin
>>>>>> 
>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>> <mailto:asa...@adobe.com>> wrote:
>>>>>> 
>>>>>>> hi again *,
>>>>>>> 
>>>>>>> after thinking a bit further IMHO an alternative for the untrusted
>>>>>>> clients can also be to always present the consent screen (at least
>>>>>>> once) before any redirect.
>>>>>>> Namely all providers I have seen show the consent screen if all the
>>>>>>> request parameters are correct and if the user accepts the redirect
>>>>>>> happens.
>>>>>>> If one of the parameter  (with the exclusion of the client id and
>>>>>>> redirect uri that are handled differently as for spec) is wrong though
>>>>>>> the redirect happens without the consent screen being shown..
>>>>>>> 
>>>>>>> WDYT?
>>>>>>> 
>>>>>>> regards
>>>>>>> 
>>>>>>> antonio
>>>>>>>

Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?

[Antonio Sanso]

I would like to attend as well …

regards

antonio

On Sep 12, 2014, at 3:00 AM, Gil Kirkpatrick 
mailto:gil.kirkpatr...@viewds.com>> wrote:

+1 for me.

-- Original Message --
From: "John Bradley" mailto:ve7...@ve7jtb.com>>
To: "Nat Sakimura" mailto:sakim...@gmail.com>>
Cc: "Derek Atkins" mailto:de...@ihtfp.com>>; 
"oauth@ietf.org" mailto:oauth@ietf.org>>
Sent: 12/09/2014 9:30:50 AM
Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?

And me

Sent from my iPhone

On Sep 11, 2014, at 7:49 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:

Add me, too.

2014-09-12 7:32 GMT+09:00 Anthony Nadalin 
mailto:tony...@microsoft.com>>:
Add me

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the 
draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion was to 
discuss the problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational 
document.

Conference calls could start in about 2 weeks and we would like to know who 
would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi *,

my understanding is that there is a rough consensus that if an OAuth Provider 
follows rfc6749 verbatim will end up having an open redirector.
My next question would be now, is there anything we can do to raise some 
awareness about this issue?

regards

antonio

On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  wrote:

> I am convinced about the issue in the use case Antonio provided but I hope 
> not to close the door on returning errors to known and trusted clients. Not 
> sure anymore if that's possible though because the distinction can't be 
> "registered"...
> 
> Hans.
> 
> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
>> hi Bill
>> On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:
>> 
>>> FWIW, Antonio convinced me and I'm going to change this in our IDM project. 
>>>  Thanks Antonio.  What convinced me was that the user is probably expecting 
>>> a login screen.  Since there is this expectation, it might make it a little 
>>> easier for the attacker to convince the user that a spoofed login screen is 
>>> real.  I know this issue can only happen with unrestricted registration, 
>>> but, IMO, this proposed change doesn't really have much of an effect on 
>>> usability and is even backward compatible with the current RFC.
>>> 
>>> Wouldn't it better though to never do a redirect on an invalid request and 
>>> just display an error page?
>> 
>> thanks for sharing your thoughts :). Display an error 400 is what Google 
>> does :)
>> 
>> regards
>> 
>> antonio
>> 
>>> 
>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote:
>>>> Hi Hans,
>>>> 
>>>> I really fail to see how this can be addressed at registration time for 
>>>> cases where registration is unrestricted (namely all the big Providers)
>>>> 
>>>> regards
>>>> 
>>>> antonio
>>>> 
>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt  
>>>> wrote:
>>>> 
>>>>> Classifying like this must also mean that consent should not be stored 
>>>>> until the client is considered (admin) trusted, and admin policy would 
>>>>> interfere with user policy.
>>>>> 
>>>>> IMHO the security consideration would apply only to dynamically 
>>>>> registered clients where registration is unrestricted; any other form 
>>>>> would involve some form of admin/user approval at registration time, 
>>>>> overcoming the concern at authorization time: there's no auto-redirect 
>>>>> flow possible for unknown clients.
>>>>> 
>>>>> Hans.
>>>>> 
>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>>>>>> I think this advice isn't a bad idea, though it's of course up to the AS
>>>>>> what an "untrusted" client really is. In practice, this is something
>>>>>> that was registered by a non-sysadmin type person, either a dynamically
>>>>>> registered client or something available through self-service
>>>>>> registration of some type. It's also reasonable that a client, even
>>>>>> dynamically registered, would be considered "trusted" if enough time has
>>>>>> passed and enough users have used it without things blowing up.
>>>>>> 
>>>>>>  -- Justin
>>>>>> 
>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>> <mailto:asa...@adobe.com>> wrote:
>>>>>> 
>>>>>>> hi again *,
>>>>>>> 
>>>>>>> after thinking a bit further IMHO an alternative for the untrusted
>>>>>>> clients can also be to always present the consent screen (at least
>>>>>>> once) before any redirect.
>>>>>>> Namely all providers I have seen show the consent screen if all the
>>>>>>> request parameters are correct and if the user accepts the redirect
>>>>>>> happens.
>>>>>>> If one of the parameter  (with the exclusion of the client id and
>>>>>>> redirect uri that are handled differently as for spec) is wrong though
>>>>>>> the redirect happens without the consent screen being shown..
>>>>>>> 
>>>>>>> WDYT?
>>>>>>> 
>>>>>>> regards
>>>>>>> 
>>>>>>> antonio
>>>

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

On Sep 15, 2014, at 9:41 PM, Phil Hunt  wrote:
hi Phil

> Simply not true.

why do you think so ?

regards

antonio
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:
> 
>> hi *,
>> 
>> my understanding is that there is a rough consensus that if an OAuth 
>> Provider follows rfc6749 verbatim will end up having an open redirector.
>> My next question would be now, is there anything we can do to raise some 
>> awareness about this issue?
>> 
>> regards
>> 
>> antonio
>> 
>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  wrote:
>> 
>>> I am convinced about the issue in the use case Antonio provided but I hope 
>>> not to close the door on returning errors to known and trusted clients. Not 
>>> sure anymore if that's possible though because the distinction can't be 
>>> "registered"...
>>> 
>>> Hans.
>>> 
>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
>>>> hi Bill
>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:
>>>> 
>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM 
>>>>> project.  Thanks Antonio.  What convinced me was that the user is 
>>>>> probably expecting a login screen.  Since there is this expectation, it 
>>>>> might make it a little easier for the attacker to convince the user that 
>>>>> a spoofed login screen is real.  I know this issue can only happen with 
>>>>> unrestricted registration, but, IMO, this proposed change doesn't really 
>>>>> have much of an effect on usability and is even backward compatible with 
>>>>> the current RFC.
>>>>> 
>>>>> Wouldn't it better though to never do a redirect on an invalid request 
>>>>> and just display an error page?
>>>> 
>>>> thanks for sharing your thoughts :). Display an error 400 is what Google 
>>>> does :)
>>>> 
>>>> regards
>>>> 
>>>> antonio
>>>> 
>>>>> 
>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote:
>>>>>> Hi Hans,
>>>>>> 
>>>>>> I really fail to see how this can be addressed at registration time for 
>>>>>> cases where registration is unrestricted (namely all the big Providers)
>>>>>> 
>>>>>> regards
>>>>>> 
>>>>>> antonio
>>>>>> 
>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt  
>>>>>> wrote:
>>>>>> 
>>>>>>> Classifying like this must also mean that consent should not be stored 
>>>>>>> until the client is considered (admin) trusted, and admin policy would 
>>>>>>> interfere with user policy.
>>>>>>> 
>>>>>>> IMHO the security consideration would apply only to dynamically 
>>>>>>> registered clients where registration is unrestricted; any other form 
>>>>>>> would involve some form of admin/user approval at registration time, 
>>>>>>> overcoming the concern at authorization time: there's no auto-redirect 
>>>>>>> flow possible for unknown clients.
>>>>>>> 
>>>>>>> Hans.
>>>>>>> 
>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>>>>>>>> I think this advice isn't a bad idea, though it's of course up to the 
>>>>>>>> AS
>>>>>>>> what an "untrusted" client really is. In practice, this is something
>>>>>>>> that was registered by a non-sysadmin type person, either a dynamically
>>>>>>>> registered client or something available through self-service
>>>>>>>> registration of some type. It's also reasonable that a client, even
>>>>>>>> dynamically registered, would be considered "trusted" if enough time 
>>>>>>>> has
>>>>>>>> passed and enough users have used it without things blowing up.
>>>>>>>> 
>>>>>>>> -- Justin
>>>>>>>> 
>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>> <mailto:asa...@adobe.com>> wrote:
>>>>>>&

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

The problem is that a malicious client can register a malicious redirect uri 
and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as 
previously discussed)

regards

antonio

On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:

> If a server accepts a URL from a client to be used as a redirect that the 
> server doesn’t recognize or is not registered, that is an open redirect.
> 
> The specification does no allow open-redirects, it considers this a 
> mis-configuration.
> 
> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:
> 
>> There may be a problem with semantics in this discussion. 
>> 
>> There is a redirect performed by athe authorization endpoint to a fixed uri 
>> that is pre registered with the authorization server without user prompting. 
>> 
>> That probably doesn't fit the strict definition of a open redirector. 
>> 
>> It may however create similar security issues in situations with relatively 
>> open registration of clients. 
>> 
>> The largest issues are that the browser might leak information across the 
>> redirect in the fragment or referrer.  That has been used in attacks against 
>> Facebook in the past. 
>> 
>> This is no where near the end of the world,  however we need to look at the 
>> security considerations and see if we can provide better advice to 
>> implementors.  In some cases returning a error to the browser may be best.  
>> 
>> I don't think we need to go so far as not returning any error to the client 
>> under any circumstance. 
>> 
>> John B. 
>> 
>> Sent from my iPhone
>> 
>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt  wrote:
>>> 
>>> Simply not true.
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:
>>>> 
>>>> hi *,
>>>> 
>>>> my understanding is that there is a rough consensus that if an OAuth 
>>>> Provider follows rfc6749 verbatim will end up having an open redirector.
>>>> My next question would be now, is there anything we can do to raise some 
>>>> awareness about this issue?
>>>> 
>>>> regards
>>>> 
>>>> antonio
>>>> 
>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  
>>>>> wrote:
>>>>> 
>>>>> I am convinced about the issue in the use case Antonio provided but I 
>>>>> hope not to close the door on returning errors to known and trusted 
>>>>> clients. Not sure anymore if that's possible though because the 
>>>>> distinction can't be "registered"...
>>>>> 
>>>>> Hans.
>>>>> 
>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
>>>>>> hi Bill
>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:
>>>>>>> 
>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM 
>>>>>>> project.  Thanks Antonio.  What convinced me was that the user is 
>>>>>>> probably expecting a login screen.  Since there is this expectation, it 
>>>>>>> might make it a little easier for the attacker to convince the user 
>>>>>>> that a spoofed login screen is real.  I know this issue can only happen 
>>>>>>> with unrestricted registration, but, IMO, this proposed change doesn't 
>>>>>>> really have much of an effect on usability and is even backward 
>>>>>>> compatible with the current RFC.
>>>>>>> 
>>>>>>> Wouldn't it better though to never do a redirect on an invalid request 
>>>>>>> and just display an error page?
>>>>>> 
>>>>>> thanks for sharing your thoughts :). Display an error 400 is what Google 
>>>>>> does :)
>>>>>> 
>>>>>> regards
>>>>>> 
>>>>>> antonio
>>>>>> 
>>>>>>> 
>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote:
>>>>>>>> Hi Hans,
>>>>>>>> 
>>>>>>>> I really fail to see how this can be ad

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

On Sep 15, 2014, at 11:08 PM, Phil Hunt  wrote:

> I’m not sure I understand why this is an OAuth protocol problem?
> 
> If you are starting with a false client with a false registration, everything 
> down stream is likely invalid. 

registration is not false. But the client can be a malicious one…. 


> 
> This seems like a registration curation (whitelisting) problem.

there is not way a whitelist can cover all the malicious uris..

regards

antonio

> 
> This is a bit like saying, how can I prove that the application on this 
> jail-broken phone is legitimate?
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Sep 15, 2014, at 1:52 PM, Antonio Sanso  wrote:
> 
>> The problem is that a malicious client can register a malicious redirect uri 
>> and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as 
>> previously discussed)
>> 
>> regards
>> 
>> antonio
>> 
>> On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:
>> 
>>> If a server accepts a URL from a client to be used as a redirect that the 
>>> server doesn’t recognize or is not registered, that is an open redirect.
>>> 
>>> The specification does no allow open-redirects, it considers this a 
>>> mis-configuration.
>>> 
>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
>>> On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:
>>> 
>>>> There may be a problem with semantics in this discussion. 
>>>> 
>>>> There is a redirect performed by athe authorization endpoint to a fixed 
>>>> uri that is pre registered with the authorization server without user 
>>>> prompting. 
>>>> 
>>>> That probably doesn't fit the strict definition of a open redirector. 
>>>> 
>>>> It may however create similar security issues in situations with 
>>>> relatively open registration of clients. 
>>>> 
>>>> The largest issues are that the browser might leak information across the 
>>>> redirect in the fragment or referrer.  That has been used in attacks 
>>>> against Facebook in the past. 
>>>> 
>>>> This is no where near the end of the world,  however we need to look at 
>>>> the security considerations and see if we can provide better advice to 
>>>> implementors.  In some cases returning a error to the browser may be best. 
>>>>  
>>>> 
>>>> I don't think we need to go so far as not returning any error to the 
>>>> client under any circumstance. 
>>>> 
>>>> John B. 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt  wrote:
>>>>> 
>>>>> Simply not true.
>>>>> 
>>>>> Phil
>>>>> 
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.h...@oracle.com
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:
>>>>>> 
>>>>>> hi *,
>>>>>> 
>>>>>> my understanding is that there is a rough consensus that if an OAuth 
>>>>>> Provider follows rfc6749 verbatim will end up having an open redirector.
>>>>>> My next question would be now, is there anything we can do to raise some 
>>>>>> awareness about this issue?
>>>>>> 
>>>>>> regards
>>>>>> 
>>>>>> antonio
>>>>>> 
>>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> I am convinced about the issue in the use case Antonio provided but I 
>>>>>>> hope not to close the door on returning errors to known and trusted 
>>>>>>> clients. Not sure anymore if that's possible though because the 
>>>>>>> distinction can't be "registered"...
>>>>>>> 
>>>>>>> Hans.
>>>>>>> 
>>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
>>>>>>>> hi Bill
>>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill B

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Sergey

On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin 
mailto:sberyoz...@gmail.com>> wrote:

Hi

I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then does it imply
there's serious a weakness present somewhere else, in the
registration process for example ? Should the client registrations be
validated ?

as previously discussed is pretty fought to filter bad redirect uri specially 
for big OPs like Facebook/Google et al where all you need to have in order to 
create a new OAuth client is an email address (the registration process is 
self-service).

Justin proposed some mitigation though… (namely a client can gain ‘reputation’ 
with time)

regards

antonio


Sergey

On 16/09/14 08:52, Hans Zandbelt wrote:
+1, Antonio and John convinced me that this is not limited to a
registration curation problem although that is where the problems starts
as Phil points out (and as much as I'd like it to stay there).

There are and will be consumer OPs (like Google) that have no means to
do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security
consideration for OPs that have no policy in place to allow only trusted
clients to register would be a good thing.

The advice for those OPs would be to not send errors back to untrusted
clients or do it only after explicit user interaction.

Hans.

On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote:
I think a security considerations addendum makes sense.

regards,
Torsten.


 Ursprüngliche Nachricht 
Von: "Richer, Justin P."
Datum:15.09.2014 23:15 (GMT+01:00)
An: Antonio Sanso
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Betreff: Re: [OAUTH-WG] open redirect in rfc6749

As we discussed before: This isn't really an open redirection in the
classical sense since nothing gets leaked and the URI is tied back to a
known (albeit malicious) client registration. And I thought the clear
solution was to have an AS not automatically redirect to an untrusted
client in error conditions, where "untrusted" is defined by the AS with
guidance. If anything this is a security considerations addendum.

-- Justin

On Sep 15, 2014, at 4:52 PM, Antonio Sanso 
mailto:asa...@adobe.com>> wrote:

> The problem is that a malicious client can register a malicious
redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1
does the rest (as previously discussed)
>
> regards
>
> antonio
>
> On Sep 15, 2014, at 10:43 PM, Phil Hunt 
> mailto:phil.h...@oracle.com>> wrote:
>
>> If a server accepts a URL from a client to be used as a redirect
that the server doesn’t recognize or is not registered, that is an open
redirect.
>>
>> The specification does no allow open-redirects, it considers this a
mis-configuration.
>>
>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com<http://www.independentid.com>
>> phil.h...@oracle.com<mailto:phil.h...@oracle.com>
>>
>>
>>
>> On Sep 15, 2014, at 1:00 PM, John Bradley 
>> mailto:ve7...@ve7jtb.com>> wrote:
>>
>>> There may be a problem with semantics in this discussion.
>>>
>>> There is a redirect performed by athe authorization endpoint to a
fixed uri that is pre registered with the authorization server without
user prompting.
>>>
>>> That probably doesn't fit the strict definition of a open
redirector.
>>>
>>> It may however create similar security issues in situations with
relatively open registration of clients.
>>>
>>> The largest issues are that the browser might leak information
across the redirect in the fragment or referrer.  That has been used in
attacks against Facebook in the past.
>>>
>>> This is no where near the end of the world,  however we need to
look at the security considerations and see if we can provide better
advice to implementors.  In some cases returning a error to the browser
may be best.
>>>
>>> I don't think we need to go so far as not returning any error to
the client under any circumstance.
>>>
>>> John B.
>>>
>>> Sent from my iPhone
>>>
>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt 
>>>> mailto:phil.h...@oracle.com>>
wrote:
>>>>
>>>> Simply not true.
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com<http://www.independentid.com>
>>>> phil.h...@oracle.com<mailto:phil.h...@oracle.com>
>>>>
>>>>
>>>>
>>>>> On Sep 15, 2014, at 12:10 PM, Antonio S

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Phil.
On Sep 15, 2014, at 11:21 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

So, let’s say you have a client that has “obtained” a client Id from a legit 
registered client.  How does the malicious client exploit the previously 
registered URL if the server only redirects to that URL?

These are the steps:

- the malicious client can registers a malicious url 
(attacker.com<http://attacker.com>)
- the malicious client builds a malicious request to the AS 
(victim.com<http://victim.com>) that looks like 
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

as per https://tools.ietf.org/html/rfc6749#section-4.1.2.1 the user is 
redirected to http://attacker.com (since the wrong parameter is the scope )

regards

antonio


Are you referring to the case Nat Sakimura previously raised where mobile app 
stores do not enforce custom URL registrations?

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com



On Sep 15, 2014, at 2:11 PM, Antonio Sanso  wrote:


On Sep 15, 2014, at 11:08 PM, Phil Hunt  wrote:

I’m not sure I understand why this is an OAuth protocol problem?

If you are starting with a false client with a false registration, everything 
down stream is likely invalid.

registration is not false. But the client can be a malicious one….



This seems like a registration curation (whitelisting) problem.

there is not way a whitelist can cover all the malicious uris..

regards

antonio


This is a bit like saying, how can I prove that the application on this 
jail-broken phone is legitimate?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 1:52 PM, Antonio Sanso  wrote:

The problem is that a malicious client can register a malicious redirect uri 
and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as 
previously discussed)

regards

antonio

On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:

If a server accepts a URL from a client to be used as a redirect that the 
server doesn’t recognize or is not registered, that is an open redirect.

The specification does no allow open-redirects, it considers this a 
mis-configuration.

Take a look at sections 3.1.2.2 and 10.15 of RFC6749.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:

There may be a problem with semantics in this discussion.

There is a redirect performed by athe authorization endpoint to a fixed uri 
that is pre registered with the authorization server without user prompting.

That probably doesn't fit the strict definition of a open redirector.

It may however create similar security issues in situations with relatively 
open registration of clients.

The largest issues are that the browser might leak information across the 
redirect in the fragment or referrer.  That has been used in attacks against 
Facebook in the past.

This is no where near the end of the world,  however we need to look at the 
security considerations and see if we can provide better advice to 
implementors.  In some cases returning a error to the browser may be best.

I don't think we need to go so far as not returning any error to the client 
under any circumstance.

John B.

Sent from my iPhone

On Sep 15, 2014, at 4:41 PM, Phil Hunt  wrote:

Simply not true.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:

hi *,

my understanding is that there is a rough consensus that if an OAuth Provider 
follows rfc6749 verbatim will end up having an open redirector.
My next question would be now, is there anything we can do to raise some 
awareness about this issue?

regards

antonio

On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  wrote:

I am convinced about the issue in the use case Antonio provided but I hope not 
to close the door on returning errors to known and trusted clients. Not sure 
anymore if that's possible though because the distinction can't be 
"registered"...

Hans.

On 9/4/14, 3:01 PM, Antonio Sanso wrote:
hi Bill
On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:

FWIW, Antonio convinced me and I'm going to change this in our IDM project.  
Thanks Antonio.  What convinced me was that the user is probably expecting a 
login screen.  Since there is this expectation, it might make it a little 
easier for the attacker to convince the user that a spoofed login screen is 
real.  I know this issue can only happen with unrestricted registration, but, 
IMO, this proposed change doesn't really have much of an effect on usability 
and is even backward compatible with the current RFC.

Wouldn't it better though to never do a redirect on an invalid request and just 
display an error page?

thanks for sharing your thoughts :). Display an error 400 is what Google does :)

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

Hi John,

agree that there are at two different things (as you pointed out below) where 
we could spend some word and provide some advice.

To summarize:

- one is the 'open redirect’ issue (net of semantic :), pointed by me,  where 
nothing is leaked 
- one is the leakage, pointed by John

Those two scenarios are different and might deserve to be discussed 
independently… :)


On Sep 15, 2014, at 11:56 PM, John Bradley  wrote:

> Something might get leaked by the browser, the fragment may be leaked by the 
> browser if the redirect URI doesn't contain a fragment in some browsers.
> 
> A simple security consideration might be to add a fragment to the 
> redirect_uri in the error case.
> 
> The other way that information may leak is via the referrer.   If there is 
> only one redirect by the AS the URI that was sent to the AS including all the 
> parameters would still be available to the target.
> A simple fix is to redirect to a intermediate page before redirecting to the 
> registered client, this clears the referrer.
> 
> It is true that nothing is leaked in the redirect_uri itself but there are 
> side channels in the browser that need to be considered.
> 
> The fixes are quite simple implementation issues and don't break anything.
> 
> Yes if the client is trusted then this is probably unnecessary but wouldn't 
> hurt anything.
> 
> John B.
> 
> PS for OAuth this would really only be exploitable if exact redirect_uri 
> matching is not happening.   
> 
> As I am a inherently bad person, I could hypothetically use this to attack a 
> AS that is doing domain level pattern matching of redirect URI and has a 
> public client in the same domain as the AS.
> 
> I should also note that domains using pattern matching are also vulnerable if 
> they allow other sorts of user hosted content like blog posts that pull in 
> images and leak the referrer.

if somebody is curios about some real world attack this is one I performed to 
Facebook that does exactly what John describes here 
http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html

regards

antonio

> 
> So we do probably need to provide some advice.
> 
> John B.
> 
> On Sep 15, 2014, at 6:15 PM, Richer, Justin P.  wrote:
> 
>> As we discussed before: This isn't really an open redirection in the 
>> classical sense since nothing gets leaked and the URI is tied back to a 
>> known (albeit malicious) client registration. And I thought the clear 
>> solution was to have an AS not automatically redirect to an untrusted client 
>> in error conditions, where "untrusted" is defined by the AS with guidance. 
>> If anything this is a security considerations addendum.
>> 
>> -- Justin
>> 
>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso  wrote:
>> 
>>> The problem is that a malicious client can register a malicious redirect 
>>> uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest 
>>> (as previously discussed)
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>> On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:
>>> 
>>>> If a server accepts a URL from a client to be used as a redirect that the 
>>>> server doesn’t recognize or is not registered, that is an open redirect.
>>>> 
>>>> The specification does no allow open-redirects, it considers this a 
>>>> mis-configuration.
>>>> 
>>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> phil.h...@oracle.com
>>>> 
>>>> 
>>>> 
>>>> On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:
>>>> 
>>>>> There may be a problem with semantics in this discussion. 
>>>>> 
>>>>> There is a redirect performed by athe authorization endpoint to a fixed 
>>>>> uri that is pre registered with the authorization server without user 
>>>>> prompting. 
>>>>> 
>>>>> That probably doesn't fit the strict definition of a open redirector. 
>>>>> 
>>>>> It may however create similar security issues in situations with 
>>>>> relatively open registration of clients. 
>>>>> 
>>>>> The largest issues are that the browser might leak information across the 
>>>>> redirect in the fragment or referrer.  That has been used in attacks 
>>>>> against Facebook in the past. 
>>>>> 
>>>>> This is

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi again *,

apologies to bother you again with this :), just wasn’t really  clear to me if 
this is considered like ‘solved’ (namely the discussion is over, no action to 
be taken) or we need still to discuss about this topic in order to reach some 
sort of consensus :)

regards

antonio
 
On Sep 16, 2014, at 4:40 PM, Bill Burke  wrote:

> I'll reiterate what convinced me if it helps.
> 
> The danger was a matter of expectations.  In Antonio's scenario, the user is 
> more likely to be expecting a login screen and thus more likely to be fooled 
> by a login-screen spoof.  Antonio's suggested changes don't break any 
> compatibility either, it just requires the AS to display an error page on 
> *any* parameter error instead of redirecting back. Something the spec already 
> requires for a bad client id.
> 
> On 9/16/2014 5:08 AM, Antonio Sanso wrote:
>> Hi John,
>> 
>> agree that there are at two different things (as you pointed out below) 
>> where we could spend some word and provide some advice.
>> 
>> To summarize:
>> 
>> - one is the 'open redirect’ issue (net of semantic :), pointed by me,  
>> where nothing is leaked
>> - one is the leakage, pointed by John
>> 
>> Those two scenarios are different and might deserve to be discussed 
>> independently… :)
>> 
> 
>> On Sep 15, 2014, at 11:56 PM, John Bradley  wrote:
>> 
>>> Something might get leaked by the browser, the fragment may be leaked by 
>>> the browser if the redirect URI doesn't contain a fragment in some browsers.
>>> 
>>> A simple security consideration might be to add a fragment to the 
>>> redirect_uri in the error case.
>>> 
>>> The other way that information may leak is via the referrer.   If there is 
>>> only one redirect by the AS the URI that was sent to the AS including all 
>>> the parameters would still be available to the target.
>>> A simple fix is to redirect to a intermediate page before redirecting to 
>>> the registered client, this clears the referrer.
>>> 
>>> It is true that nothing is leaked in the redirect_uri itself but there are 
>>> side channels in the browser that need to be considered.
>>> 
>>> The fixes are quite simple implementation issues and don't break anything.
>>> 
>>> Yes if the client is trusted then this is probably unnecessary but wouldn't 
>>> hurt anything.
>>> 
>>> John B.
>>> 
>>> PS for OAuth this would really only be exploitable if exact redirect_uri 
>>> matching is not happening.
>>> 
>>> As I am a inherently bad person, I could hypothetically use this to attack 
>>> a AS that is doing domain level pattern matching of redirect URI and has a 
>>> public client in the same domain as the AS.
>>> 
>>> I should also note that domains using pattern matching are also vulnerable 
>>> if they allow other sorts of user hosted content like blog posts that pull 
>>> in images and leak the referrer.
>> 
>> if somebody is curios about some real world attack this is one I performed 
>> to Facebook that does exactly what John describes here 
>> http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html
>> 
>> regards
>> 
>> antonio
>> 
>>> 
>>> So we do probably need to provide some advice.
>>> 
>>> John B.
>>> 
>>> On Sep 15, 2014, at 6:15 PM, Richer, Justin P.  wrote:
>>> 
>>>> As we discussed before: This isn't really an open redirection in the 
>>>> classical sense since nothing gets leaked and the URI is tied back to a 
>>>> known (albeit malicious) client registration. And I thought the clear 
>>>> solution was to have an AS not automatically redirect to an untrusted 
>>>> client in error conditions, where "untrusted" is defined by the AS with 
>>>> guidance. If anything this is a security considerations addendum.
>>>> 
>>>> -- Justin
>>>> 
>>>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso  wrote:
>>>> 
>>>>> The problem is that a malicious client can register a malicious redirect 
>>>>> uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest 
>>>>> (as previously discussed)
>>>>> 
>>>>> regards
>>>>> 
>>>>> antonio
>>>>> 
>>>>> On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:
>>>>> 
>>>&

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

just sharing with you how this very “issue” has been lately used in a real life 
attack:

http://andrisatteka.blogspot.ch/2014/09/how-microsoft-is-giving-your-data-to.html

regards

antonio

On Oct 9, 2014, at 3:34 PM, Antonio Sanso  wrote:

> hi again *,
> 
> apologies to bother you again with this :), just wasn’t really  clear to me 
> if this is considered like ‘solved’ (namely the discussion is over, no action 
> to be taken) or we need still to discuss about this topic in order to reach 
> some sort of consensus :)
> 
> regards
> 
> antonio
> 
> On Sep 16, 2014, at 4:40 PM, Bill Burke  wrote:
> 
>> I'll reiterate what convinced me if it helps.
>> 
>> The danger was a matter of expectations.  In Antonio's scenario, the user is 
>> more likely to be expecting a login screen and thus more likely to be fooled 
>> by a login-screen spoof.  Antonio's suggested changes don't break any 
>> compatibility either, it just requires the AS to display an error page on 
>> *any* parameter error instead of redirecting back. Something the spec 
>> already requires for a bad client id.
>> 
>> On 9/16/2014 5:08 AM, Antonio Sanso wrote:
>>> Hi John,
>>> 
>>> agree that there are at two different things (as you pointed out below) 
>>> where we could spend some word and provide some advice.
>>> 
>>> To summarize:
>>> 
>>> - one is the 'open redirect’ issue (net of semantic :), pointed by me,  
>>> where nothing is leaked
>>> - one is the leakage, pointed by John
>>> 
>>> Those two scenarios are different and might deserve to be discussed 
>>> independently… :)
>>> 
>> 
>>> On Sep 15, 2014, at 11:56 PM, John Bradley  wrote:
>>> 
>>>> Something might get leaked by the browser, the fragment may be leaked by 
>>>> the browser if the redirect URI doesn't contain a fragment in some 
>>>> browsers.
>>>> 
>>>> A simple security consideration might be to add a fragment to the 
>>>> redirect_uri in the error case.
>>>> 
>>>> The other way that information may leak is via the referrer.   If there is 
>>>> only one redirect by the AS the URI that was sent to the AS including all 
>>>> the parameters would still be available to the target.
>>>> A simple fix is to redirect to a intermediate page before redirecting to 
>>>> the registered client, this clears the referrer.
>>>> 
>>>> It is true that nothing is leaked in the redirect_uri itself but there are 
>>>> side channels in the browser that need to be considered.
>>>> 
>>>> The fixes are quite simple implementation issues and don't break anything.
>>>> 
>>>> Yes if the client is trusted then this is probably unnecessary but 
>>>> wouldn't hurt anything.
>>>> 
>>>> John B.
>>>> 
>>>> PS for OAuth this would really only be exploitable if exact redirect_uri 
>>>> matching is not happening.
>>>> 
>>>> As I am a inherently bad person, I could hypothetically use this to attack 
>>>> a AS that is doing domain level pattern matching of redirect URI and has a 
>>>> public client in the same domain as the AS.
>>>> 
>>>> I should also note that domains using pattern matching are also vulnerable 
>>>> if they allow other sorts of user hosted content like blog posts that pull 
>>>> in images and leak the referrer.
>>> 
>>> if somebody is curios about some real world attack this is one I performed 
>>> to Facebook that does exactly what John describes here 
>>> http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>>> 
>>>> So we do probably need to provide some advice.
>>>> 
>>>> John B.
>>>> 
>>>> On Sep 15, 2014, at 6:15 PM, Richer, Justin P.  wrote:
>>>> 
>>>>> As we discussed before: This isn't really an open redirection in the 
>>>>> classical sense since nothing gets leaked and the URI is tied back to a 
>>>>> known (albeit malicious) client registration. And I thought the clear 
>>>>> solution was to have an AS not automatically redirect to an untrusted 
>>>>> client in error conditions, where "untrusted" is defined by the AS with 
>>>>> guidance. If anything this is a security con

Re: [OAUTH-WG] Blackhat US: OAuth Talk

[Antonio Sanso]

hi Hannes,

thanks for the link. It is interesting.
Said that I think the attack shown there are a bit “academic” and do not 
reflect the real life situation. Moreover it still mention the MAC flow when 
AFAIK the OAuth working group decided to deviate from it.
IMHO the majority of real life attacks (and I can provide many many examples 
taken from blog posts of people that hacked big providers such Google,Facebook, 
Github etc) are actually targeting two things:

- weak/incorrect validation of the redirect_uri parameter
- leak of the access token . authorization code from the referrer

just my 0.02 cents :)

regards

antonio


On Oct 13, 2014, at 6:35 PM, Hannes Tschofenig  
wrote:

> During the OAuth conference call today I asked whether someone had
> looked at this paper published at the recent Blackhat US conference and
> nobody knew about it.
> 
> Hence, I am posting it here:
> 
> * Paper:
> 
> https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week-WP.pdf
> 
> * Slides:
> https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week.pdf
> 
> Ciao
> Hannes
> 
> ___
> 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

Re: [OAUTH-WG] Password in plaintext in emails from mailmain-ow...@ietf.org

[Antonio Sanso]

hi,

this is not Oauth@ietf only :)

regards

antonio
On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki 
mailto:daru...@gmail.com>> wrote:

Hello,

As a result of subscribing to oauth@ietf.org, 
mailmain-ow...@ietf.org periodically sends me 
emails titled "ietf.org mailing list memberships reminder" 
containing my password in PLAINTEXT. It's unbelievably insecure.

Is this happening only to me? How to stop 
mailmain-ow...@ietf.org from sending such 
emails? It's a terrible joke that this happens for 
OAUTH@ietf.org.

They store our passwords in plaintext in their database, or at least in a way 
for them to decrypt our passwords. One-way hash should be used...

Takahiko Kawasaki
___
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

Re: [OAUTH-WG] End User Authentication using OAuth 2.0

[Antonio Sanso]

nice stuff Justin.
Little nitpicking: is just me or this sounds a bit weird "signed by the 
identity provider's public key” ?

regards

antonio


On Nov 3, 2014, at 5:30 AM, Justin Richer  wrote:

> As of earlier this evening, I've published the article that we've been 
> working on about dealing with OAuth and end-user authentication. It's 
> available here:
> 
> http://oauth.net/articles/authentication/
> 
> Huge thanks to everyone who commented on the text, both here on the list and 
> last week at IIW. If there are edits to be made, either reply here or just 
> make a pull request directly from GitHub. It's not an RFC, we can keep 
> editing it. :)
> 
> In the process of putting this together for the site, I also created an 
> "Articles" structure on the site so that if there are other topics we want to 
> add, we (the community, not just the WG) can do so.
> 
> -- Justin
> 
> ___
> 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

Re: [OAUTH-WG] End User Authentication using OAuth 2.0

[Antonio Sanso]

ops sorry forget about it… of course this is correct… For some reason I read 
"signed with the identity provider's public key” :)

regards

antonio
On Nov 3, 2014, at 8:27 PM, Antonio Sanso  wrote:

> nice stuff Justin.
> Little nitpicking: is just me or this sounds a bit weird "signed by the 
> identity provider's public key” ?
> 
> regards
> 
> antonio
> 
> 
> On Nov 3, 2014, at 5:30 AM, Justin Richer  wrote:
> 
>> As of earlier this evening, I've published the article that we've been 
>> working on about dealing with OAuth and end-user authentication. It's 
>> available here:
>> 
>> http://oauth.net/articles/authentication/
>> 
>> Huge thanks to everyone who commented on the text, both here on the list and 
>> last week at IIW. If there are edits to be made, either reply here or just 
>> make a pull request directly from GitHub. It's not an RFC, we can keep 
>> editing it. :)
>> 
>> In the process of putting this together for the site, I also created an 
>> "Articles" structure on the site so that if there are other topics we want 
>> to add, we (the community, not just the WG) can do so.
>> 
>> -- Justin
>> 
>> ___
>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution nitpicking

[Antonio Sanso]

hi *.

AFAIU the access token in the  Client-to-AS Response is not “forced” to be JWT 
format but can also be an opaque string.
Now the example rather says:

HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store

 {
   "access_token":"SlAV32hkKG ...
(remainder of JWT omitted for brevity;
JWT contains JWK in the cnf claim)",
   "token_type":"pop",
   "expires_in":3600,
   "refresh_token":"8xLOxBtZp8",
   "key":"eyJhbGciOiJSU0ExXzUi ...
(remainder of plain JWK omitted for brevity)"
 }
now IMHO this is a bird odd cause 
access_token":"SlAV32hkKG ...
(remainder of JWT omitted for brevity;
JWT contains JWK in the cnf claim)
so either is not a JWT and "remainder of JWT omitted… should be removed or 
SlAV32hkKG should look like a JWT (and it is not the case at the moment :))

regards

antonio

[0] 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-00#section-4.2
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Meeting Minutes

[Antonio Sanso]

hi Hannes ,

thanks for sharing the minutes.

about

==
John reported a security problem where a 302 redirect without user interaction 
causes security problems. 
Do we want to say somthing about this?  Implementation guidance somewhere?

Chairs: Is this written up?

John: Yes, on mailing list.

Justin: This might be a good example for the oauth.net article section because 
it's implementation advice, not a change to the protocol.
=

I assume (maybe wrong) this might be about [0].
My question is there any timeline/action plan for this topic?
I am more than happy if I could contribute or try to help out

regards

antonio

[0] http://www.ietf.org/mail-archive/web/oauth/current/msg13367.html


On Nov 14, 2014, at 4:05 AM, Hannes Tschofenig  
wrote:

> Hi all,
> 
> here is a draft version of the meeting minutes:
> http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth
> 
> Thanks to Brian Rosen for taking notes.
> 
> Comments are welcome!
> 
> Ciao
> Hannes & Derek
> 
> ___
> 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

[OAUTH-WG] Top 5 OAuth 2 Implementation Vulnerabilities

[Antonio Sanso]

http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html

regards

antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Status

[Antonio Sanso]

hi *,
On Jan 9, 2015, at 11:18 AM, Hannes Tschofenig  
wrote:

> Hi all,
> 
> Happy New Year!
> 
> I thought it would be good to quickly summarize where we are with our
> work in OAuth as we start into 2015.
> 
> Late last year we issued a few working group last calls.
> 
> * SPOP
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
> 
> The WGLC was started already in the summer and led to a huge amount of
> feedback. This lead to an improved draft.
> 
> Nat, John, Naveen: What is the status of the document? What are the open
> issues?
> 
> At a minimum there is the issue with the name of the document since it
> actually does not propose a proof-of-
> possession solution.
> 
> * Token Introspection
> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/
> 
> Justin told me that he believes the document is ready for the IESG. I
> will do my shepherd write-up and shepherd review of the latest version
> before I hand it over to Kathleen.
> 
> * Dynamic Client Registration
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21
> 
> We had a fair amount of discussion about this document on the mailing
> list in response to my shepherd write-up. A new version of the document
> has been published and I will have to double-check whether the review
> comments have been incorporated. Then, the document will be ready for
> the IESG.
> 
> * OAuth 2.0 Proof-of-Possession (PoP) Security Architecture   
> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
> 
> We issued a WGLC and received comments, which had not yet been
> incorporated. The obvious next step is to publish a new version of the
> document with the comments addressed. There is also the new mailing list
>  and we have to figure out how this aligns with the work we
> are doing. Info is here:
> http://www.ietf.org/mail-archive/web/oauth/current/msg13997.html
> 
> Derek will be the shepherd for that document.
> 
> I also wanted to produce a short write-up in response to a news story
> late last year that blamed OAuth for getting things wrong while the real
> issue is rather with the way how responsibility are distributed among
> different players in the eco-system. Here is the link to the discussion
> and the news story:
> http://www.ietf.org/mail-archive/web/oauth/current/msg13929.html
> 
> We also have various documents in IESG processing, namely
> * JWT
> * Assertion Framework
> * SAML Bearer Assertion
> * JWT Bearer Assertion
> 
> Kathleen asked us to do a final review of the documents to make sure
> that various review comments have been addressed appropriately. I am
> planning to have a look at it today.
> 
> There is also a webinar upcoming, namely about Kantara UMA. This webinar
> will be a bit different than earlier presentations you have heard about
> UMA since it will be focused on Internet of Things. This is part of the
> webinar series we do in the IETF ACE working group. Here is a link to
> the announcement:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14015.html
> 
> Related to the work in this group is the SASL OAuth draft, which is
> currently in WGLC in the KITTEN working group and you might want to do a
> quick review of the document:
> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18
> 
> Here is the WGLC announcement from the KITTEN chairs:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14020.html
> 
> There is also the "authentication in OAuth" topic that we wanted to
> progress. There is a write-up from Justin available, which will inform
> the debate, but there was also interest to do something more official in
> the working group. We discussed this at the last IETF meeting.
> 
> Also at the last IETF meeting we briefly spoke about the token
> exchange/token delegation work and I got the impression that there is a
> bit of confusion about the scope of the work and what functionality
> should be covered in what document.
> 
> The last two topics seem to be suitable for conference calls. So, we
> will try to arrange something to progress these topics.
> 
> Finally, there is the open redirect Antonio raised in
> http://www.ietf.org/mail-archive/web/oauth/current/msg13367.html. The
> attack might be difficult to understand but it is still worthwhile
> to make an attempt to explain it to a wider audience (and also the
> mitigation technique). I believe a draft would be quite suitable for
> this purpose and I have spoken with Antonio about it already.
> 

thanks Hannes & Derek for including this here.
Even if I do not have any experience in IETF processes and related I was 
wondering if there is any change I can take a stub at and try to prepare a 
draft about this particular issue.
What do you guys think? Is there also anybody that would like to collaborate 
with me on this matter?

regards

antonio


> These are the items that come to mind right now. A lot of work ahead of
> us, as it seems.
> 
> What is missing from the list? Feedback?
> 
> Ciao
> Hannes & Derek
> 
> ___

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Antonio Sanso]

I wonder if the spec would have contained POST + 307 response rather than a 
GET+302 with fragment for the implicit grant would have been safer…..

At least the risk of fragment leakage would have been lower...

regards

antonio


On Feb 10, 2015, at 6:10 PM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

Inline
On Feb 10, 2015, at 1:12 PM, Adam Lewis 
mailto:adam.le...@motorolasolutions.com>> 
wrote:

Hi John,

What do you mean by the app that is “already loaded and cached in the browser?” 
 Where did this app come from initially?  Is this what comes from the 
web-hosted client resource in step D/E of section 4.2?  So the first time D/E 
*will* flow over the wire, and in all subsequent requests it will be cached?

Yes the web hosted client resource is typically the same JS code that is 
creating the Authorization request in A.   Now that you mention it the diagram 
in 4.2 is ambiguous about where that request comes from , the fact that it is 
coming from the browser implies that it is a JS CORS type request.

In some cases you might have a webserver invoke it via a 302 redirect and load 
a new JS app from the redirect URI.

The important thing is that the fragment is not sent to the server on the call 
that loads the JS even if it is not cached.

The thing people do (facebook and others) that is twisting implicit in my 
opinion is having the callback URI just load a JS snipppet that extracts the 
token and posts it back to “Web hosted client resource”
Those applications should be using the code flow.



And with respect to the web hosted client resource, is this a resource deployed 
by the same domain as the RS to facilitate the deployment of user-agent-based 
apps to access the APIs exposed by that RS?

The hosted client resource is typically a AJAX/AngularJS application that 
doesn’t want to swap out it’s context by doing a full 302 redirect to the AS.

The AS and RS could be completely separate from the client.

However it is not uncommon for people developing AngularJS apps to protect the 
API that they use with OAuth, in that case they may all be from the same domain.

It might be that a sophisticated app may have multiple tokens for different API 
across multiple providers.

John B.


adam

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Monday, February 09, 2015 3:31 PM
To: Prateek Mishra
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow

Typically the implicit callback JS is part of the application that is already 
loaded and cached in the browser.

The implicit flow doesn’t depend on on the fragment not being re-appended to 
the resource location URI in the 302.  It would admittedly be more secure if 
that didn’t happen.
Re-appending the fragment is the correct browser behaviour according to the W3C.

I still think you are farther ahead with that than leaking the code in the 
referrer.

Implicit if done correctly has the token in one leg.  code on the other hand 
has the code in 4 legs and the token in one.

It is having the JS make the exchange of code for the AT without a secret that 
is the problem in my opinion.

If the client is a server that is doing the code -> token exchange then the 
answer is different, but the question was for a JS only client.

John B.


On Feb 9, 2015, at 6:21 PM, Prateek Mishra 
mailto:prateek.mis...@oracle.com>> wrote:

The implicit flow depends upon a subtle and little known aspect of browser 
behavior - that the URI fragment component isn't propagated across redirects.

I havent checked this recently - but I am aware that several folks have found 
that some browser versions dont comply with this requirement.
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2

The additional round-trip issue is also unclear. The implicit flow requires an 
additional redirect (round-trip) to retrieve JS which retrieves the access 
token from the fragment URI.

How is that different from a HTTPs callback to exchange the access code for the 
access token?

- prateek



You are passing code in a query parameter, and without a secret that is more 
likely to be leaked than sending token in the fragment directly from the 
authorization endpoint to the browser JS in a fragment.



You have several extra round trips for no security benefit.   In your case the 
code in the query parameter goes from the browser to the redirect endpoint then 
must be sent back to the browser, and then to the token endpoint.



So yes using code for that is less secure.



Both rely solely on the registered redirect URI for security, but implicit has 
fewer hopes and is more friendly to JS.



John B.

On Feb 9, 2015, at 5:50 PM, Bill Burke 
 wrote:



If you don't have a client secret, why is Javascript-based auth code grant flow 
more risky?  We also require SSL and valid redirect URI patterns to be 
registered for the application.  The code can only ever be sent to spe

[OAUTH-WG] Open redirect blog post

[Antonio Sanso]

FYI
http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html

thanks 

antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] redircet_uri matching algorithm

[Antonio Sanso]

On May 21, 2015, at 4:35 AM, John Bradley  wrote:

> I think the correct answer is that clients should always assume exact 
> redirect_uri matching, and servers should always enforce it.  
> 
> Anything else is asking for trouble.

FWIW I completely agree with John here…

regards

antonio


> 
> If clients need to maintain some state the correct thing to do is use the 
> state parameter, and not append extra path or query elements to there 
> redirect_uri.
> 
> A significant number of security problems in the wild come from servers not 
> enforcing this.
> 
> I may be taking an excessively hard line, but partial matching is not 
> something we should be encouraging by making easier.
> 
> I did do a draft on a way to safely use state 
> https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt
> 
> John B.
> 
> 
>> On May 16, 2015, at 4:43 AM, Patrick Gansterer  wrote:
>> 
>> "OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished and 
>> provides the possibility to register additional “Client Metadata”.
>> 
>> OAuth 2.0 does not define any matching algorithm for the redirect_uris. The 
>> latest information on that topic I could find is [1], which is 5 years old. 
>> Is there any more recent discussion about it?
>> 
>> I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client 
>> metadata. Possible valid values could be:
>> * “exact”: The “redirect_uri" provided in a redirect-based flow must match 
>> exactly one of of the provided strings in the “redirect_uris” array.
>> * “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”. 
>> (e.g. "http://example.com/path/subpath” would be valid with 
>> [“http://example.com/path/“, “http://example.com/otherpath/”])
>> * “regex”: The provided “redirect_uris” are threatened as regular 
>> expressions, which the “redirect_uri” will be matched against. (e.g. 
>> “http://subdomain.example.com/path5/“ would be valid with 
>> [“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“]
>> 
>> If not defined the server can choose any supported method, so we do not 
>> break existing implementations. On the other side it allows an client to 
>> make sure that a server supports a specific matching algorithm required by 
>> the client. ATM a client has no possibility to know how a server handles the 
>> redirect_uris.
>> 
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29
>> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html
>> 
>> --
>> Patrick Gansterer
>> 
>> ___
>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Same Origin Method Execution (SOME)

[Antonio Sanso]

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client 
endpoints due to some common developers pattern 
http://www.benhayak.com/2015/06/same-origin-method-execution-some.html 
(concrete example in 
http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html)

regards

antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Same Origin Method Execution (SOME)

[Antonio Sanso]

hi John

On Jun 25, 2015, at 1:42 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS loaded 
from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other resources 
from the same origin, and it is just coincidence that people are using OAuth.

is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with fullling
the above described need is OAuth. In order to gain access to third-party 
resources
using OAuth, the service shall utilize a third-party endpoint (OAuth dialog) 
that will
ask for the resource owner's approval. The problem with this process is that 
redirecting
the service to an OAuth dialog means losing the content of the currently open 
service
document. For overcoming this problem, developers open a pop-up window to 
display
the dialog in a singular browsing context. Once the user permits or denies 
access to
the service, the OAuth dialog pop-up will be redirected to render a callback 
endpoint
hosted on the service domain. This document should eventually notify the 
service that
the process has been completed.
For the new pop-up window to notify the service window upon approval, denial or 
for
it to transfer access tokens or similar data, developers may implement callback 
endpoints
that use a script referencing the "opener" window for executing a callback 
method of the
service. When developers also opted for providing the service with the decision 
on how
to "call it back" through a callback parameter, the entire domain becomes 
vulnerable to
SOME."

regards

antonio

[0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf


Understanding if there is any Oauth specific advice to give would be helpful.   
I see there are ways to prevent the SOME exploit.

Regards
John B.


On Jun 24, 2015, at 4:18 PM, Antonio Sanso 
mailto:asa...@adobe.com>> wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client 
endpoints due to some common developers pattern 
http://www.benhayak.com/2015/06/same-origin-method-execution-some.html 
(concrete example in 
http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html)

regards

antonio
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] invalid_scope in access token request

[Antonio Sanso]

hi Aaron

On Jul 7, 2015, at 6:23 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

Section 5.2 lists the possible errors the authorization server can return for 
an access token request. In the list is "invalid_scope", which as I understand 
it, can only be returned for a "password" or "client_credentials" grant, since 
scope is not a parameter of an "authorization_code" grant.

why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1


 scope
 OPTIONAL.  The scope of the access request as described by
 Section 3.3.

regards

antonio


Because of this, I believe the phrase "or exceeds the scope granted by the 
resource owner." is unnecessary, since there is no initial grant by the 
resource owner. Am I reading this correctly, or is there some situation I am 
not thinking of? Thanks!


Aaron Parecki
aaronparecki.com
@aaronpk

___
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

Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86

[Antonio Sanso]

hi,

nice to see some work on this topic by the way!

Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

Thanks for the review Erik,

We will go through it in detail and get back to you.

I am working with a couple of governments on how a eID app could use the self 
issued profile of OpenID Connect to issue tokens.

There are also other out of band authentication  apps that people use that need 
to be considered.

I think that the callback / redirect_uri can work if a custom scheme URI or a 
app claimed https: URI is used.

Is there any example of “popular” custom scheme. One I have seen is 
urn:ietf:wg:oauth:2.0:oob
Another common redirect_uri for native app I have seen is http://localhost

One more comment. I strongly suggest  for mobile app to have a really strict 
consent screen policy.
Aka the authorization server MUST show the consent screen at every usage and 
not remember the fact that the app has been already authorized.

Just my 2 cents :)

regards

antonio


I agree that sniffing the URI in a web view creates a very confusing user 
experience at the moment.  It works better on Android than iOS 8 but is not 
smooth in many cases.

I personally use a out of band mobile authenticator for my enterprise login 
that has exactly that problem, and requires me to manually switch back to the 
calling app.

Regards
John B.




On Jul 24, 2015, at 12:59 AM, Erik Wahlström 
mailto:e...@wahlstromstekniska.se>> wrote:


Hi,

Thanks for a great document! I volunteered to review 
draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go:


In national mobile eID deployments an app is issued by gov or other 
organisation in a country. The app acts as the users authentication method and 
it works with an IDP, the IDP can be anywhere if its an PKI token or at the 
place that issued the credential if it’s something else. When an SP start 
developing an native app for there services and want’s to use the national eID 
solution in combination with OAuth we might run into trouble here.

The flow is like follows for a service provider called FooBar:

FooBar’s app starts browser-view. FooBar’s SAML service provider functionality 
redirects the user to an national SAML IDP. The IDP prompts user for a username 
and then starts an mobile eID token on the same phone. Users is asked if they 
want’s to authenticate to FooBar and enters PIN. User are then redirected back 
with an assertion. The FooBar's service provider verifies the assertion and 
mint’s OAuth2 token(s) and redirects the user back to the app with the help of 
the redirect URL.

So the phone first displays an app, then foobar.com in 
browser-view, then idp.com in browser-view, then 
mobile eID token, then idp.com in the system browser 
and back to foobar.com and the app that the user wanted to 
use.

The problem with browser-views is that the mobile eID token will start 
idp.com when user has authenticated and then the user is not 
back in the apps browser-view, but in system browser instead. The system 
browser is sharing the session with the browser-view and redirect the user to 
the native app. The user experience will be a bit strange then because there 
the correct page is not loaded and the browser-view should be closed and the 
app should start parsing out the authorization code instead.

So I think draft should mention something about this scenario and that app 
developers should handle this scenario in the app. The grant did not really 
come back from the browser-view as expected but from the system browser instead.

—

With the above in mind. Maybe even some example code would be nice to have in 
the non normative section "Appendix A.  Operating System Specific 
Implementation Details”. Especially how to handle call backs.

—

Another eID related issue is the pricing model for authentications in that 
market segment. It’s really common by the eID credential issuing organisations 
to charge a service providers usage of a credential per tick (that is by OSCP 
call). The system is based on a per tick pricing model and there are 
regulations for how long the sessions can live. That means that its not 
possible to authenticate with a token once and then create a refresh token and 
the user will ever see the authentication flow again. It kinda messes up the 
usability of mobile apps a lot but end users have come to term with it. They 
have not however came to term to always require consents every time they use 
the app. That drives end user crazy. The usability would be much better if the 
payment model also accepted a refresh token as a tick instead of just an OSCP 
call, but we are not there yet.

Anyway, that’s the backstory. The section "6.4.  Always Prompting for User 
Interaction” is a bit harsh with a SHOULD NOT. I would rather change it to a 
NOT RECOMME

Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86

[Antonio Sanso]

hi,

let me give you an example of what is my concern.
I admit this example is a bit extreme but still
As said one popular redirect_uri used by mobile app is http://localhost.

Let’s also say a resource owner use this mobile app the first time and approve 
the consent screen and so forth….

It also turn out this resource owner is a developer :) and it runs one 
application on its own computer.
This application runs as well on localhost.
Now, and as said this assumption is a bit extreme, this application has as well 
some open redirector and http://localhost?goto=http://evil.com redirect to 
evil.com<http://evil.com>

Well you can do your maths now and see that having a consent screen now would 
prevent such a threat

For the record some less popular custom redirect uri used for mobile I have 
seen is also data: so also this might be “at risk"

regards

antonio

On Jul 24, 2015, at 1:16 PM, Paul Madsen 
mailto:paul.mad...@gmail.com>> wrote:

Antonio, are you arguing for short token lifetimes and so frequent explicit 
consent ? or something more

if the app has a valid refresh token then there is no opportunity for the AS to 
inject a consent screen

paul

On 7/24/15 3:00 AM, Antonio Sanso wrote:
hi,

nice to see some work on this topic by the way!

Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

Thanks for the review Erik,

We will go through it in detail and get back to you.

I am working with a couple of governments on how a eID app could use the self 
issued profile of OpenID Connect to issue tokens.

There are also other out of band authentication  apps that people use that need 
to be considered.

I think that the callback / redirect_uri can work if a custom scheme URI or a 
app claimed https: URI is used.

Is there any example of “popular” custom scheme. One I have seen is 
urn:ietf:wg:oauth:2.0:oob
Another common redirect_uri for native app I have seen is 
http://localhost<http://localhost/>

One more comment. I strongly suggest  for mobile app to have a really strict 
consent screen policy.
Aka the authorization server MUST show the consent screen at every usage and 
not remember the fact that the app has been already authorized.

Just my 2 cents :)

regards

antonio


I agree that sniffing the URI in a web view creates a very confusing user 
experience at the moment.  It works better on Android than iOS 8 but is not 
smooth in many cases.

I personally use a out of band mobile authenticator for my enterprise login 
that has exactly that problem, and requires me to manually switch back to the 
calling app.

Regards
John B.




On Jul 24, 2015, at 12:59 AM, Erik Wahlström 
mailto:e...@wahlstromstekniska.se>> wrote:


Hi,

Thanks for a great document! I volunteered to review 
draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go:


In national mobile eID deployments an app is issued by gov or other 
organisation in a country. The app acts as the users authentication method and 
it works with an IDP, the IDP can be anywhere if its an PKI token or at the 
place that issued the credential if it’s something else. When an SP start 
developing an native app for there services and want’s to use the national eID 
solution in combination with OAuth we might run into trouble here.

The flow is like follows for a service provider called FooBar:

FooBar’s app starts browser-view. FooBar’s SAML service provider functionality 
redirects the user to an national SAML IDP. The IDP prompts user for a username 
and then starts an mobile eID token on the same phone. Users is asked if they 
want’s to authenticate to FooBar and enters PIN. User are then redirected back 
with an assertion. The FooBar's service provider verifies the assertion and 
mint’s OAuth2 token(s) and redirects the user back to the app with the help of 
the redirect URL.

So the phone first displays an app, then foobar.com<http://example.com/> in 
browser-view, then idp.com<http://nationalidp.com/> in browser-view, then 
mobile eID token, then idp.com<http://nationalidp.com/> in the system browser 
and back to foobar.com<http://example.com/> and the app that the user wanted to 
use.

The problem with browser-views is that the mobile eID token will start 
idp.com<http://idp.com/> when user has authenticated and then the user is not 
back in the apps browser-view, but in system browser instead. The system 
browser is sharing the session with the browser-view and redirect the user to 
the native app. The user experience will be a bit strange then because there 
the correct page is not loaded and the browser-view should be closed and the 
app should start parsing out the authorization code instead.

So I think draft should mention something about this scenario and that app 
developers should handle this scenario in the app. The grant did not really 
come back from the browser-view as expected but from the 

Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

[Antonio Sanso]

hi,

same here. I have the same recollection of the meeting in Darmstadt as Brian. I 
do appreciate the draft of Mike (kudos to him) and his will to steer toward the 
consensus.

regards

antonio

On Jan 13, 2016, at 5:31 AM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:

I am in agreement with Brian.

I understand what Mike is trying to do is safer, but I too am concerned that 
the escalation in knowledge/skills for oauth clients is significant.

This may not be the same concern as for OIDC where we can expect more 
sophistication.

Phil

On Jan 12, 2016, at 20:03, Justin Richer 
mailto:jric...@mit.edu>> wrote:

+1 to Brian’s point, and points to Mike for promising to address this. I wasn’t 
able to attend the meeting in Darmstadt, but I’ve been following the discussion 
and original papers. Let’s take this one piece at a time and not overreach with 
a solution.

In particular, the whole “late binding discovery” bit would cause huge problems 
on its own. There’s good reason that OpenID Connect mandates that the “iss” 
value returned from the discovery endpoint MUST be the same as the “iss” value 
coming back from the ID Token, so let’s not ignore that.

 — Justin

On Jan 12, 2016, at 5:53 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

John Bradley and I went over this today and I'm already planning on simplifying 
the draft along the lines described. I would have written this earlier but I've 
been busy at a NIST meeting today.

John has also stated writing a note about how cut-and-paste does and doesn't 
apply here but hasn't finished it yet because he's been similarly occupied.  
He's also started writing up the state_hash token request parameter, as he 
agreed to do.

Watch this space for the new draft...

Best wishes,
-- Mike

From: Brian Campbell
Sent: ‎1/‎12/‎2016 5:24 PM
To: oauth
Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on 
them) take advantage of the fact that there's nothing in the OAuth 
authorization response to the client's redirect_uri that identifies the 
authorization server. As a result, a variety of techniques can be used to trick 
the client into sending the code (or token in some cases) to the wrong endpoint.

To the best of my recollection the general consensus coming out of the meetings 
in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization 
Server 
Mix-Up)
 was to put forth an I-D as a simple extension to OAuth, which described how to 
return an issuer identifier for the authorization server and client identifier 
as authorization response parameters from the authorization endpoint. Doing so 
enables the client to know which AS the response came from and thus avoid 
sending the code to a different AS. Also, it doesn't introduce 
application/message level cryptography requirements on client implementations.

The mitigation draft that was posted 
yesterday 
diverges considerably from that with a significantly expanded scope that 
introduces OpenID Connect ID Tokens (sort of anyway) to regular OAuth and the 
retrieval of a metadata/discovery document in-between the authorization request 
and the access token request.

It is possible that my recollection from Darmstadt is wrong. But I expect 
others who were there could corroborate my account of what transpired. Of 
course, the agreements out of the Darmstadt meeting were never intended to be 
the final word - the whole WG would have the opportunity to weigh, as is now 
the case. However, a goal of meeting face-to-face was to come away with a good 
consensus towards a proposed solution that could (hopefully) be implementable 
in the very near term and move thought the IETF process in an expedited manner. 
I believe we'd reached consensus but the content of -00 draft does not reflect 
it.

I've made the plea off-list several times to simplify the draft to reflect the 
simple solution and now I'm doing the same on-list. Simplify the response 
validation to just say not to send the code/token back to an AS entity other 
that the one identified by the 'iss' in the response. And remove the id_token 
and JWT parts that .

If this WG and/or the larger community believes that OAuth needs signed 
responses, let's develop a proper singed response mechanism. I don't know if 
it's needed or not but I do know that it's a decent chunk of work that should 
be conscientiously undertaken independent of what can and should be a simple to 
understand and implement fix for the idp mix-up problem.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAut

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

[Antonio Sanso]

+1 for adoption
On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig  
wrote:

> Hi all,
> 
> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
> 
> Please let us know by Feb 9th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> 
> Note: This call is related to the announcement made on the list earlier
> this month, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
> time for analysis is provided due to the complexity of the topic.
> 
> Ciao
> Hannes & Derek
> 
> ___
> 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

Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

[Antonio Sanso]

+1 for adoption. I do really think this fills a current gap.

regards

antonio
On Jan 19, 2016, at 12:46 PM, Hannes Tschofenig  
wrote:

> Hi all,
> 
> this is the call for adoption of OAuth 2.0 for Native Apps, see
> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
> 
> Please let us know by Feb 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> 
> Note: If you already stated your opinion at the IETF meeting in Yokohama
> then you don't need to re-state your opinion, if you want.
> 
> The feedback at the Yokohama IETF meeting was the following: 16 persons
> for doing the work / 0 persons against / 2 persons need more info
> 
> Ciao
> Hannes & Derek
> 
> ___
> 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

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

[Antonio Sanso]

+1 for adoption
On Jan 19, 2016, at 12:47 PM, Hannes Tschofenig  
wrote:

> Hi all,
> 
> this is the call for adoption of OAuth 2.0 Security: OAuth Open
> Redirector, see
> https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02
> 
> Please let us know by Feb 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> 
> Note: At the IETF Yokohama we asked for generic feedback about doing
> security work in the OAuth working group and there was very positive
> feedback. However, for the adoption call we need to ask for individual
> documents. Hence, you need to state your view again.
> 
> Ciao
> Hannes & Derek
> 
> 
> 
> 
> ___
> 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

Re: [OAUTH-WG] Call for Adoption

[Antonio Sanso]

hi John,

if you remember I even proposed something along those lines in Darmstadt and it 
was deemed (with reason) as not enough good protection since the attacker can 
use a proxy….

regards

antonio

On Jan 27, 2016, at 2:30 PM, John Bradley  wrote:

> It think requiring a common authority segment for the authorization endpoint 
> and the token endpoint might work in common cases, but there are legitimate 
> cases where the URI of the Authorization endpoint might be a alias in the 
> case of multi tenants, all using a common token endpoint.
> 
> The larger problem would be the RS, it is not uncommon to have the AS and RS 
> in different domains,  so with bearer tokens unless you make the same 
> authority restriction for RS then you are not really stoping the attacker.   
> They can get the AT by impersonating the RS.
> 
> I think trying to enforce a common origin policy over OAuth would be a bad 
> direction to go.
> 
> I understand that it seems like a easy fix on the surface, and it works for 
> most of the things people are using OAuth for today, but would be quite 
> limiting over the long term.
> 
> John B.
>> On Jan 27, 2016, at 7:31 AM, sakim...@gmail.com wrote:
>> 
>> Hi Hans,
>> 
>> Sorry, I mixed up the IdP mix-up attack and the code phishing attack.
>> 
>> Mandating the Authorization and Token Endpoint being in the same
>> authority would solve the later without changing the wire protocol.
>> 
>> For AS mix-up attack, mandating the client to change the redirection endpoint
>> per AS would solve the problem without change the wire protocol.
>> 
>> If these are not possible, then we would have to look at changing the
>> wire protocol. The solution that solves the both cases must
>> provide the token endpoint URI authoritatively, which means
>> you have to mandate some variation of discovery mandatory.
>> 
>> Nat
>> 
>> 
>> At 2016-01-27 17:01  Hans Zandbelt wrote:
>>> I don't see how that can deal with the specific form of the attack
>>> where the Client would have sent the authorization request to the
>>> legitimate authorization endpoint of a compromised AS and believes it
>>> gets the response from that, where in fact it was redirected away to
>>> the good AS.
>>> IOW, I don't think this is so much about mixing up endpoints where to
>>> send stuff to, but mixing up the entity/endpoint from which the Client
>>> believes the response was received. That may just be terminology
>>> though.
>>> Bottom line as far as I see is that a wire protocol element in the
>>> response is needed to tell the Client who issued it, regardless of how
>>> the Client deals with configuration of the AS information.
>>> Hans.
>>> On 1/27/16 1:31 AM, Nat Sakimura wrote:
 So, is there a lot of cases that the authority section of the Good AS's
 Authorization Endpoint and the Token Endpoints are different?
 If not, then requiring that they are the same seems to virtually remove
 the attack surface for the mix-up related attacks. It does not introduce
 new parameter nor discovery. If it can be done, it probably is not worth
 adding a new wire protocol element to mitigate the mix-up variants.
>> 
>> 
>> ___
>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Antonio Sanso]

hi,

FWIW I also find Option A easier to understand/implement.

regards

antonio

On Feb 19, 2016, at 8:42 PM, Hannes Tschofenig  
wrote:

> Early February I posted a mail to the list to make progress on the
> solution to the OAuth Authorization Server Mix-Up problem discovered
> late last year.
> 
> Here is my mail about the Authorization Server Mix-Up:
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
> 
> Here is my mail to the list that tries to summarize the discussion
> status and asked a few questions:
> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
> 
> Unfortunately, my mail didn't lead to the intended success. While there
> was some feedback I wasn't getting the desired response.
> 
> In order to move forward I believe we need a working group document that
> serves as a starting point for further work in the group*. We have two
> documents that provide similar functionality in an attempt to solve the
> Authorization Server Mix-Up problem.
> 
> So, here is the question for the group. Which document do you want as a
> starting point for work on this topic:
> 
> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley
> 
> Link:
> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
> 
> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
> Sascha Preibisch
> 
> Link:
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
> 
> Deadline for feedback is March, 4th.
> 
> Ciao
> Hannes & Derek
> 
> PS: (*) Regardless of the selected solution we will provide proper
> acknowledgement for those who contributed to the work.
> 
> ___
> 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

Re: [OAUTH-WG] JWS Access Token concerns

[Antonio Sanso]

hi Sergey,
just my 2 cents
let’s start from a simple fact that encryption is not authentication. :)

Now, if the claim sets of a JWS contains only not confidential information JWS 
is enough.

See also inline


On Feb 23, 2016, at 6:15 PM, Sergey Beryozkin  wrote:

> Hi
> 
> Some OAuth2 providers may return self-contained access tokens which are JWS 
> Compact-encoded.
> I wonder is it really a good idea and would it not be better to only 
> JWE-encrypt the tokens. I'm not sure JWS signing the claims is necessarily 
> faster then only encrypting the claims, assuming the symmetric algorithms are 
> used in both cases.

JWE algorithms are all AEAD AFAIK so is not only symmetric encryption plus 
there is the content key  "wrap algorithm”.

regards

antonio

> 
> For example, my colleague and myself, while dealing with the issue related to 
> parsing an access token response from a 3rd party provider were able to 
> easily check the content of the JWS-signed access_token by simply submitting 
> an easily recognized JWS Compact-formatted value (3 dots) into our JWS reader 
> - we did not have to worry about decrypting it neither the fact we did not 
> validate the signature mattered.
> 
> But access tokens are opaque values as far as the clients are concerned and 
> if the introspection is needed then the introspection endpoint does exist for 
> that purpose...
> 
> Thanks, Sergey
> 
> 
> 
> ___
> 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

[OAUTH-WG] Some recent FUD about OAuth

[Antonio Sanso]

Just sharing, do not shoot the messenger :)

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

and  companion website:

http://no-oauth.insanecoding.org/

regards

antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Some recent FUD about OAuth

[Antonio Sanso]

hi Hans,

indeed I found this article technically inaccurate and it annoyed me quite a 
bit…

regards

antonio

On Apr 11, 2016, at 9:26 AM, Hans Zandbelt  wrote:

> "JWT is a specification for allowing SSO or API usage between services. In 
> many ways JWT is like SAML"
> 
> makes me stop trying to parse/understand the rest of it
> 
> Hans.
> 
> On 4/11/16 9:04 AM, Antonio Sanso wrote:
>> Just sharing, do not shoot the messenger :)
>> 
>> http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
>> 
>> and  companion website:
>> 
>> http://no-oauth.insanecoding.org/
>> 
>> regards
>> 
>> antonio
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> -- 
> Hans Zandbelt  | Sr. Technical Architect
> hzandb...@pingidentity.com | Ping Identity

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Antonio Sanso]

hi Daniel

On Apr 22, 2016, at 4:20 PM, Daniel Fett  wrote:

> Hi all,
> 
> During our formal analysis of OAuth we found an attack that allows
> CSRF. It is similar to the "code" leak described by Homakov in [1] and
> therefore not really surprising. In this attack, the intention for an
> attacker is to steal the "state" value instead of the "code" value.
> 
> Setting:
> 
> In the auth code grant, after authentication to the AS, the user is
> redirected to some page on the Client. If this page leaks the
> referrer, i.e., there is a link to the attacker's website or some
> resource is loaded from the attacker, then the attacker can see not
> only code but also state in the Referer header of the request.
> 
> The fact that code can leak was described in [1]. Since code is
> single-use, it might be already redeemed in most cases when it is sent
> to the attacker.

probably is not redeemed instead, just because the redirect_uri is not the 
correct one.
The mitigation that good implemented AS use (also Github) is to follow section 
4.1.3 the OAuth core specification [RFC6749], in particular:

"ensure that the "redirect_uri" parameter is present if the "redirect_uri" 
parameter was included in the initial authorization request as described in 
Section 4.1.1, and if included ensure that their values are identical."

regards

antonio


> State, however, is not limited to a single use (by 6749 or others) and
> therefore can be used by the attacker to mount a CSRF attack and
> inject his own code into a (new) auth code grant.
> 
> We suggest
> a) making state single use, and
> b) highlighting to developers the importance of non-leaky redirection
> endpoints, and to this end
> c) recommending the use of "referrer policies" [2] to mitigate such attacks.
> 
> Could somebody confirm whether this attack is new?
> 
> Cheers,
> Daniel, Guido, and Ralf
> 
> [1] http://homakov.blogspot.de/2014/02/how-i-hacked-github-again.html
> [2] https://w3c.github.io/webappsec-referrer-policy/
> -- 
> Informationssicherheit und Kryptografie
> Universität Trier - Tel. 0651 201 2847 - H436
> 
> ___
> 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

Re: [OAUTH-WG] State Leakage Attack

[Antonio Sanso]

hi Daniel

On Apr 22, 2016, at 4:35 PM, Daniel Fett 
mailto:f...@uni-trier.de>> wrote:

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

probably is not redeemed instead, just because the redirect_uri is not the 
correct one.
The mitigation that good implemented AS use (also Github) is to follow section 
4.1.3 the OAuth core specification [RFC6749], in particular:

"ensure that the "redirect_uri" parameter is present if the "redirect_uri" 
parameter was included in the initial authorization request as described in 
Section 4.1.1, and if included ensure that their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

right. so is not really [1] :) since there there is manipulation using /../../
Now the real question why a legit redirect_uri should contain links to 
malicious external resources?

regards

antonio

[1] http://homakov.blogspot.ch/2014/02/how-i-hacked-github-again.html


- Daniel



--
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Antonio Sanso]

On Apr 22, 2016, at 4:42 PM, Daniel Fett 
mailto:f...@uni-trier.de>> wrote:

Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
hi Daniel

On Apr 22, 2016, at 4:35 PM, Daniel Fett 
mailto:f...@uni-trier.de>
<mailto:f...@uni-trier.de>> wrote:

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

probably is not redeemed instead, just because the redirect_uri is
not the correct one.
The mitigation that good implemented AS use (also Github) is to
follow section 4.1.3 the OAuth core specification [RFC6749], in
particular:

"ensure that the "redirect_uri" parameter is present if the
"redirect_uri" parameter was included in the initial authorization
request as described in Section 4.1.1, and if included ensure that
their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

right. so is not really [1] :) since there there is manipulation using
/../../

Of course.

Now the real question why a legit redirect_uri should contain links to
malicious external resources?

Well, why not? :)

Anyway, developers should be made aware that having external
resources/links on these pages is a bad idea.

agree about the awareness.
It is more likely that such a page contains resource/links e.g. in the form of 
http://ajax.googleapis.com/ajax/libs/angularjs/1.2.23/angular.js"</a>;>
 .
In this case IMHO this is more a privacy issue rather than a real security 
threat.

regards

antonio


- Daniel

--
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Antonio Sanso]

hi

On Apr 25, 2016, at 3:01 PM, Daniel Fett  wrote:

> Am 24.04.2016 um 22:31 schrieb John Bradley:
>> I described a similar attack at the meeting in Darmstadt.  Using stolen 
>> state to inject code from a different session.
>> 
>> We were calling that the cut and paste attack.   The proposed mitigation is 
>> ing the draft that Mike and I did.
>> 
>> This was based on the attacker making a new request in a different user 
>> agent and using that state.  
>> 
>> In open redirectors draft we do talk about referrer leaking info, and 
>> methods to address that.
>> 
>> Checking referrer is a weak protection at best, as that is easily faked in 
>> many circumstances.
> 
> Note that we do not propose checking the referrer as a mitigation; we
> propose using the referrer policy (at the client) to suppress the
> referrer (just as in the open redirector draft where it is used at the
> AS). So the recommendation here is to use the referrer policy also at
> the client.

and just as a corollary Internet Explorer doesn’t seem to support the referrer 
policy. Maybe Edge…

regards

antonio

> 
>> Are you saying that the proposed mitigation of the AS tying state to code is 
>> not sufficient?
> 
> Yes, it is not sufficient as an attacker can request a new code for his
> own account at the AS for the same state.
> 
> (Note that from draft-bradley-oauth-jwt-encoded-state-05 it does not
> become clear how the JTI value comes into play here; you should probably
> add some clarification on generating this value and how to check it. An
> example would be good.)
> 
> -Daniel
> 
> -- 
> Informationssicherheit und Kryptografie
> Universität Trier - Tel. 0651 201 2847 - H436
> 
> ___
> 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

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

[Antonio Sanso]

hi,

FWIW Facebook is not the only one here.
Many OAuth provider do not do exact matching redirect uri validation. Github 
for example is another….

regards

antonio

On May 10, 2016, at 10:23 AM, Daniel Fett 
mailto:f...@uni-trier.de>> wrote:

It does not work if the AS does not check the redirect URI completely.
Facebook being the main example here, and I guess they won't change this
soon (for backwards compatibility). Adding the iss parameter won't break
things.

-Daniel

Am 09.05.2016 um 05:45 schrieb Nat Sakimura:
Hi Daniel,

May I ask again why separate redirect uri would not work for mix-up?
(I know, it does not work for cut-n-paste.)

Thanks,

Nat

2016年5月5日(木) 23:28 Daniel Fett mailto:f...@uni-trier.de>
>:

   Am 23.04.2016 um 13:47 schrieb Torsten Lodderstedt:
I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId
   Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id!
   tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both
   threats.

https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are
   alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside
   state for
counter XSRF)

From our formal analysis of OAuth we are pretty confident that the
   mitigation proposed in draft-ietf-oauth-mix-up-mitigation-00 should be
   sufficient against the Mix-Up attack.

   Cheers,
   Daniel


   --
   Informationssicherheit und Kryptografie
   Universität Trier - Tel. 0651 201 2847 - H436

   ___
   OAuth mailing list
   OAuth@ietf.org 
   https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative


--
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
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

Re: [OAUTH-WG] OAuth Security Workshop: Call for Participation

[Antonio Sanso]

hi Daniel,
On Jun 17, 2016, at 1:44 PM, Daniel Fett  wrote:

> Call for Participation
> 
> OAuth Security Workshop 2016
> University of Trier
> Trier, Germany
> July 14-15, 2016
> 
> The workshop program and further information is available on the
> workshop website:
> 
>https://infsec.uni-trier.de/events/osw2016
> 
> * Registration is open until: July 24th, 2016 *

did you mean Registration is open until: June 24th, 2016 * ? :)
> 
> The OAuth Security Workshop (OSW) brings together the IETF OAuth Working
> Group and security experts from research, industry, and standardization
> to improve the security of OAuth and related Internet protocols. The
> workshop is hosted by the Chair for Information Security and
> Cryptography at the University of Trier.
> 
> 
> Invited Speakers
> 
> 
>Karthikeyan Bhargavan (INRIA Paris-Rocquencourt)
>Andrey Labunets (Facebook)
> 
> ___
> 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

[OAUTH-WG] Critical vulnerability in JSON Web Encryption (#JWE) - RFC 7516 Invalid Curve Attack

[Antonio Sanso]

hi *,

sorry for cross posting with the jose mailing list

http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html

regards

antonio
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] More Criticism of JOSE

[Antonio Sanso]

hi Mike,

while I am the original author of one of the mentioned article in the blog post 
(http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html)
 I do not share entirely the criticism.
Said that, I must really admit that some of the cryptographic choices made 
specially in JWE are really questionable.

regards

antonio

On Mar 15, 2017, at 8:50 PM, Mike Jones  wrote:

> The bulk of this seems to be about applications that don't verify that the 
> crypto algorithms that were used in a JWT are acceptable in the application 
> context.  While I know that some people would like crypto to be magic pixie 
> dust that you can sprinkle on an application to get crypto goodness, it will 
> never be that simple.  Crypto algorithms that are thought to be good today 
> will be deprecated later.  Apps that keep allowing them to be used will be 
> vulnerable.  The JOSE specs requiring that applications be aware of the 
> algorithms used is a good and necessary thing for long-term security - not a 
> problem with the specs.
> 
> That said, of course some implementers will get things wrong.  To the extent 
> that we can help them understand what they actually need to do to use the 
> specifications securely, we obviously should.  Perhaps we should write an 
> article for oauth.net talking about some of these issues?  Maybe a few of us 
> can get together in Chicago and work on that.
> 
> I'm looking forward to seeing many of you in 1.5 weeks!
> 
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Sergey Beryozkin
> Sent: Wednesday, March 15, 2017 8:46 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] More Criticism of JOSE
> 
> and everyone should now start using the most secure alternative proposed in 
> that very light in analysis article :-)
> 
> Sergey
> On 15/03/17 15:43, Mike Schwartz wrote:
>> Sorry to be the bearer of bad news, but here's a negative review of JOSE:
>> 
>> JOSE (Javascript Object Signing and Encryption) is a Bad Standard That 
>> Everyone Should Avoid
>> 
>> https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard
>> -that-everyone-should-avoid
>> 
>> 
>> - Mike
>> 
>> ___
>> 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
> 
> ___
> 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

Re: [OAUTH-WG] More Criticism of JOSE

[Antonio Sanso]

hi Mike

On Mar 15, 2017, at 10:06 PM, Mike Jones  wrote:

> Will you be in Chicago, Antonio?  If so, maybe you can sit down with us and 
> work on advice to implementers.

Unluckily not. FWIW I will be at 
https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/. And I’d be glad to sit 
down with you and try to help if you are around….

regards

antonio


> 
>   Cheers,
>   -- Mike
> 
> -Original Message-
> From: Antonio Sanso [mailto:asa...@adobe.com] 
> Sent: Wednesday, March 15, 2017 1:40 PM
> To: Mike Jones 
> Cc: Sergey Beryozkin ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] More Criticism of JOSE
> 
> hi Mike,
> 
> while I am the original author of one of the mentioned article in the blog 
> post 
> (http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html)
>  I do not share entirely the criticism.
> Said that, I must really admit that some of the cryptographic choices made 
> specially in JWE are really questionable.
> 
> regards
> 
> antonio
> 
> On Mar 15, 2017, at 8:50 PM, Mike Jones  wrote:
> 
>> The bulk of this seems to be about applications that don't verify that the 
>> crypto algorithms that were used in a JWT are acceptable in the application 
>> context.  While I know that some people would like crypto to be magic pixie 
>> dust that you can sprinkle on an application to get crypto goodness, it will 
>> never be that simple.  Crypto algorithms that are thought to be good today 
>> will be deprecated later.  Apps that keep allowing them to be used will be 
>> vulnerable.  The JOSE specs requiring that applications be aware of the 
>> algorithms used is a good and necessary thing for long-term security - not a 
>> problem with the specs.
>> 
>> That said, of course some implementers will get things wrong.  To the extent 
>> that we can help them understand what they actually need to do to use the 
>> specifications securely, we obviously should.  Perhaps we should write an 
>> article for oauth.net talking about some of these issues?  Maybe a few of us 
>> can get together in Chicago and work on that.
>> 
>> I'm looking forward to seeing many of you in 1.5 weeks!
>> 
>>  -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Sergey 
>> Beryozkin
>> Sent: Wednesday, March 15, 2017 8:46 AM
>> To: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] More Criticism of JOSE
>> 
>> and everyone should now start using the most secure alternative 
>> proposed in that very light in analysis article :-)
>> 
>> Sergey
>> On 15/03/17 15:43, Mike Schwartz wrote:
>>> Sorry to be the bearer of bad news, but here's a negative review of JOSE:
>>> 
>>> JOSE (Javascript Object Signing and Encryption) is a Bad Standard 
>>> That Everyone Should Avoid
>>> 
>>> https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standar
>>> d
>>> -that-everyone-should-avoid
>>> 
>>> 
>>> - Mike
>>> 
>>> ___
>>> 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
>> 
>> ___
>> 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

Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

[Antonio Sanso]

hi Torsten,

good one. I personally I am looking forward to see this particular document 
find its way.

IMHO this is something much needed.

regards

antonio

On Mar 21, 2017, at 2:08 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:

Hi Chairs,

I would like to request 5 minutes on Monday to briefly present the status of 
the security document. This is mainly to raise awareness in the group since I 
didn’t get that much input on it since Seoul.

kind regards,
Torsten.

Am 18.03.2017 um 01:52 schrieb Mike Jones 
mailto:michael.jo...@microsoft.com>>:

Hi Chairs,

I'd like to request that the following presentations be added to the agenda:

OAuth Token Exchange (draft-ietf-oauth-token-exchange) - Mike Jones - 15 minutes
OAuth Authorization Server Metadata (draft-ietf-oauth-discovery) - Mike Jones - 
15 minutes

I'd also talked with Brian Campbell and I think he wants to lead this 
discussion, in part based on his implementation experience:

OAuth Token Binding (draft-ietf-oauth-token-binding) - Brian Campbell - 30 
minutes

(Brian may suggest a different amount of time)

I agree that William Dennis should present about the OAuth Device Flow 
(draft-ietf-oauth-device-flow).

For completeness, I don't think a presentation is needed about OAuth AMR Values 
(draft-ietf-oauth-amr-values) because it's now completed its IESG review.

I'll look forward to seeing many of you in just over a week!

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of "IETF Secretariat"
Sent: Friday, March 3, 2017 3:55 PM
To: oauth-cha...@ietf.org; 
smccam...@amsl.com
Cc: oauth@ietf.org
Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

Dear Stephanie McCammon,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by the original request.

oauth Session 1 (2:30:00)
  Friday, Morning Session I 0900-1130
  Room Name: Zurich C size: 100
  -
  oauth Session 2 (1:00:00)
  Monday, Afternoon Session III 1710-1810
  Room Name: Zurich C size: 100
  -



Request Information:


-
Working Group Name: Web Authorization Protocol Area Name: Security Area Session 
Requester: Stephanie McCammon

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour Number of Attendees: 50 Conflicts to 
Avoid:
First Priority: saag core tls tokbind




People who must be present:
Hannes Tschofenig
Kathleen Moriarty
Derek Atkins

Resources Requested:
Projector in room

Special Requests:
Please avoid conflict with sec area BoFs.
-

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463068122&sdata=5CIJnWs2VdLM9FUWt%2FWlOxIilp5N2vfr7b9elwhL%2BA4%3D&reserved=0

___
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

[Antonio Sanso]

Hi Torsten,


nice one. FWIW I am reallly happy to see this happening.

Quick question though. What is the recommendation about dealing with the client 
secret in this situation?


regards


antonio


From: OAuth  on behalf of Torsten Lodderstedt 

Sent: Sunday, November 25, 2018 6:32:53 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

Hi all,

I would like to state again what the proposal of the authors of the Security 
BCP is:

Here is the respective text from the draft:

——

2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2, Section 3.3, 
and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.
——

In my observation, discouraging implicit seems to be the less controversial 
issue.

„or any other response type causing the authorization server to issue an access 
token in the authorization response.“ in the 3rd paragraph caused discussions 
because it suggests to discourage developers from using ANY response type 
issuing access tokens in the authorization response. This includes OIDC’s 
response types „token id_token“, „code token“ & „code token id_token“, where at 
least  „token id_token“ is used in the wild to implement SPAs.

Why did we come up with this proposal given at least „token id_token“ & „code 
token id_token“ protect against injection?

Two reasons:

1) „token id_token“ does not support sender constrained tokens. Also use of 
refresh tokens to frequently issue new live-time and privilege restricted 
access tokens is not supported. „code token id_token“ seems more complex than 
just „code“+pkce for achieving the same goal.

2) Protection against token leakage is rather thin and fragile. There is just a 
single line of defense (CSP, open redirection prevention, browser history 
manipulation) implemented by the client.

Daniel and I collected some more information and argument at 
https://github..com/tlodderstedt/oauth2_spa/blob/master/README.md that you 
might like to give a read.

My conclusion after 2 weeks of intensive discussions with SPA developers 
(mostly on twitter): code+pkce is the more secure, simpler, and more versatile 
approach to (also) implement SPAs. I prefer to approach developers with a clean 
and robust message instead of a lengthy description of what needs to go right 
in order to secure a SPA using OAuth. That’s why I think code+pkce should be 
the recommendation of our working group.

So please vote in favor of our proposal. I think that’s a huge improvement for 
OAuth.

kind regards,
Torsten.


> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt :
>
> I strongly support the recommendation of using code instead of implicit. I do 
> so based on my own experience in the field [1] and stick to that also after 
> reading the comments and (what I would call) workarounds on this thread.
>
> Hans.
>
> [1] 
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
>
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt  
> wrote:
> that’s certainly true, but that might by a web server with static content 
> only.
>
> If the server is a real backend, there is even less reasons to use a implicit 
> or hybrid. No even a performance gain in comparison to code.
>
> Am 21..11.2018 um 14:24 schrieb George Fletcher :
>
>> An SPA has a backend because it has to be loaded from somewhere :)
>>
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>>> We had a discussion about this topic on Twitter 
>>> https://twitter.com/Apl3b/status/1064854507606208513
>>>
>>>
>>> Outcome is POST requires a backend to receive the request so it’s not a 
>>> viable solution for SPAs.
>>>
>>>
 Am 20.11.2018 um 23:29 schrieb John Bradley 
 :

 Post response works OK for server based clients.  I don't think POST works 
 for single

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

[Antonio Sanso]

Hi Torsten, thanks it makes sense.

> Do you see a need to add this to the BCP?

Well, while you are on it this might be a good chance to include this IMHO. At 
least it will be a pointer for a question that might pop up quite often.

Regards

antonio

From: Torsten Lodderstedt 
Date: Monday, November 26, 2018 at 10:34 AM
To: Antonio Sanso 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

Hi Antonio,

good point. I would assume most SPAs will be public clients. Even if a single 
instance registers dynamically and obtains a secret, this secret can only be 
used as kind of „same originator“ proof (much like PKCE). SPAs with a backend 
can also make the backend a confidential client. There was a thread about SPAs 
& backends on the list recently.

I would argue this is inline with RFC6749 security considerations. Do you see a 
need to add this to the BCP?

kind regards,
Torsten.


Am 26.11.2018 um 09:18 schrieb Antonio Sanso 
mailto:asa...@adobe.com>>:

Hi Torsten,



nice one. FWIW I am reallly happy to see this happening.

Quick question though. What is the recommendation about dealing with the client 
secret in this situation?



regards



antonio


From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Torsten Lodderstedt mailto:tors...@lodderstedt.net>>
Sent: Sunday, November 25, 2018 6:32:53 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

Hi all,

I would like to state again what the proposal of the authors of the Security 
BCP is:

Here is the respective text from the draft:

——

2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2, Section 3.3, 
and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.
——

In my observation, discouraging implicit seems to be the less controversial 
issue.

„or any other response type causing the authorization server to issue an access 
token in the authorization response.“ in the 3rd paragraph caused discussions 
because it suggests to discourage developers from using ANY response type 
issuing access tokens in the authorization response. This includes OIDC’s 
response types „token id_token“, „code token“ & „code token id_token“, where at 
least  „token id_token“ is used in the wild to implement SPAs.

Why did we come up with this proposal given at least „token id_token“ & „code 
token id_token“ protect against injection?

Two reasons:

1) „token id_token“ does not support sender constrained tokens. Also use of 
refresh tokens to frequently issue new live-time and privilege restricted 
access tokens is not supported. „code token id_token“ seems more complex than 
just „code“+pkce for achieving the same goal.

2) Protection against token leakage is rather thin and fragile. There is just a 
single line of defense (CSP, open redirection prevention, browser history 
manipulation) implemented by the client.

Daniel and I collected some more information and argument at 
https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might 
like to give a read.

My conclusion after 2 weeks of intensive discussions with SPA developers 
(mostly on twitter): code+pkce is the more secure, simpler, and more versatile 
approach to (also) implement SPAs. I prefer to approach developers with a clean 
and robust message instead of a lengthy description of what needs to go right 
in order to secure a SPA using OAuth. That’s why I think code+pkce should be 
the recommendation of our working group.

So please vote in favor of our proposal. I think that’s a huge improvement for 
OAuth.

kind regards,
Torsten.


> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt 
> mailto:hans.