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

day, 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 dy

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

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, Nove

Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

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

Re: [OAUTH-WG] More Criticism of JOSE

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

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

[OAUTH-WG] Critical vulnerability in JSON Web Encryption (#JWE) - RFC 7516 Invalid Curve Attack

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] OAuth Security Workshop: Call for Participation

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

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

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

Re: [OAUTH-WG] State Leakage Attack

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 mit

Re: [OAUTH-WG] State Leakage Attack

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 sch

Re: [OAUTH-WG] State Leakage Attack

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 Ho

Re: [OAUTH-WG] State Leakage Attack

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

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

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

[OAUTH-WG] Some recent FUD about OAuth

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.

Re: [OAUTH-WG] JWS Access Token concerns

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 m

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

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

Re: [OAUTH-WG] Call for Adoption

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 segme

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

+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 / obj

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

+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

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

+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 > ado

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

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

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

n 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 w

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

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

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

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

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

comes 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 P

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

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

Re: [OAUTH-WG] redircet_uri matching algorithm

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

[OAUTH-WG] Open redirect blog post

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] Confusion on Implicit Grant flow

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>

Re: [OAUTH-WG] OAuth Status

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://datatra

[OAUTH-WG] Top 5 OAuth 2 Implementation Vulnerabilities

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] Meeting Minutes

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.

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

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

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

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 weir

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

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 w

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

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 emai

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

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 attack

Re: [OAUTH-WG] open redirect in rfc6749

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 a

Re: [OAUTH-WG] open redirect in rfc6749

-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, Antoni

Re: [OAUTH-WG] open redirect in rfc6749

irect 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 p

Re: [OAUTH-WG] open redirect in rfc6749

kimura 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

Re: [OAUTH-WG] open redirect in rfc6749

sten 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]

Re: [OAUTH-WG] open redirect in rfc6749

ne 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

Re: [OAUTH-WG] open redirect in rfc6749

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

Re: [OAUTH-WG] open redirect in rfc6749

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

Re: [OAUTH-WG] open redirect in rfc6749

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

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

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"

Re: [OAUTH-WG] open redirect in rfc6749

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, >>>> &

Re: [OAUTH-WG] open redirect in rfc6749

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 wrot

Re: [OAUTH-WG] open redirect in rfc6749

as 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

Re: [OAUTH-WG] open redirect in rfc6749

) 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

Re: [OAUTH-WG] open redirect in rfc6749

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

Re: [OAUTH-WG] open redirect in rfc6749

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,

Re: [OAUTH-WG] open redirect in rfc6749

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

Re: [OAUTH-WG] open redirect in rfc6749

m > > > > 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,

Re: [OAUTH-WG] open redirect in rfc6749

t; >> 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 >> >>>

Re: [OAUTH-WG] open redirect in rfc6749

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 >>&g

Re: [OAUTH-WG] open redirect in rfc6749

/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

Re: [OAUTH-WG] open redirect in rfc6749

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

Re: [OAUTH-WG] open redirect in rfc6749

ovided? 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...@ve7j

Re: [OAUTH-WG] open redirect in rfc6749

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

Re: [OAUTH-WG] open redirect in rfc6749

cker 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

[OAUTH-WG] open redirect in rfc6749

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 resou

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

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 Innova

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

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 JW

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

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.

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

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 t

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

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

[OAUTH-WG] JWE with A128CBC-HS256

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 pri

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

to: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 > aud

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

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

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

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

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

io > > 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, Anto

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

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 JW

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

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 s

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

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

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

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.

Re: [OAUTH-WG] Oauth Server to Server

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

Re: [OAUTH-WG] Oauth Server to Server

ue, 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-be

Re: [OAUTH-WG] Oauth Server to Server

- 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 :) >>

Re: [OAUTH-WG] Oauth Server to Server

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 OAut

Re: [OAUTH-WG] Oauth Server to Server

plementary 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

Re: [OAUTH-WG] Oauth Server to Server

ken 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: > >&g

Re: [OAUTH-WG] Oauth Server to Server

l/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 ex

Re: [OAUTH-WG] Oauth Server to Server

; 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 :) &g

[OAUTH-WG] Oauth Server to Server

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 Cred

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

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&g

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

s 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

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

, 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 > - Justi

Re: [OAUTH-WG] JWS encoding Appendix A

h-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 ag

[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 sp

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

bset 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 Mess

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

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-WG] JWT spec

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

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

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

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

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 c

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

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

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

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

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

ign 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

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

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

  1   2   >