18 ms·

OAuth 3

413 points by andyroid 6y ago

gnur 6y ago
I'm slightly confused, is it going to be called xyz? Or OAuth XYZ, or Oauth 3? In either case, I am excited about it, I do hope it will be easier to use as well.
- spiderfarmer 6y ago
  I think it's called XYZ until it's ready to be called Oauth 3.
- LeonM 6y ago
  Same here. If anyone from the workgroup is reading this: please clarify in the first paragraph that XYZ is like a 'working title' for OAuth 3.
- valera_rozuvan 6y ago
  As Justin Richer writes [1]: And to be clear, I don’t actually care if the new work is called OAuth 3.0 or TxAuth or some other name, but I do think that it’s a fitting change set for a major revision of a powerful and successful protocol. We need something new, while we patch what we have, and now’s the time to build it. Come join the conversation in TxAuth, play with XYZ, and let’s start building the future. -------------------- [1] https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c7537e3f9c3 https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c...
- mooreds 6y ago
  It's called GNAP: https://datatracker.ietf.org/wg/gnap/documents/ https://datatracker.ietf.org/wg/gnap/documents/ The "Grant Negotiation and Authorization Protocol"
- detaro 6y ago
  XYZ was a title of some early drafts. The current working title is GNAT. It might stay with that name, it might be decided that it'll be called "OAuth 3", it might be abandoned
slooonz 6y ago
Apparently, still not going in the direction of OpenID where the end-user specifies (in an open-ended way) his authorization provider instead of choosing from a handful of big well-known providers (Google/Facebook/Github) handpicked by the relying party. Not surprised, but still disappointed.
- lode 6y ago
  Indeed. I miss OpenID, and the promise it had.
  - random5634 6y ago
    Same here. I even setup an openid provider using my domain - was great!
    - mooreds 6y ago
      Me too! I just checked and I still have the headers in my html. Should probably remove them :)
- magicalhippo 6y ago
  It's different things though, or? OAuth is about getting access to something, and usually part of that is proving to some authorization server that you are you (ie what OpenID is about), no? Do you mean you'd like OAuth to tackle the "you are you" part as well?
  - inopinatus 6y ago
    GP has written authorisation but they must mean identification, because only a resource owner can perform authorisation, not some random external service.
  - chrisweekly 6y ago
    authN = autheNtication (identity / "who are you") authZ = authoriZation (access / "what are you allowed to do")
vmception 6y ago
Oh god another decade of this bullshit
- ilikehurdles 6y ago
  My thoughts exactly. It comes across as an organization creating technical debt to justify its own existence.
  - vmception 6y ago
    that, and that some widely used service is going to be on oAuth 1.0, 1.0a, 2.0, some non-standard version, and 3.0 and these over-engineered-for-a-seemingly-good-reason-but-never-good-enough authentication methods won't have a relevant library that makes it easy to integrate with
qwerty456127 6y ago
There are 2 major problems that must be addressed: 1. Using OAuth to sign-up often means disclosing private data you can (and would normally prefer to) keep secret if you go the bare e-mail sign-up way. E.g. contacts list, exact date of birth, etc. - This is why I (as a user) stopped using OAuth for new accounts. Kind of the same used to apply to e.g. Android apps. I mean the "give an app all the permissions it wants or gtfo" anti-pattern which ought be abolished. The user should be allowed to continue after denying/revoking access to any (but absolutely essential for the very function) data silently or manually specifying whatever values they want. 2. It isn't always easy to decouple an OAuth-based account from the social network account, especially in case you loose access to the latter. - This is why I (as a user) migrated all OAuth-based accounts I had to the good old e-mail way.
- mattlutze 6y ago
  These are two great discussions to raise in the working group communications. If you go through the link that they've shared, you can sign up directly and participate in the conversation about how they architect the v3 rebuild.
- namanaggarwal 6y ago
  Your first point is actually not a OAuth issue, but how the provider designed it. You can build an OAuth provider that don't need to disclose anything(not even email)
  - qwerty456127 6y ago
    As a user I don't really care about the way they build it. I care about the spec to deny them forcing me to disclose the data. I once tried to sign-up with Google an it asked me to allow (with no option to deny but continue) to share my specific personal details. I've cancelled and never used this technology ever since. I didn't have to specify the same details (which Google was going to share) when signing-up with an e-mail address. The spec should discourage sharing details beyond necessary, prevent any details from being shared silently and ensure user can always deny and continue.
