OAuth 3

413 points by andyroid 4 years ago | 208 comments
  • bostik 4 years 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 4 years 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-re...

      • jiggawatts 4 years ago
        This is a solution to a problem of their own making.

        OAuth transactions are "big" because they allow the use of RSA keys, which are large. The keys would be smaller if they were simply opinionated and mandated a specific cipher, such as Ed25519 that uses much smaller keys.

        Protocols like SAML, OpenID, and OAuth aren't. They're not protocols at all. They're protocol parts thrown into a bag that everyone can pull whatever they like out of. They support way too many cryptographic primitives, and have far too many pluggable features.

        Just yesterday I had to deal with an outage because a large enterprise ISV's SAML implementation doesn't support signing key rollover! You can have exactly one key only, which means after a key renewal all authentication breaks. You have to do big-bang coordinated rollouts.

        That is typical of the kind of stuff I see in this space.

        Everyone gets every part of these protocols wrong. Google does SAML wrong! Microsoft fixed one glaring security flaw in Azure AD, but neglected to back-port it to AD FS, because legacy on-prem security doesn't matter, right?

        If Google and Microsoft can't get these things right, why are we working one yet more protocols that are even more complex!?

        • marcosdumay 4 years ago
          I have personally faced plenty of problems caused by the OAuth2 large wire size.

          The web is full of middle boxes with crazy limitations. And OAuth2 is very good of triggering each one of them. They are also mostly unique, not under the control of the ends, and often transient, so they most often aren't even understood, the problem is just assumed unsolvable. That alone is a big limitation that stops people from using OAuth2.

          That said, I have never seen a case where crypto data was the cause of the bloat. Its size is so small when compared to everything else that I'm not sure why anybody would even look at it. And indeed, the rationale I found on the site is about cryptographic agility... what is interesting because you will find plenty of people claiming that this is an anti-feature that will harm security much more than help.

          • q3k 4 years ago
            Doesn't that issue come from the fact that OAuth2 state mostly lives in GET URL data (redirects/callbacks) and request headers (bearer tokens), vs. POST body (which is something OAuth3 does seem to get right)?
            • ldng 4 years ago
              What do you use instead of OAuth2 yourself ?
            • fny 4 years 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://www.ietf.org/mailman/listinfo/txauth

            • bostik 4 years ago
              > shorter wire format - but that's such a weird thing to optimize for.

              As odd as it sounds, this one I can actually understand. I'm pretty sure the designers come loaded with painful experience on request header bloat. They may want v3 to support completely stateless requests, and would rather not transmit large public keys or possibly even client certificate chains on routine requests.

              For those cases I can see the benefit of being able to say "look up my details from this $ObjectID". When everything related to session authorisation is behind a single lookup key, the data likely becomes more easily cacheable.

              It's a perfectly valid tradeoff for environments where compute and bandwidth cost way more than engineering time. For the rest of us...

              • q3k 4 years ago
                But with the current spec, IIUC, it's up to the AS to provide handles for future client reference - so the burden of allowing for smaller requests in the future falls on identity provider software, not the client. And when a side 'MAY', experience says, they almost never do, unless it makes things simpler for them. And having to store extra, global data is something no-one really wants to do.

                Not to mention handles introduce state, not allow for statelessness: not only the AS now has to keep a global state across all endpoints that may serve a given request, but also the client must keep a local cache of resource -> handle(s). Retry/restart logic has to be implemented, cache clearing logic must be implemented, state has to be kept between restarts of both sides, etc. This is definitely stateful.

              • m463 4 years ago
                Are you saying the handle concept in general? I have a theory that people convert to handles to "sanitize" apis that used to return a structure (and therefore an exploitable pointer).
                • topranks 4 years ago
                  You should be able to read the IETF mailing lists for the working group, and watch videos of discussions at IETF meetings.
                • part1of2 4 years ago
                  This is sounding like a repeat of the ambiguity from the other OAuth specs, leading to bugs, non-interoperability, and security problems.

                  Would you please send your comments to the working group?

                  • btilly 4 years ago
                    You say it like that ambiguity is a bad thing.

                    I came to understand OAuth2 much better when I realized that it exists to make the lives of big companies easier, and to make the lives of small developers possible. If BigCo only offers an OAuth2 API, then developers will figure it out because they have no choice. And from the point of view of big companies, what matters is that they implement something that meets their needs, which they can pretend is a standard.

                    Ambiguities give big companies the freedom to do the different things that they want to do while everyone claims, "We're following the standard!"

                    • chairmanwow1 4 years ago
                      OAuth 2 implementations are bizarrely different and frequently custom. Absolute nightmare to figure out the subtle differences based on who you are talking to
                      • Serow225 4 years ago
                        ding ding ding
                      • brazzledazzle 4 years ago
                        Maybe the assumption is that a complimentary standards like OIDC are necessary and expected?
                        • bostik 4 years ago
                          Thank you, good point. I did.
                        • nly 4 years ago
                          What's even sadder about this is that there are oven ready JSON serialization formats that support unions natively. Avro, for example, would serialize to something like

                              { "key": { "KeyHandle": "myhandle" } }
                          
                          and

                              { "key": { "FullKey": "myfullkey" } }
                          
                          They could just provide a schema and nobody would have to implement anything of the wire end.
                          • q3k 4 years ago
                            Same with protobuf JSON serialization (oneof, enforcing exactly one field of many is set).

                            But I think the authors were focused on using the shorted possible serialized JSON, no matter the implementation difficulty cost and the inability to use existing schema/IDLs. Which in my opinion is terribad for what is effectively a critical security standard.

                          • amw-zero 4 years ago
                            Lots of negativity around the polymorphic JSON types. I don't think this will be a problem at all in practice. It's fairly simple to limit the conditional that checks the type to exactly one place via a parsing step. This is basic OO - using factories to abstract conditionals. It will also mostly be handled by client libraries.
                          • parhamn 4 years 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.

                            • samprotas 4 years ago
                              The number of comments here specifically upset with this part of the current design is a bit discouraging, but not necessarily surprising.

                              Yes, many mainstream languages have near-zero support for Tagged/Discriminated Unions or Enums with Associated Data or Algebraic Data Types (pick your favorite name for the same concept). This is a limitation of those languages, which should not force a language-agnostic protocol to adopt the lowest common denominator of expressiveness.

                              Consider the problem they're avoiding of mutually exclusive keys in a struct/object. What do you do if you receive more than one? Is that behavior undefined? If it is defined, how sure are you that the implementation your package manager installed for you doesn't just pick one key arbitrarily in the name of "developer friendliness" leading to security bugs? This seems like a much more bug-ridden problem to solve than having to write verbose type/switching golang/java.

                              Implementing more verbose deserialization code in languages with no support for Tagged Unions seems like a small price to pay for making a protocol that leaves no room for undefined behavior.

                              To be clear, _many_ statically typed languages have perfect support for this concept (Rust/Swift/Scala/Haskell, to name a few).

                              • parhamn 4 years ago
                                > To be clear, _many_ statically typed languages have perfect support for this concept (Rust/Swift/Scala/Haskell, to name a few).

                                No they don't, at least in the way you're selling it. The "limitation" here is JSON which doesn't attach type information. You're going to have to implement some typing protocol on top of the JSON anyway which will face similar problems to the ones you raised (unless you do some trait based inference which could be ambiguous and dangerous).

                                If they were Enums/Unions over a serialization protocol like protobuf, maybe your case makes sense. Even then, Im guessing a large % of the OAuth 3 requests will go through Java/Golang libraries, so on a practical level this is a bad idea too.

                                • samprotas 4 years ago
                                  I agree that having multiple different types of "object values" share one JSON key with no explicit "type" tag is asking for trouble with extensibility and conflicts.

                                  That said, I think the constructive suggestion would be: "add a type tag to all objects in a union" (something suggested elsewhere in this thread).

                                  Their "handles" can still claim "just a string" to save bandwidth in the common case, arrays can still represent "many things" and objects require "type" to be dis-ambiguous.

                                  Most of the comments below don't mention the (real and important, but easily solvable) issue you've brought up however. They primarily fall into one of two buckets:

                                  - It's hard to work with data shaped like this in my language (ex: java/go)

                                  - It's hard to deserialize data shaped like this into my language that has no tagged unions (ex: java/go)

                                  My biggest counterpoint to all of these complaints is: The fact that your language of choice cannot represent the concept of "one of these things" doesn't change the fact that this accurately describes reality sometimes.

                                  A protocol with mutually exclusive keys (or really anything) by convention is strictly more bug-prone than a protocol with an object that is correct by construction.

                                • oaiey 4 years ago
                                  A protocol which is cumbersome to implement in many languages. Hmmm what can't go wrong. Partial support, late support of extensions, bugs,...

                                  IMHO: a very bad choice. Complicated basic and higher level elements of protocols are the death of them (remember SOAP). I follow the train of thoughts to not restrict yourself too much but if (eg) java or C++ cannot implement it easy, not a good idea.

                                  • samprotas 4 years ago
                                    Protobuf supports "oneof" which is also cumbersome to implement in these same languages but all of them support it (with some extra LOC and no exhaustiveness checking watching your back).

                                    Java/Go/C++ are perfectly capable of parsing a "type" key and conditionally parsing different shaped data. If you make a programming mistake here, you'll get a parse error (bad, but not a security problem). The pushback seems to be that a Java/Go/C++ implementation adds LOCS and won't gain much by doing this extra step so lets make the protocol itself match match their (less precise) data representation.

                                    FWIW there is work towards improving Java in this regard: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match....

                                  • Touche 4 years ago
                                    > This is a limitation of those languages, which should not force a language-agnostic protocol to adopt the lowest common denominator of expressiveness.

                                    It's an intentional decision made by those languages in order to focus on other things. If your intent is to be language-agnostic, then yeah, going with lowest common denominator concepts is exactly what you need to do. If you just want to write a Haskell auth implementation using your favorite pet language features, then write a Haskell auth implementation.

                                    • GordonS 4 years ago
                                      It's not the same as union types, but you can also often achieve polymorphic serialisation with any OO language, through the use of interfaces.
                                      • dgritsko 4 years ago
                                        My fingers are firmly crossed that DUs make their way into C# 10... https://github.com/dotnet/csharplang/blob/master/proposals/d...
                                      • sk5t 4 years ago
                                        I'm in vigorous agreement here--polymorphic JSON is far more difficult to deserialize safely, and every instance I've seen of this in the wild has been the output of careless or deeply ignorant makers.
                                        • kevincox 4 years ago
                                          Yeah, put a `type` tag in there and call it a day.
                                          • oblio 4 years ago
                                            I'm not sure I get this, does the data type change depending on context? Is that what they mean?
                                            • q3k 4 years ago
                                              It means sometimes you'll get:

                                                  { foo: { bar: "baz" }}
                                              
                                              and other times you'll get

                                                  { foo: "something else" }
                                              
                                              Good luck!
                                              • maerF0x0 4 years ago
                                                Polymorphic JSON is such a PITA for strongly typed languages.

                                                    var data map[string]interface{}
                                                    //.. 
                                                    switch t := data["foo"].(type) {
                                                         case string:
                                                         case interface{}
                                                    }
                                                
                                                
                                                imagine that for every key...
                                                • rmrfrmrf 4 years ago

                                                      { foo: { length: 1.7976931348623157e+308 } }
                                                  • sroussey 4 years ago
                                                    So, like Apple and in app payments then...
                                                  • golergka 4 years 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 4 years 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.

                                                      • alyandon 4 years ago
                                                        Lovely - I can't wait to see how horrible something like that is to implement in a language like Go.
                                                      • mumblemumble 4 years ago
                                                        Yeah, pretty much exactly that.

                                                        The only time I've had to deal with it in the wild was a terrible experience. As a consumer, you couldn't make any decisions with confidence without first making a careful study of the documentation. For every. single. decision.

                                                      • nyanpasu64 4 years ago
                                                        YAML has !Tag syntax for expressing polymorphism. Shame that nobody uses YAML because the standard is so complex, and shame that AppVeyor uses a single-element key-value mapping instead of a tag for this purpose...
                                                        • thosakwe 4 years 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.
                                                        • bojanz 4 years 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/

                                                        • qwerty456127 4 years 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.

                                                          • fyfy18 4 years ago
                                                            What you are talking about is OpenID Connect, not OAuth. It does use OAuth 2.0 under the hood, but they are two separate protocols.

                                                            OAuth is an authorization protocol. It can be used (for example) to give Facebook access to your Flickr photos without having to give out your Flickr username and password to Facebook or share API tokens, and have a standardized way to revoke access when you realise Facebook scraped all your private photos.

                                                            • ownagefool 4 years ago
                                                              Actually, OpenID Connect is an SSO product. Whilst it can be used to federate your auth to other providers, you're probably thinking of OpenID, which is "social login".
                                                              • ForHackernews 4 years ago
                                                                No, parent commenter is correct: OpenIDConnect is an extension protocol that adds a user-authentication (user metadata) layer on top of OAuth 2, which is a bare authorization protocol (access tokens are opaque and don't say anything about the user).

                                                                Besides the similar names, OpenIDConnect has virtually nothing to do with the older OpenID protocols. Old-style OpenID has been deprecated and removed by almost all web properties today (e.g. https://meta.stackexchange.com/questions/307647/support-for-...)

                                                            • namanaggarwal 4 years 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)
                                                              • jrockway 4 years ago
                                                                Is this even a provider issue? If an application asks for scopes=[profile] then the OAuth provider has two choices -- categorically deny it, or ask you to authorize it. They all ask you to authorize it, and you can say no, and then the app doesn't work because the developers decided that you can't use their app unless you give them your profile information.

                                                                The app could easily ask you to check a checkbox next to each scope, and then write separate code for each combination of checkboxes. They decided not to do that because it's probably not worth your business if you don't want to give them full access. (Honestly, I click a lot of things on HN that ask for way too many scopes, and then I close the window and forget what it was. But the calculation was done -- they don't need me as a user or customer. I can live with that.)

                                                                I guess what people want is an IDP that will give applications fake data when you deny a scope. But no application developer wants to deal with that complexity, so they'd never integrate a provider that does that. (They probably moved away from email+password because of all the fake emails that people provide.)

                                                                On the other hand, it's mandatory for iOS apps to use Apple's sign-in which auto-generates a fake email address for you. So I suppose some progress is being made. (I have an iPhone but I've never seen this supposedly mandatory OAuth provider. I only know about it from reading HN. So maybe it doesn't actually exist? I have no idea really.)

                                                                • btown 4 years ago
                                                                  Auto-generating a single-use profile, or letting you choose a pseudonym, is absolutely a compromise that more identity providers should implement.
                                                                  • namanaggarwal 4 years ago
                                                                    Yes it is really provider issue. Apple implemented it and so can any other provider.

                                                                    I also don't think people want an IDP that provides fake data when you deny a scope. That's a bad implementation IMHO. When you say no that means you don't authorize access for that scope, not that send fake data. Applications should deal with it.

                                                                  • qwerty456127 4 years 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.

                                                                    • magicalhippo 4 years ago
                                                                      But there's nothing in the spec that requires you to disclose that data to begin with.

                                                                      And there's nothing they could write in the spec to deny that besides a perfunctory "please don't do that" which companies could ignore without consequence.

                                                                      • muyuu 4 years ago
                                                                        OAuth does what you want, but also does what you don't want.

                                                                        This is like Android allowing apps to ask for permissions they don't "need" because, well surveillance and user data brokerage is the business model that most are info and the reason many apps are "free" or "cheap" in the first place, crowding out more honest business models.

                                                                        Maybe there could be an initiative for apps and sites without predatory practices, like "apps/webs needing no personal info from you"

                                                                    • mattlutze 4 years 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.
                                                                      • pharaohgeek 4 years ago
                                                                        OAuth isn't solely about social networks. There are a number of corporations that use it for delegated authorization. A financial aggregator and a bank, for example. A large number of SaaS providers support G-Suite logins for enterprise customers as well.
                                                                        • oaiey 4 years ago
                                                                          Oauth2 / OIDC is essentially next to SAML the only serious identity provider protocol in the single sign on space.

                                                                          Ignoring LDAP and Active Directory for now.

                                                                        • asah 4 years ago
                                                                          Create a new/throwaway email account. Granted this is annoying.
                                                                        • slooonz 4 years 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.

                                                                          • fuzzy2 4 years ago
                                                                            OpenID and OAuth are different things though? Sure, OpenID Connect is built on top of OAuth 2.0, but OAuth 2.0 is a general authorization solution. You couldn’t just interact with arbitrary APIs so there’s really no point in creating a bring-your-own-API-server thing.
                                                                            • magicalhippo 4 years 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?

                                                                              • IshKebab 4 years ago
                                                                                That's probably like 30% of the uses of OAuth (e.g. granting Azure Pipelines access to your GitHub repos). 70% is just outsourcing identity and authentication (log in with Google / Facebook / etc.) In those cases the only data they access is your email, profile image, etc.

                                                                                As a website developer I would definitely appreciate something like OpenID but actually usable/popular. Having to implement a ton of "log in with"s sucks, as does implementing email based login.

                                                                                • sk5t 4 years ago
                                                                                  > Having to implement a ton of "log in with"s sucks, as does implementing email based login.

                                                                                  This is kind of auth0's--but also most security token service things--raison d'etre: your app trusts just one authority and supports just one protocol, shunting any unauthenticated users to it, letting it handle the transaction with trusted identity providers.

                                                                                  • stopyellingatme 4 years ago
                                                                                    100% agreed. I would love to find a language or library that makes one or both of them trivial.
                                                                                  • inopinatus 4 years ago
                                                                                    GP has written authorisation but they must mean identification, because only a resource owner can perform authorisation, not some random external service.
                                                                                    • chrisweekly 4 years ago
                                                                                      authN = autheNtication (identity / "who are you")

                                                                                      authZ = authoriZation (access / "what are you allowed to do")

                                                                                      • part1of2 4 years ago
                                                                                        Also, in general

                                                                                        OAuth => think authZ

                                                                                        OIDC => think authN

                                                                                    • lode 4 years ago
                                                                                      Indeed. I miss OpenID, and the promise it had.
                                                                                      • random5634 4 years ago
                                                                                        Same here. I even setup an openid provider using my domain - was great!
                                                                                        • mooreds 4 years ago
                                                                                          Me too! I just checked and I still have the headers in my html. Should probably remove them :)
                                                                                      • zemnmez 4 years ago
                                                                                        OpenID Connect is a superset of OAuth 2.0 so I find this an odd comparison. Assumedly there'll be an authN OIDC OAuth 3.0 protocol too.
                                                                                        • mooreds 4 years ago
                                                                                          I was excited about OpenID around 2010. I wasn't aware it was still possible to use; most of the services I've looked at either support OIDC (built on top of OAuth) or SAML.

                                                                                          How could the specification support letting the end-user pick their authorization provider? Should the RC suggest the AS instead of the RS doing so?

                                                                                          • CodesInChaos 4 years ago
                                                                                            The user could enter an email-like identity, where the domain part determines the provider.
                                                                                        • mattlutze 4 years 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 ^

                                                                                          • mooreds 4 years ago
                                                                                            I'd also suggest wading through the actual protocol draft as opposed to the higher level articles linked on the submitted page:

                                                                                            https://www.ietf.org/archive/id/draft-ietf-gnap-core-protoco...

                                                                                            • dt3ft 4 years ago
                                                                                              I wish they wouldn't use mailing lists. Keeping track of threads/topics must be a nightmare.
                                                                                              • znpy 4 years 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?

                                                                                                • tzs 4 years ago
                                                                                                  The alternative is newsgroups and NNTP.

                                                                                                  They are open, technology agnostic, interoperable, and most news readers are way better at threaded discussions involving more than two people than almost every email client.

                                                                                                  • dt3ft 4 years ago
                                                                                                    You sound like someone who never used GitHub/GitLab/Jira/Any forum which offers categories/topics/threads and their respective issue tracking/organizing features.
                                                                                                    • pas 4 years ago
                                                                                                      GitLab issues?
                                                                                                      • Avamander 4 years ago
                                                                                                        They are not.

                                                                                                        Gitea, GitLab, GitHub, Bitbucket, Discourse literally everything else similar to those is more usable than the pieces of turd that mailing lists are. I instantly assign a negative score in my mind to all projects that still find them in any way usable.

                                                                                                      • bo1024 4 years ago
                                                                                                        Depends on your email client and whether people start a new thread for each topic, I think. Email has more than enough metadata to be displayed like reddit threads, or slack/zulip messages, etc. if you so choose.
                                                                                                        • mattlutze 4 years ago
                                                                                                          Benefit of a mailing list is that you have a wonderful distributed history of a thing, don’t have to own & maintain a large website/app, and everyone has some way to have and use email for free
                                                                                                      • swiley 4 years 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.

                                                                                                        • tg3 4 years ago
                                                                                                          > I really wanted to like OAuth but implementing it is a nightmare!

                                                                                                          Not only is the spec itself challenging, it leaves enough ambiguity and rough edges that most providers end up extending it some way that makes it hard to standardize. Most commonly: how to get refresh tokens (`offline_access` scope, `access_type=offline` parameter?), and how/when they expire (as soon as you get a new one? as soon as you've received 10 new ones? on a set schedule?)

                                                                                                          And that's not to mention how OAuth gets extended to handle organization-wide access. Anyone that's dealt with GSuite/Workspace Service Accounts or Microsoft Graph Application permissions knows what a pain that is.

                                                                                                          This is exactly why I built [Xkit](https://xkit.co), which abstracts away the complexity of dealing with all the different providers and gives you a single API to retrieve access tokens (or API keys) that are always valid. Not everyone should have to be an OAuth expert to build a 3rd party integration.

                                                                                                          • mooreds 4 years ago
                                                                                                            Are you talking about RFC 8705 ( https://www.rfc-editor.org/rfc/rfc8705.html )? I've researched this a bit and heard that deployment is problematic.

                                                                                                            From a brief search, it looks like let's encrypt doesn't have great support for them ( https://community.letsencrypt.org/t/can-i-create-client-cert... ) so you are stuck setting up a private CA?

                                                                                                            Have you set up client side certs? I'd love to hear your experience if so.

                                                                                                            BTW, I'd defer implementing OAuth to a library or specialized piece of software (full disclosure: I work for a company providing this). There are a number of options, paid and open source out there.

                                                                                                            • Avamander 4 years ago
                                                                                                              > Have you set up client side certs? I'd love to hear your experience if so.

                                                                                                              Entire Estonia and a few other countries use them daily. For logging into banks, Craigslist-equivalents, online stores, service providers etc. etc.

                                                                                                              • mooreds 4 years ago
                                                                                                                Thanks for the pointer. Here's an interesting article on using the Estonian client cert:

                                                                                                                https://wandernauta.nl/2015/08/27/estonian-id-with-nginx-and...

                                                                                                                • chrisshroba 4 years ago
                                                                                                                  Interesting! Why does the distinction of a country matter here? I mean - why would using client side certs be something a country as a whole uses, as opposed to a certain type of company or something? Does it have to do with some sort of national firewalls or anti-encryption laws?
                                                                                                                • bebop 4 years ago
                                                                                                                  In my opinion, client certificates are great, you can let existing crypto infrastructure deal with the problem of "who is this user?".

                                                                                                                  The biggest problem is around revocation. You need to have some central revocation list and make sure that all of the users of your PKI are keeping that list up-to-date in production, which can be difficult if you do not plan for that from the start.

                                                                                                                • GordonS 4 years ago
                                                                                                                  Not sure if you're referring to a particular spec or something, but we used client certificates as a 2nd factor to control access to an extranet web app, almost 15 years ago, long before OAuth, and when 2FA was only just beginning to come into existence.

                                                                                                                  From a security standpoint, it's pretty great. But the reality of generating keys and signing and distributing certificates was horrible, and our users were confused and hated it.

                                                                                                                  How would you solve key generation even now - assuming the client generates the key, is it locked to that browser on that machine? How do you generate a CSR (certificate signing request)? How do you send the signed certificate to the user? How does the user install the certificate? Again, does that mean the user can only access your app from the machine they installed the certificate to?

                                                                                                                  PKI is hard, mainly because of the distribution problem.

                                                                                                                  • bo1024 4 years 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 4 years 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 4 years 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”.
                                                                                                                        • Avamander 4 years ago
                                                                                                                          > Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication

                                                                                                                          Chrome has an interface for it.

                                                                                                                        • q3k 4 years ago
                                                                                                                          This is exactly how TLS client certificates work - except that instead of the server storing the public keys of clients, the clients present a cryptographic proof generated by the server/CA that they represent some identity (ie., a certificate).
                                                                                                                          • chipsa 4 years ago
                                                                                                                            Uh?

                                                                                                                            They normally store the User Principal Name from the cert, and then use the public/private key as part of the connection. Specifically, the connection is negotiated after the client sends the public client certificate, and uses it as part of the key exchange.

                                                                                                                            It doesn't necessarily need to store the public key, but it does need to store which certificate goes with which account. And the certificate is validated by checking that it's been issued by a CA the server trusts.

                                                                                                                          • GoblinSlayer 4 years ago
                                                                                                                            Private key is not much better than a strong password. A certificate would physically identify you and would allow to apply social credit system.
                                                                                                                            • cestith 4 years ago
                                                                                                                              You're familiar I'm sure with your browser authenticating that a TLS certificate is within its valid date range and assigned to the hostname of the server? You're probably also aware that your OS and/or browser have a list of certificate authorities one of which must have signed the certificate (or via a chain of CAs from a trusted root, with each CA cert signed by one closer to the root). Client certs work the same way except it's the server verifying all of this for the client (browser, mail user agent, whatever).

                                                                                                                              At $work we have several systems in which the server only accepts requests, or only accepts certain kinds of requests, from clients with client certificates with specific restrictions. Depending on the application and its authN/authZ needs, any of the solutions I'm about to mention might be combined with some combination of a username/password, with a time-based token, a JWT, IP range restrictions, an API key, or whatever else in addition to the client cert requirement - or sometimes the cert is sufficient by itself. Some just trust anything that was issued by the right CA and is in its proper date range. Sometimes we also verify that the certificate matches an assigned hostname of the client. Sometimes we trust certs by the right CA to connect, but parse the hostname out of the cert and check whether that client's hostname or the subdomain it's in has authorization to do certain things. Semantic hostnames might look long and confusing at first, but they can be used very easily for things like that. Semantic host names and naming schemes could be its own article.

                                                                                                                              This isn't a general use case for the general public because of deployment headaches. Which CAs do we trust? Is it the same as those issuing server certs? Will services be set up especially to issue client certs? Who's supporting the users to get the certs installed, many of whom enter the wrong email when signing up for services? We can do this in a corporate network pretty easily. We have automation systems for servers. We have another, different automation system for administration of Laptop, desktop, and mobile client devices. We just put what cert we want everywhere we want it.

                                                                                                                              A big problem I see with client certs and the general public is multi-device users. If you're logging into Google from your home desktop, your work desktop, a couple of laptops, a tablet, and a phone that's one email address but half a dozen different certificates. Some applications, especially cross-platform ones, insist on their own certificate store even if the OS provides a shared one. So for mail, a couple of browsers, and two other native apps, congratulations that's maybe two dozen. One can export and import client certs, but there's no simple way to get less technical end users to do that. So do we make it easier to configure multiple client devices and all their applications with the same certificate and key? Are end users going to remember to update them all when one is lost in a breach or it expires? Or do we expect all the service providers to trust multiple certificates signed by multiple different CAs for each user, then have the user upload the public (but not the private!) part of each cert/key pair to all of those services to say they should be trusted? Or does every service require its own CA to sign your cert for its own service, so you need an Apple cert, a Google cert, an Amazon cert... ad nauseum?

                                                                                                                              Tools like Bitbucket or Gitlab let you upload your public SSH key in the web UI to provide auth for the git repos. You can also have (hopefully with separate keys) automated applications that interact with git auth against a repository or all the repos in a project. That's the sort of interface one might expect a web application to offer for TLS certificates. *

                                                                                                                              * A certificate is basically the public key portion of a public/private key pair that's been signed by some CA. Preferably that CA is a broadly trusted one, except in very particular circumstances.

                                                                                                                              • bo1024 4 years ago
                                                                                                                                Thanks, this explanation and discussion is very helpful. It does confirm how I suspected things to work.

                                                                                                                                I have trouble understanding the need for the "signing" part of client-side certificates. Currently if I create an account at a website with a username/password, there's no need to get my account signed by a trusted third party. So why not let me create the account with a username/publickey instead? Why does a third party CA need to be involved?

                                                                                                                                And actually (as I mentioned in another post just now), one thought is to have keypairs supplement passwords rather than replace them. Basically when I move to a new device, I can still log in to the website with a password, and then the site will give me the option to add the device's public key so I can seamlessly log in automatically next time.

                                                                                                                                • 0xCMP 4 years ago
                                                                                                                                  Ideally they would run some kind of CA and users would generate keys local to the device with some kind of alternate authentication when setting up the device initially.

                                                                                                                                  Generating keys is cheap and the fact that your key could be tracked across services is a problem you'd want to avoid upfront. This is already an issue with things like SSH where you can finger-print devices when they present their public keys.

                                                                                                                                  When signing up the user could be given the option to enable alternate authentication via FIDO2, Password, or Passwordless (email). Otherwise authenticating another device works by approving a new device from an existing one.

                                                                                                                            • znpy 4 years 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 4 years 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.
                                                                                                                              • jwr 4 years 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.

                                                                                                                                • GoblinSlayer 4 years ago
                                                                                                                                  "I will send details over email" should be easy to say over a phone.
                                                                                                                                  • anentropic 4 years ago
                                                                                                                                    I always assumed it was pronounced O-Auth, like T-Shirt
                                                                                                                                    • masukomi 4 years 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 4 years 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 4 years 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.

                                                                                                                                    • secretsatan 4 years ago
                                                                                                                                      The medium page with the "Case for OAuth3" requires a sign in, kinda feel like it shouldn't
                                                                                                                                      • orthecreedence 4 years ago
                                                                                                                                        Kinda feel like people should stop using Medium for anything.
                                                                                                                                      • gnur 4 years 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 4 years ago
                                                                                                                                          I think it's called XYZ until it's ready to be called Oauth 3.
                                                                                                                                          • mooreds 4 years ago
                                                                                                                                            It's called GNAP: https://datatracker.ietf.org/wg/gnap/documents/

                                                                                                                                            The "Grant Negotiation and Authorization Protocol"

                                                                                                                                            • valera_rozuvan 4 years 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-5c...

                                                                                                                                              • LeonM 4 years 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.

                                                                                                                                                • detaro 4 years 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
                                                                                                                                                • faichai 4 years 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-5c...

                                                                                                                                                  • jricher 4 years 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 4 years ago
                                                                                                                                                      No worries, I wasn’t trying to ascribe any personal fault. Figured it was more a Medium product issue.
                                                                                                                                                    • jayzalowitz 4 years ago
                                                                                                                                                      If only someone created a well known technically focused contributor based medium competitor that doesnt have a paywall!!
                                                                                                                                                    • callamdelaney 4 years ago
                                                                                                                                                      But the last two were already so painful..
                                                                                                                                                      • detay 4 years ago
                                                                                                                                                        better prepare for OAuth 3.0 bounties. a man's gotta eat.
                                                                                                                                                        • speedgoose 4 years ago
                                                                                                                                                          Becoming a farmer sounds more appealing to me than reading and understanding the oauth3 RFC and the implementations.
                                                                                                                                                        • vmception 4 years ago
                                                                                                                                                          Oh god another decade of this bullshit
                                                                                                                                                          • ilikehurdles 4 years ago
                                                                                                                                                            My thoughts exactly. It comes across as an organization creating technical debt to justify its own existence.
                                                                                                                                                            • vmception 4 years 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
                                                                                                                                                          • huma 4 years ago
                                                                                                                                                            • ansonhoyt 4 years 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.
                                                                                                                                                              • pmlnr 4 years 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 4 years 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-protoco...

                                                                                                                                                                  [1]: https://mailarchive.ietf.org/arch/msg/txauth/UkvrBXkMk9YMl7m...

                                                                                                                                                                  [2]: https://datatracker.ietf.org/wg/gnap/about/

                                                                                                                                                                  [3]: 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/

                                                                                                                                                                  • will4274 4 years 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.

                                                                                                                                                                    • mooreds 4 years ago
                                                                                                                                                                      Ah, in my opinion, it's better to be able to build an object then serialize it, rather than have to jam object semantics into form parameters (and then serialize them).

                                                                                                                                                                      Here's a grant request from the draft:

                                                                                                                                                                         {
                                                                                                                                                                             "resources": [
                                                                                                                                                                                 {
                                                                                                                                                                                     "type": "photo-api",
                                                                                                                                                                                     "actions": [
                                                                                                                                                                                         "read",
                                                                                                                                                                                         "write",
                                                                                                                                                                                         "dolphin"
                                                                                                                                                                                     ],
                                                                                                                                                                                     "locations": [
                                                                                                                                                                                         "https://server.example.net/",
                                                                                                                                                                                         "https://resource.local/other"
                                                                                                                                                                                     ],
                                                                                                                                                                                     "datatypes": [
                                                                                                                                                                                         "metadata",
                                                                                                                                                                                         "images"
                                                                                                                                                                                     ]
                                                                                                                                                                                 },
                                                                                                                                                                                 "dolphin-metadata"
                                                                                                                                                                             ],
                                                                                                                                                                             "client": {
                                                                                                                                                                               "display": {
                                                                                                                                                                                 "name": "My Client Display Name",
                                                                                                                                                                                 "uri": "https://example.net/client"
                                                                                                                                                                               },
                                                                                                                                                                               "key": {
                                                                                                                                                                                 "proof": "jwsd",
                                                                                                                                                                                 "jwk": {
                                                                                                                                                                                             "kty": "RSA",
                                                                                                                                                                                             "e": "AQAB",
                                                                                                                                                                                             "kid": "xyz-1",
                                                                                                                                                                                             "alg": "RS256",
                                                                                                                                                                                             "n": "kOB5rR4Jv0GMeL...."
                                                                                                                                                                                 }
                                                                                                                                                                               }
                                                                                                                                                                             },
                                                                                                                                                                             "interact": {
                                                                                                                                                                                 "redirect": true,
                                                                                                                                                                                 "callback": {
                                                                                                                                                                                     "method": "redirect",
                                                                                                                                                                                     "uri": "https://client.example.net/return/123455",
                                                                                                                                                                                     "nonce": "LKLTI25DK82FX4T4QFZC"
                                                                                                                                                                                 }
                                                                                                                                                                             },
                                                                                                                                                                             "capabilities": ["ext1", "ext2"],
                                                                                                                                                                             "subject": {
                                                                                                                                                                                 "sub_ids": ["iss-sub", "email"],
                                                                                                                                                                                 "assertions": ["id_token"]
                                                                                                                                                                             }
                                                                                                                                                                         }
                                                                                                                                                                      
                                                                                                                                                                      (Not all of the object keys are required, FYI). The ability to have resources be a rich object (as opposed to a string) and to support multiple resources in one grant request seems to me to be a good thing(tm).
                                                                                                                                                                  • skrowl 4 years ago
                                                                                                                                                                    Just calling this link "OAuth 3" is clickbait
                                                                                                                                                                    • ratiolat 4 years ago
                                                                                                                                                                      I wish they renamed the thing to OAuthorize. The current name is confusing. It's not for AUTHentication, it's for AUTHorization.
                                                                                                                                                                      • ancymon 4 years 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?
                                                                                                                                                                        • preommr 4 years 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.
                                                                                                                                                                          • tenplusfive 4 years 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 4 years 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

                                                                                                                                                                          • self_awareness 4 years 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.

                                                                                                                                                                            • pwdisswordfish4 4 years 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 4 years ago
                                                                                                                                                                                You could spare your answer, since it's not providing any information at all.
                                                                                                                                                                                • pwdisswordfish4 4 years ago
                                                                                                                                                                                  Ruling out the truth of something is information-free, and mentioning an RFC by ID is information-free. Got it.
                                                                                                                                                                              • dathinab 4 years 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...

                                                                                                                                                                                • will4274 4 years ago
                                                                                                                                                                                  > 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 4 years ago
                                                                                                                                                                                    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 4 years ago
                                                                                                                                                                                      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 4 years 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