11–20 of 98 posts
To 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…
Earlier 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.
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.)
Earlier quoted context omitted.
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.)
People build SPAs with the OAuth2 code flow (and PKCE) all the time.
It's really the implicit grant (where access tokens are available to the client) that should be avoided.
I 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 sen…
I thought the point of OAuth was to make it easy to build clients and push the complexity to the authorization servers :) ?
I 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 sen…
Were you implementing a client in all of these OAuth integrations? I thought the point of OAuth was to make it easy to build clients and push the complexity to the authorization servers :) ?
I 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 sen…
Were you implementing a client in all of these OAuth integrations? I thought the point of OAuth was to make it easy to build clients and push the complexity to the authorization servers :) ?
Earlier quoted context omitted.
People build SPAs with the OAuth2 code flow (and PKCE) all the time.
Sorry, I misspoke. Those SPAs always have middleware to handle the authorization code, right? It's really the implicit grant (where access tokens are available to the client) that should be avoided.
I 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 sen…
can you tell me if there is a good drop in component that I can add to my product and integrate easily to get oauth2/open id connect? I heard good things about identity server but would appreciate if you could share your opinion on it.
Earlier 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)?