mattlutze 6y ago
For everyone that has comments and questions, the best way to get them discussed and considered is to join the IETF working group mailing list and starting to participate. As a student I've previously sat on a couple of mailing lists for the academic benefit of learning from some really smart/dedicated people. Joining and participating is open and just requires you to sign up. The signup link is on the announcement page above ^
- dt3ft 6y ago
  I wish they wouldn't use mailing lists. Keeping track of threads/topics must be a nightmare.
  - znpy 6y ago
    mailing lists are actually great for keeping track of threads and topics. and are pretty much the only open technology that is sufficiently technology-agnostic and interoperable. what should be the alternative, facebook comment threads?
    - pas 6y ago
      GitLab issues?
      - gray_-_wolf 6y ago
        You can easily branch mailing thread into multiple separate ones (happens regularly on gnu mailing lists for example). Compared to that, threading in all of the git forges sucks hard.
        pas 6y ago
        You can easily search for open issues, tag/label them, mange milestones, you know, project stuff. Plus you get a web interface that's a bit more user friendly than mailman's. You can see what's going on, how much open issues there are. How hard it is to open N separate issues and link them to the original one? It's exactly as much effort as sending new emails. TC39 uses GitHub: https://github.com/tc39/ https://github.com/tc39/ There's also the IETF datatracker, and various sites cobbled together to show the mail threads (eg. https://mailarchive.ietf.org/arch/browse/acme/ https://mailarchive.ietf.org/arch/browse/acme/ ) and states of various RFCs. And basically to manage work. Email is great, and it's enough for IETF workgroups, but it's just a communication channel, it's far from an efficient tool to organize (track, show, share, plan) work.
jwr 6y ago
While we're there, could we please change the name to something that is actually pronounceable and reasonably understandable on a phone call? (especially with non-native English speakers) "OAuth" is such a terrible name. It sounds like a silly problem, until you've been through a number of calls where you had to explain to someone that this is what can be used for integration. A fair percentage of such calls end with no understanding of what is being talked about.
- masukomi 6y ago
  how are you pronouncing it? I'm fairly certain the correct pronunciation is two distinct syllables (almost word level separation) "Oh" "oth" it should never have one syllable and sound like "oath" or "oh ah ooth". While i'm sure there are some languages where the "oth" is an odd phoneme it's pretty hard to confuse "Oh" "oth" with much of anything else in English. Sure people might not know about it, but there are tons of tech things people don't know about. That's a separate issue.
  - mmm_grayons 6y ago
    It's more that any word where one has to slow down and insert extra time between syllables so that they are distinghishable and intelligible is a "poorly designed word". Otherwise, it starts blurring due to the lack of a consonant.
    - gmfawcett 6y ago
      Such as your username, for example? Shouldn't you put a consonant between the "y" and the "o" to make it more intelligible? English is full of words that shift between vowels without a consonant. OAuth might be ugly, but it's hardly bending the rules of the language.
      - onion-soup 6y ago
        More like you are bending your own argument. grayoons, YO is more pronounceable than OA
parhamn 6y ago
> Polymorphic JSON. The protocol elements have different data types that convey additional contextual meaning, allowing us to avoid mutually exclusive protocol elements and design a more succinct and readable protocol. Yeah... let's not please.
- thosakwe 6y ago
  Yeah... This is the same sort of thing you see with, say, ActivityPub, that makes it a massive pain, if not totally impossible to implement it in a statically-typed language.
- oblio 6y ago
  I'm not sure I get this, does the data type change depending on context? Is that what they mean?
  - golergka 6y ago
    > XYZ’s protocol is not just based on JSON, but it’s based on a particular technique known as polymorphic JSON. In this, a single field could have a different data type in different circumstances. For example, the resources field can be an array when requesting a single access token, or it can be an object when requesting multiple named access tokens. The difference in type indicates a difference in processing from the server. Within the resources array, each element can be either an object, representing a rich resource request description, or a string, representing a resource handle (scope). This is horrible.
    - pwinnski 6y ago
      This is definitely not a protocol dreamed up by, say, Java developers. Obviously it's doable in Java, but I'm hard-pressed to imagine a Java developer would think of such a thing.
      - tasogare 6y ago
        This is a few magnitude even more infuriating than a spec I have to work with at work, where some keys are required to be URI...
