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!?

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.

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

> 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...

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).

You should be able to read the IETF mailing lists for the working group, and watch videos of discussions at IETF meetings.

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!"

Maybe the assumption is that a complimentary standards like OIDC are necessary and expected?

Thank you, good point. I did.

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.

> 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.

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.

> 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.

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.

My fingers are firmly crossed that DUs make their way into C# 10... https://github.com/dotnet/csharplang/blob/master/proposals/d...

It means sometimes you'll get:

    { foo: { bar: "baz" }}

and other times you'll get

    { foo: "something else" }

Good luck!

> 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.

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.

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".

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.)

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.

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.

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.

GP has written authorisation but they must mean identification, because only a resource owner can perform authorisation, not some random external service.

authN = autheNtication (identity / "who are you")

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

Same here. I even setup an openid provider using my domain - was great!

The user could enter an email-like identity, where the domain part determines the provider.

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?

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.

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

> 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.

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.

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.

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).

Private key is not much better than a strong password. A certificate would physically identify you and would allow to apply social credit system.

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.

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.

No worries, I wasn’t trying to ascribe any personal fault. Figured it was more a Medium product issue.

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

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).

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.

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.

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

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

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.