OAuth 2.0 Security Best Current Practice
tools.ietf.org
OAuth 2.0 Security Best Current Practice
1–10 of 98 posts
Re: OAuth 2.0 Security Best Current Practice
#2Worth bearing in mind:
> This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
> ...
> It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
Re: OAuth 2.0 Security Best Current Practice
#3To this day I have no idea how one should handle client secrets in (F)OSS applications, and I'm often wondering if I'm the only one. I guess what this text says in 4.13 is "just don't put it somewhere for anyone to see", which means that the only solution is to make the id and secret configurable and let the user register the application with its OAuth provider, which of course most users wouldn't know how to do. As a result, applications like Thunderbird simply put the secret in the code with a comment above it "please don't copy these values for your own application". I really don't mean to shame Mozilla, what else are they supposed to do?
Re: OAuth 2.0 Security Best Current Practice
#4To this day I have no idea how one should handle client secrets in (F)OSS applications, and I'm often wondering if I'm the only one. I guess what this text says in 4.13 is "just don't put it somewhere for anyone to see", which means that the only solution is to make the id and secret configurable and let the user register the application with its OAuth provider, which of course most users wouldn't know how to do. As…
From my understanding the best practice for applications that run on clients' machines (Javascript SPA, mobile app, email client) is to not use a client secret at all. Just use a client id and assume that anyone can reuse it.
Of course that is if the OAuth provider allows it.
Re: OAuth 2.0 Security Best Current Practice
#5I implemented more than a dozen OAuth integrations last year with multiple American and Chinese companies and oh boy it was painful.
I do not know why so many engineers end up reading a clear specification document like RFC-6749 [1] and then ignore 80% of the instructions. I had to deal with so many weird bugs and bad OAuth server implementations, I lost count of how many emails went back and forth trying to make sense of unexpected behavior.
Even Apple engineers got it wrong. They decided to create their own thing based on OpenID Connect for “Sign In With Apple” [2]. OpenID had to write an open letter [3] explaining the repercussions of their changes and fortunately were able to convince Apple to fix the implementation [4].
OpenID was lucky though, they had some leverage, but a no-one like me couldn’t possibly convince a gigantic conglomerate like Tencent to fix their web API. Talking with Tencent engineers has been one of the worst experiences in my career. The company apparently has a culture of constant job rotations, engineers are assigned projects for short periods of time with bonuses for early completion which encourage them to deploy half-finished code before moving to something else.
[1] https://tools.ietf.org/html/rfc6749
[2] https://developer.apple.com/sign-in-with-apple/
[3] https://openid.net/2019/06/27/open-letter-from-the-openid-fo...
[4] https://openid.net/2019/09/30/apple-successfully-implements-...
Re: OAuth 2.0 Security Best Current Practice
#6It's not structurally all that great; it opens with a long section of recommendations backed by citations to later "attack model" sections in the text, which themselves include disjoint lists of recommendations.
Re: OAuth 2.0 Security Best Current Practice
#7To this day I have no idea how one should handle client secrets in (F)OSS applications, and I'm often wondering if I'm the only one. I guess what this text says in 4.13 is "just don't put it somewhere for anyone to see", which means that the only solution is to make the id and secret configurable and let the user register the application with its OAuth provider, which of course most users wouldn't know how to do. As…
From my understanding the best practice for applications that run on clients' machines (Javascript SPA, mobile app, email client) is to not use a client secret at all. Just use a client id and assume that anyone can reuse it. Of course that is if the OAuth provider allows it.
> Of course that is if the OAuth provider allows it.
That's the catch. Last time I checked, at least Google didn't. So how can you write a (F)OSS email application for accessing GMail via OAuth2, without putting the secrets into the code (which Google also forbids)?
Re: OAuth 2.0 Security Best Current Practice
#8To this day I have no idea how one should handle client secrets in (F)OSS applications, and I'm often wondering if I'm the only one. I guess what this text says in 4.13 is "just don't put it somewhere for anyone to see", which means that the only solution is to make the id and secret configurable and let the user register the application with its OAuth provider, which of course most users wouldn't know how to do. As…
If it's a FOSS clientside application, like a mobile or desktop app, it's a public application and the client secret doesn't really apply. If it's a serverside application, a web app, then every instance of the app will be registered independently with auth servers, and will manage their own client secrets.
Re: OAuth 2.0 Security Best Current Practice
#9Earlier quoted context omitted.
From my understanding the best practice for applications that run on clients' machines (Javascript SPA, mobile app, email client) is to not use a client secret at all. Just use a client id and assume that anyone can reuse it. Of course that is if the OAuth provider allows it.
> Of course that is if the OAuth provider allows it. That's the catch. Last time I checked, at least Google didn't. So how can you write a (F)OSS email application for accessing GMail via OAuth2, without putting the secrets into the code (which Google also forbids)?
Google Mail's OAuth2 instructions discuss this point explicitly.
Re: OAuth 2.0 Security Best Current Practice
#10To this day I have no idea how one should handle client secrets in (F)OSS applications, and I'm often wondering if I'm the only one. I guess what this text says in 4.13 is "just don't put it somewhere for anyone to see", which means that the only solution is to make the id and secret configurable and let the user register the application with its OAuth provider, which of course most users wouldn't know how to do. As…
From my understanding the best practice for applications that run on clients' machines (Javascript SPA, mobile app, email client) is to not use a client secret at all. Just use a client id and assume that anyone can reuse it. Of course that is if the OAuth provider allows it.
Yup, a SPA can't really keep a secret, right?
That's why the best option is to set up a secure middleware layer to hold your secrets. Here's an example using react: https://fusionauth.io/blog/2020/03/10/securely-implement-oau...
(Full disclosure, this is a post on the blog of the companyfor which I work.)