ratiolat 6y ago
I wish they renamed the thing to OAuthorize. The current name is confusing. It's not for AUTHentication, it's for AUTHorization.
- ancymon 6y ago
  Isn't it other way around? Authentication is about confirming one's identity and that's what oAuth is used for. Authorization is about giving proper permissions and that's what happens after you get authenticated and has nothing to do with oAuth. Am I missing something?
  - tenplusfive 6y ago
    OAuth 2.0 is meant for Authorization. Multiple parties used if for Authentication, which is why a standardized Authentication layer was built on top of OAuth which is called OpenID Connect.
  - magicalhippo 6y ago
    No, I believe you got it 100% backwards. See the diagram in the RFC[1] and section 1.3 just below it. Sure OAuth usually involves authentication, but OAuth doesn't really care how it's done. Then again, not my field of expertise so I might be wrong. [1]: https://tools.ietf.org/html/rfc6749#section-1.2 https://tools.ietf.org/html/rfc6749#section-1.2
  - preommr 6y ago
    It's really stupid because it is an authorization protocol that people use for authentication because if you have access to certain resources, it implies you're a particular user.
secretsatan 6y ago
The medium page with the "Case for OAuth3" requires a sign in, kinda feel like it shouldn't
- orthecreedence 6y ago
  Kinda feel like people should stop using Medium for anything.
znpy 6y ago
Just spent a month during lockdown going through all the RFCs and specs for oauth 2.0, bearer token usage, openid connect, various extensions and a couple of software implementations... ... Great.
- jaywalk 6y ago
  After glancing at how OAuth 3 is going to work, I think your newfound knowledge will be good for quite a while. OAuth 3 looks like a mess right now.
bostik 6y ago
On a quick glance, this looks like an implementation nightmare just waiting to happen. Opaque handles everywhere (okay, that simplifies stuff going over the wire). Union types in protocol payloads - the spec calls these "polymorphic JSON", but the reality is you will need to branch on type of a given field. Worse, nothing prevents having two or more subtly different dictionaries in the same field, based on arbitrary/implicit conditions. Subtle and surprising payload differences are pretty much guaranteed to introduce weird problems in the real world. And I'm not ruling out security problems either, because a bug in authorisation logic can easily generate tokens that are valid for wrong scopes.
- q3k 6y ago
  Yeah, I really don't get the Handle concept - what is this attempting to solve? Dooes anyone know where can I read up on the design decisions that lead to this? This seems to introduce tons of implementation pains (statefulness, cache invalidation, 'polymorphic JSON', ...) while only seemingly benefiting a shorter wire format - but that's such a weird thing to optimize for. EDIT: There's this [1], but it only makes me ask more questions. The only rationale I can see from that document is “it would seem silly and wasteful to force all developers to push all of their keying information in every request”. Which makes me want to throw out oauth.xyz and never look at it again, because that looks like the authors have some absurd priorities in their protocol design. [1] - https://medium.com/@justinsecurity/xyz-handles-passing-by-reference-and-polymorphic-json-e1af8892f371 https://medium.com/@justinsecurity/xyz-handles-passing-by-re...
  - fny 6y ago
    This used to be called TxAuth. You can find a lot of the discussions online through search: - https://ietf.topicbox-scratch.com/groups/txauth https://ietf.topicbox-scratch.com/groups/txauth - https://www.ietf.org/mailman/listinfo/txauth https://www.ietf.org/mailman/listinfo/txauth
    - btilly 6y ago
      TxAuth? Toxic Authorization? My positive attitude about OAuth* may be showing.
self_awareness 6y ago
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.
- secretsatan 6y ago
  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
- dathinab 6y ago
  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...
- pwdisswordfish4 6y ago
  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 6y ago
    You could spare your answer, since it's not providing any information at all.
    - 6y ago
bojanz 6y ago
I'm personally more excited about this year's OAuth 2.1 draft[1], since it aims to reduce the number of RFCs one needs to review and understand in order to implement a best practices OAuth client. [1] https://oauth.net/2.1/ https://oauth.net/2.1/
- mooreds 6y ago
  Yes, I've been keeping an eye on this. Haven't seen much action on this for a few months. I like that they are formally deprecating the implicit grant! If folks are interested in the nitty gritty, I wrote a blog post a few months back: https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1/ https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1... And this is a great podcast with one of the authors, Aaron Parecki, talking in detail about the changes: https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd https://identityunlocked.auth0.com/public/49/Identity%2C-Unl...
