[self_awareness]

Can it be used in desktop apps or mobile apps?

I remember something that previous versions were for webapps only. Never used it though.

Edit: What's wrong with you people? You're downvoting questions now? I remember that OAuth forced the user to include client secret in app's binary. When extracted, everyone could impersonate the app. If you don't understand the problem then don't downvote.

[pwdisswordfish4]

These are false/misleading statements, not questions:

> I remember something that previous versions were for webapps only.

> I remember that OAuth forced the user to include client secret in app's binary.

This is not actually a problem with RFC 7636.

[self_awareness]

You could spare your answer, since it's not providing any information at all.

[pwdisswordfish4]

Ruling out the truth of something is information-free, and mentioning an RFC by ID is information-free. Got it.

[dathinab]

You always could use OAuth in apps just fine.

OAuth 2 was a design nightmare.

But by now it kinda consolidated into a usable best practices how to do it. But gathering them from the core RFC and all the extensions is a pain.

So what would be nice would a a updated RFC including all best practice and deprecating all things which turned out bad (or had security vulnerabilities).

OAuth 2.1 somewhat goes into that direction.

But IMHO OAuth 3 looks like starting the whole OAuth 2 madness from the scratch not learning from all the problems OAuth 2 had when it was new...

[will4274]

> I remember that OAuth forced the user to include client secret in app's binary. When extracted, everyone could impersonate the app. If you don't understand the problem then don't downvote

This isn't correct. Native apps aren't capable of holding a secret. There are two patterns here. Some providers omit the secret for native apps. Other providers define the concept of a "public secret," a value that is "not a secret," but is put in the client_secret field - rotating this value disables old clients. Either model is fine and secure.

The problems you refer to were mostly just developer error. Developers registered their native apps as having confidential secrets, even though this was not the case, and then shipped those secrets in the app source code.

[mooreds]

The best practice for native apps is to use PKCE now, I believe.

See section 4.1.1 of the OAuth 2.1.1 spec ( https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00 ) which was, I believe also included in the security best practices.

[will4274]

While that's true, it's irrelevant to my comment. PKCE is layered on top of the either of the two strategies I described and solves a totally different problem (untrustworthy user agents).

[secretsatan]

I've implemented it in mobile to authorize our app to communicate with our cloud, it does still use a webview to enter credentials, but there's a specific framework for doing authorisation with a webview on iOS