swiley 6y ago
I really wanted to like OAuth but implementing it is a nightmare! When can we just have client side certificates? That would be a great way to deal with most of the problems that emailing a "magic login link" (or just normal email based accounts) doesn't solve.
- bo1024 6y ago
  I"m not sure exactly what client-side certificates means here, but I have long wondered why we can't just use public key/private key authentication for most logins. Is it the same?
  - mortehu 6y ago
    Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication, and a very small number of websites supported it. After Chrome became popular, those sites were forced to switch to a different form of second factor authentication, and it's fallen almost completely out of use. Part of the reason was that the user interfaces for installing certificates were terrible, and websites needed to have guides on how to use it in each browser.
    - bo1024 6y ago
      Thanks. I’m still not clear what the authentication method is, but I don't see why we can’t have a one click browser button “give this site my public key” and another “authenticate to this site with my private key”.
      - chipsa 6y ago
        Who gives you the private key? Is it generated on the device? How do you move the keys to your different devices? I can end up working at any of 20 computers on a given day, not counting my personal devices.
        bo1024 6y ago
callamdelaney 6y ago
But the last two were already so painful..
detay 6y ago
better prepare for OAuth 3.0 bounties. a man's gotta eat.
- speedgoose 6y ago
  Becoming a farmer sounds more appealing to me than reading and understanding the oauth3 RFC and the implementations.
faichai 6y ago
His "The Case for OAuth 3.0" article [1] is behind the Medium paywall. That's utter bullshit when arguing the case for a core internet protocol. Medium has ruined text like Pinterest has ruined images. [1] https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c7537e3f9c3 https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c...
- jricher 6y ago
  I didn't realize that this got put behind the paywall like that -- Medium's options for this are really confusing. I'd happily open it up if I can find out how.
  - faichai 6y ago
    No worries, I wasn’t trying to ascribe any personal fault. Figured it was more a Medium product issue.
- jayzalowitz 6y ago
  If only someone created a well known technically focused contributor based medium competitor that doesnt have a paywall!!
pmlnr 6y ago
ok, that's ridiculous: "The Case for OAuth 3.0" article linked - becase I'd like to learn what problem OAuth 3.0 would solve - is behind medium paywall. Although this fact alone might even tell me enough of OAuth 3.0.
mooreds 6y ago
This document just graduated to the full WG[0][1]. So this isn't a full fledged, ready to implement, draft. I've been doing some research on this for an upcoming presentation and it seems this was a union of the design ideas of two draft documents TxAuth and OAuth.xyz, which means there's a few issues that need to be resolved. I'm sure they'd welcome respectful feedback. From the WG's charter[2], they are looking for feedback and comments and expect last call for the core protocol in July 2021. It's still very much a work in progress. I counted the TBDs and "Editor's notes" and found an average of one of these "TODO" markers per page of the draft. I'm excited about the more modern developer ergonomics (using JSON is a step up from using form params), the ability for an RC to request user info at the same time (folding in some of OIDC), and fact they've explicitly built interaction extensions into the model. OAuth2 often assumes a browser with redirect capabilities and there are some inelegant solutions that arise from that[3]. Still a lot of things to iron out, for sure, though. That said, I think OAuth2 will still be common 3 years from now, and if OAuth2 satisfies your needs, you aren't forced to move on to this new, explicitly not backward compatible[4], auth protocol. [0]: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.txt https://www.ietf.org/archive/id/draft-ietf-gnap-core-protoco... [1]: https://mailarchive.ietf.org/arch/msg/txauth/UkvrBXkMk9YMl7m6N-YxhN7Zm1w/ https://mailarchive.ietf.org/arch/msg/txauth/UkvrBXkMk9YMl7m... [2]: https://datatracker.ietf.org/wg/gnap/about/ https://datatracker.ietf.org/wg/gnap/about/ [3]: https://fusionauth.io/blog/2020/08/19/securing-react-native-with-oauth/ https://fusionauth.io/blog/2020/08/19/securing-react-native-... shows that you have to have a redirect with a custom scheme for a mobile app. Seems weird to me. [4]: "Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible." - https://datatracker.ietf.org/wg/gnap/about/ https://datatracker.ietf.org/wg/gnap/about/
- will4274 6y ago
  > using JSON is a step up from using form params Why? It seems to me that I'm either writing Json.Serialize(loginParams) or HttpForms.Serialize(loginParams). Both are human readable and weakly typed. From a developer perspective, these seem almost exactly equivalent, just different.
skrowl 6y ago
Just calling this link "OAuth 3" is clickbait
huma 6y ago
A bit of history on the matter. https://web.archive.org/web/20130116102852/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ https://web.archive.org/web/20130116102852/http://hueniverse...
ansonhoyt 6y ago
I really want to cheer with hope, but I'm screaming inside. My crappy app auth code needs to stay buried...forever. It's almost October 31, so definitely filing this under scary.

413 points by andyroid 6y ago

gnur 6y ago

I'm slightly confused, is it going to be called xyz? Or OAuth XYZ, or Oauth 3? In either case, I am excited about it, I do hope it will be easier to use as well.

spiderfarmer 6y ago
I think it's called XYZ until it's ready to be called Oauth 3.
LeonM 6y ago
Same here. If anyone from the workgroup is reading this: please clarify in the first paragraph that XYZ is like a 'working title' for OAuth 3.
valera_rozuvan 6y ago
As Justin Richer writes [1]: And to be clear, I don’t actually care if the new work is called OAuth 3.0 or TxAuth or some other name, but I do think that it’s a fitting change set for a major revision of a powerful and successful protocol. We need something new, while we patch what we have, and now’s the time to build it. Come join the conversation in TxAuth, play with XYZ, and let’s start building the future. -------------------- [1] https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c7537e3f9c3 https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c...
mooreds 6y ago
It's called GNAP: https://datatracker.ietf.org/wg/gnap/documents/ https://datatracker.ietf.org/wg/gnap/documents/ The "Grant Negotiation and Authorization Protocol"
detaro 6y ago
XYZ was a title of some early drafts. The current working title is GNAT. It might stay with that name, it might be decided that it'll be called "OAuth 3", it might be abandoned

slooonz 6y ago

Apparently, still not going in the direction of OpenID where the end-user specifies (in an open-ended way) his authorization provider instead of choosing from a handful of big well-known providers (Google/Facebook/Github) handpicked by the relying party. Not surprised, but still disappointed.

lode 6y ago
Indeed. I miss OpenID, and the promise it had.
- random5634 6y ago
  Same here. I even setup an openid provider using my domain - was great!
  - mooreds 6y ago
    Me too! I just checked and I still have the headers in my html. Should probably remove them :)
magicalhippo 6y ago
It's different things though, or? OAuth is about getting access to something, and usually part of that is proving to some authorization server that you are you (ie what OpenID is about), no? Do you mean you'd like OAuth to tackle the "you are you" part as well?
- inopinatus 6y ago
  GP has written authorisation but they must mean identification, because only a resource owner can perform authorisation, not some random external service.
- chrisweekly 6y ago
  authN = autheNtication (identity / "who are you") authZ = authoriZation (access / "what are you allowed to do")

vmception 6y ago

Oh god another decade of this bullshit

ilikehurdles 6y ago
My thoughts exactly. It comes across as an organization creating technical debt to justify its own existence.
- vmception 6y ago
  that, and that some widely used service is going to be on oAuth 1.0, 1.0a, 2.0, some non-standard version, and 3.0 and these over-engineered-for-a-seemingly-good-reason-but-never-good-enough authentication methods won't have a relevant library that makes it easy to integrate with

qwerty456127 6y ago

There are 2 major problems that must be addressed: 1. Using OAuth to sign-up often means disclosing private data you can (and would normally prefer to) keep secret if you go the bare e-mail sign-up way. E.g. contacts list, exact date of birth, etc. - This is why I (as a user) stopped using OAuth for new accounts. Kind of the same used to apply to e.g. Android apps. I mean the "give an app all the permissions it wants or gtfo" anti-pattern which ought be abolished. The user should be allowed to continue after denying/revoking access to any (but absolutely essential for the very function) data silently or manually specifying whatever values they want. 2. It isn't always easy to decouple an OAuth-based account from the social network account, especially in case you loose access to the latter. - This is why I (as a user) migrated all OAuth-based accounts I had to the good old e-mail way.

mattlutze 6y ago
These are two great discussions to raise in the working group communications. If you go through the link that they've shared, you can sign up directly and participate in the conversation about how they architect the v3 rebuild.
namanaggarwal 6y ago
Your first point is actually not a OAuth issue, but how the provider designed it. You can build an OAuth provider that don't need to disclose anything(not even email)
- qwerty456127 6y ago
  As a user I don't really care about the way they build it. I care about the spec to deny them forcing me to disclose the data. I once tried to sign-up with Google an it asked me to allow (with no option to deny but continue) to share my specific personal details. I've cancelled and never used this technology ever since. I didn't have to specify the same details (which Google was going to share) when signing-up with an e-mail address. The spec should discourage sharing details beyond necessary, prevent any details from being shared silently and ensure user can always deny and continue.

mattlutze 6y ago

For everyone that has comments and questions, the best way to get them discussed and considered is to join the IETF working group mailing list and starting to participate. As a student I've previously sat on a couple of mailing lists for the academic benefit of learning from some really smart/dedicated people. Joining and participating is open and just requires you to sign up. The signup link is on the announcement page above ^

dt3ft 6y ago
I wish they wouldn't use mailing lists. Keeping track of threads/topics must be a nightmare.
- znpy 6y ago
  mailing lists are actually great for keeping track of threads and topics. and are pretty much the only open technology that is sufficiently technology-agnostic and interoperable. what should be the alternative, facebook comment threads?
  - pas 6y ago
    GitLab issues?
    - gray_-_wolf 6y ago
      You can easily branch mailing thread into multiple separate ones (happens regularly on gnu mailing lists for example). Compared to that, threading in all of the git forges sucks hard.
      - pas 6y ago
        You can easily search for open issues, tag/label them, mange milestones, you know, project stuff. Plus you get a web interface that's a bit more user friendly than mailman's. You can see what's going on, how much open issues there are. How hard it is to open N separate issues and link them to the original one? It's exactly as much effort as sending new emails. TC39 uses GitHub: https://github.com/tc39/ https://github.com/tc39/ There's also the IETF datatracker, and various sites cobbled together to show the mail threads (eg. https://mailarchive.ietf.org/arch/browse/acme/ https://mailarchive.ietf.org/arch/browse/acme/ ) and states of various RFCs. And basically to manage work. Email is great, and it's enough for IETF workgroups, but it's just a communication channel, it's far from an efficient tool to organize (track, show, share, plan) work.

jwr 6y ago

While we're there, could we please change the name to something that is actually pronounceable and reasonably understandable on a phone call? (especially with non-native English speakers) "OAuth" is such a terrible name. It sounds like a silly problem, until you've been through a number of calls where you had to explain to someone that this is what can be used for integration. A fair percentage of such calls end with no understanding of what is being talked about.

masukomi 6y ago
how are you pronouncing it? I'm fairly certain the correct pronunciation is two distinct syllables (almost word level separation) "Oh" "oth" it should never have one syllable and sound like "oath" or "oh ah ooth". While i'm sure there are some languages where the "oth" is an odd phoneme it's pretty hard to confuse "Oh" "oth" with much of anything else in English. Sure people might not know about it, but there are tons of tech things people don't know about. That's a separate issue.
- mmm_grayons 6y ago
  It's more that any word where one has to slow down and insert extra time between syllables so that they are distinghishable and intelligible is a "poorly designed word". Otherwise, it starts blurring due to the lack of a consonant.
  - gmfawcett 6y ago
    Such as your username, for example? Shouldn't you put a consonant between the "y" and the "o" to make it more intelligible? English is full of words that shift between vowels without a consonant. OAuth might be ugly, but it's hardly bending the rules of the language.
    - onion-soup 6y ago
      More like you are bending your own argument. grayoons, YO is more pronounceable than OA

parhamn 6y ago

> Polymorphic JSON. The protocol elements have different data types that convey additional contextual meaning, allowing us to avoid mutually exclusive protocol elements and design a more succinct and readable protocol. Yeah... let's not please.

thosakwe 6y ago
Yeah... This is the same sort of thing you see with, say, ActivityPub, that makes it a massive pain, if not totally impossible to implement it in a statically-typed language.
oblio 6y ago
I'm not sure I get this, does the data type change depending on context? Is that what they mean?
- golergka 6y ago
  > XYZ’s protocol is not just based on JSON, but it’s based on a particular technique known as polymorphic JSON. In this, a single field could have a different data type in different circumstances. For example, the resources field can be an array when requesting a single access token, or it can be an object when requesting multiple named access tokens. The difference in type indicates a difference in processing from the server. Within the resources array, each element can be either an object, representing a rich resource request description, or a string, representing a resource handle (scope). This is horrible.
  - pwinnski 6y ago
    This is definitely not a protocol dreamed up by, say, Java developers. Obviously it's doable in Java, but I'm hard-pressed to imagine a Java developer would think of such a thing.
    - tasogare 6y ago
      This is a few magnitude even more infuriating than a spec I have to work with at work, where some keys are required to be URI...

ratiolat 6y ago

I wish they renamed the thing to OAuthorize. The current name is confusing. It's not for AUTHentication, it's for AUTHorization.

ancymon 6y ago
Isn't it other way around? Authentication is about confirming one's identity and that's what oAuth is used for. Authorization is about giving proper permissions and that's what happens after you get authenticated and has nothing to do with oAuth. Am I missing something?
- tenplusfive 6y ago
  OAuth 2.0 is meant for Authorization. Multiple parties used if for Authentication, which is why a standardized Authentication layer was built on top of OAuth which is called OpenID Connect.
- magicalhippo 6y ago
  No, I believe you got it 100% backwards. See the diagram in the RFC[1] and section 1.3 just below it. Sure OAuth usually involves authentication, but OAuth doesn't really care how it's done. Then again, not my field of expertise so I might be wrong. [1]: https://tools.ietf.org/html/rfc6749#section-1.2 https://tools.ietf.org/html/rfc6749#section-1.2
- preommr 6y ago
  It's really stupid because it is an authorization protocol that people use for authentication because if you have access to certain resources, it implies you're a particular user.

secretsatan 6y ago

The medium page with the "Case for OAuth3" requires a sign in, kinda feel like it shouldn't

orthecreedence 6y ago
Kinda feel like people should stop using Medium for anything.

znpy 6y ago

Just spent a month during lockdown going through all the RFCs and specs for oauth 2.0, bearer token usage, openid connect, various extensions and a couple of software implementations... ... Great.

jaywalk 6y ago
After glancing at how OAuth 3 is going to work, I think your newfound knowledge will be good for quite a while. OAuth 3 looks like a mess right now.

bostik 6y ago

On a quick glance, this looks like an implementation nightmare just waiting to happen. Opaque handles everywhere (okay, that simplifies stuff going over the wire). Union types in protocol payloads - the spec calls these "polymorphic JSON", but the reality is you will need to branch on type of a given field. Worse, nothing prevents having two or more subtly different dictionaries in the same field, based on arbitrary/implicit conditions. Subtle and surprising payload differences are pretty much guaranteed to introduce weird problems in the real world. And I'm not ruling out security problems either, because a bug in authorisation logic can easily generate tokens that are valid for wrong scopes.

q3k 6y ago
Yeah, I really don't get the Handle concept - what is this attempting to solve? Dooes anyone know where can I read up on the design decisions that lead to this? This seems to introduce tons of implementation pains (statefulness, cache invalidation, 'polymorphic JSON', ...) while only seemingly benefiting a shorter wire format - but that's such a weird thing to optimize for. EDIT: There's this [1], but it only makes me ask more questions. The only rationale I can see from that document is “it would seem silly and wasteful to force all developers to push all of their keying information in every request”. Which makes me want to throw out oauth.xyz and never look at it again, because that looks like the authors have some absurd priorities in their protocol design. [1] - https://medium.com/@justinsecurity/xyz-handles-passing-by-reference-and-polymorphic-json-e1af8892f371 https://medium.com/@justinsecurity/xyz-handles-passing-by-re...
- fny 6y ago
  This used to be called TxAuth. You can find a lot of the discussions online through search: - https://ietf.topicbox-scratch.com/groups/txauth https://ietf.topicbox-scratch.com/groups/txauth - https://www.ietf.org/mailman/listinfo/txauth https://www.ietf.org/mailman/listinfo/txauth
  - btilly 6y ago
    TxAuth? Toxic Authorization? My positive attitude about OAuth* may be showing.

self_awareness 6y ago

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.

secretsatan 6y ago
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
dathinab 6y ago
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...
pwdisswordfish4 6y ago
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 6y ago
  You could spare your answer, since it's not providing any information at all.
  - 6y ago

bojanz 6y ago

I'm personally more excited about this year's OAuth 2.1 draft[1], since it aims to reduce the number of RFCs one needs to review and understand in order to implement a best practices OAuth client. [1] https://oauth.net/2.1/ https://oauth.net/2.1/

mooreds 6y ago
Yes, I've been keeping an eye on this. Haven't seen much action on this for a few months. I like that they are formally deprecating the implicit grant! If folks are interested in the nitty gritty, I wrote a blog post a few months back: https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1/ https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1... And this is a great podcast with one of the authors, Aaron Parecki, talking in detail about the changes: https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd https://identityunlocked.auth0.com/public/49/Identity%2C-Unl...

swiley 6y ago

I really wanted to like OAuth but implementing it is a nightmare! When can we just have client side certificates? That would be a great way to deal with most of the problems that emailing a "magic login link" (or just normal email based accounts) doesn't solve.

bo1024 6y ago
I"m not sure exactly what client-side certificates means here, but I have long wondered why we can't just use public key/private key authentication for most logins. Is it the same?
- mortehu 6y ago
  Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication, and a very small number of websites supported it. After Chrome became popular, those sites were forced to switch to a different form of second factor authentication, and it's fallen almost completely out of use. Part of the reason was that the user interfaces for installing certificates were terrible, and websites needed to have guides on how to use it in each browser.
  - bo1024 6y ago
    Thanks. I’m still not clear what the authentication method is, but I don't see why we can’t have a one click browser button “give this site my public key” and another “authenticate to this site with my private key”.
    - chipsa 6y ago
      Who gives you the private key? Is it generated on the device? How do you move the keys to your different devices? I can end up working at any of 20 computers on a given day, not counting my personal devices.
      - bo1024 6y ago

callamdelaney 6y ago

But the last two were already so painful..

detay 6y ago

better prepare for OAuth 3.0 bounties. a man's gotta eat.

speedgoose 6y ago
Becoming a farmer sounds more appealing to me than reading and understanding the oauth3 RFC and the implementations.

faichai 6y ago

His "The Case for OAuth 3.0" article [1] is behind the Medium paywall. That's utter bullshit when arguing the case for a core internet protocol. Medium has ruined text like Pinterest has ruined images. [1] https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c7537e3f9c3 https://medium.com/@justinsecurity/the-case-for-oauth-3-0-5c...

jricher 6y ago
I didn't realize that this got put behind the paywall like that -- Medium's options for this are really confusing. I'd happily open it up if I can find out how.
- faichai 6y ago
  No worries, I wasn’t trying to ascribe any personal fault. Figured it was more a Medium product issue.
jayzalowitz 6y ago
If only someone created a well known technically focused contributor based medium competitor that doesnt have a paywall!!

pmlnr 6y ago

ok, that's ridiculous: "The Case for OAuth 3.0" article linked - becase I'd like to learn what problem OAuth 3.0 would solve - is behind medium paywall. Although this fact alone might even tell me enough of OAuth 3.0.

mooreds 6y ago

This document just graduated to the full WG[0][1]. So this isn't a full fledged, ready to implement, draft. I've been doing some research on this for an upcoming presentation and it seems this was a union of the design ideas of two draft documents TxAuth and OAuth.xyz, which means there's a few issues that need to be resolved. I'm sure they'd welcome respectful feedback. From the WG's charter[2], they are looking for feedback and comments and expect last call for the core protocol in July 2021. It's still very much a work in progress. I counted the TBDs and "Editor's notes" and found an average of one of these "TODO" markers per page of the draft. I'm excited about the more modern developer ergonomics (using JSON is a step up from using form params), the ability for an RC to request user info at the same time (folding in some of OIDC), and fact they've explicitly built interaction extensions into the model. OAuth2 often assumes a browser with redirect capabilities and there are some inelegant solutions that arise from that[3]. Still a lot of things to iron out, for sure, though. That said, I think OAuth2 will still be common 3 years from now, and if OAuth2 satisfies your needs, you aren't forced to move on to this new, explicitly not backward compatible[4], auth protocol. [0]: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.txt https://www.ietf.org/archive/id/draft-ietf-gnap-core-protoco... [1]: https://mailarchive.ietf.org/arch/msg/txauth/UkvrBXkMk9YMl7m6N-YxhN7Zm1w/ https://mailarchive.ietf.org/arch/msg/txauth/UkvrBXkMk9YMl7m... [2]: https://datatracker.ietf.org/wg/gnap/about/ https://datatracker.ietf.org/wg/gnap/about/ [3]: https://fusionauth.io/blog/2020/08/19/securing-react-native-with-oauth/ https://fusionauth.io/blog/2020/08/19/securing-react-native-... shows that you have to have a redirect with a custom scheme for a mobile app. Seems weird to me. [4]: "Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible." - https://datatracker.ietf.org/wg/gnap/about/ https://datatracker.ietf.org/wg/gnap/about/

will4274 6y ago
> using JSON is a step up from using form params Why? It seems to me that I'm either writing Json.Serialize(loginParams) or HttpForms.Serialize(loginParams). Both are human readable and weakly typed. From a developer perspective, these seem almost exactly equivalent, just different.

skrowl 6y ago

Just calling this link "OAuth 3" is clickbait

huma 6y ago

A bit of history on the matter. https://web.archive.org/web/20130116102852/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ https://web.archive.org/web/20130116102852/http://hueniverse...

ansonhoyt 6y ago

I really want to cheer with hope, but I'm screaming inside. My crappy app auth code needs to stay buried...forever. It's almost October 31, so definitely filing this under scary.