Comment by guessmyname | Hacker News Reader

Comment by guessmyname | Hacker News Reader

Parent Full thread

I implemented more than a dozen OAuth integrations last year with multiple American and Chinese companies and oh boy it was painful.

I do not know why so many engineers end up reading a clear specification document like RFC-6749 [1] and then ignore 80% of the instructions. I had to deal with so many weird bugs and bad OAuth server implementations, I lost count of how many emails went back and forth trying to make sense of unexpected behavior.

Even Apple engineers got it wrong. They decided to create their own thing based on OpenID Connect for “Sign In With Apple” [2]. OpenID had to write an open letter [3] explaining the repercussions of their changes and fortunately were able to convince Apple to fix the implementation [4].

OpenID was lucky though, they had some leverage, but a no-one like me couldn’t possibly convince a gigantic conglomerate like Tencent to fix their web API. Talking with Tencent engineers has been one of the worst experiences in my career. The company apparently has a culture of constant job rotations, engineers are assigned projects for short periods of time with bonuses for early completion which encourage them to deploy half-finished code before moving to something else.

[1] https://tools.ietf.org/html/rfc6749

[2] https://developer.apple.com/sign-in-with-apple/

[3] https://openid.net/2019/06/27/open-letter-from-the-openid-fo...

[4] https://openid.net/2019/09/30/apple-successfully-implements-...

Oh man, I've done Google, Facebook, Reddit and all of them have tiny but annoying differences in their Auth Flow. I've given up up on Twitter, because they didn't even seem to support OAuth2 (maybe they do now?), but it was too much of a pain.

What's also very annoying is the need to register an "application" at the provider. So i.e. for Facebook you have to login into their developer portal, create an app, fill out all the stuff they want to know, and then rely on them to approve your app. You have to do this for each and every provider, and for each application you want to support, and of course they all have different developer portals and want to know varying amounts of information... I've given up on Instagram OAuth because it seemed to much hassle to get your application approved.

Don't know why this is necessary, there should be a simple straightforward spec solely for Auth, that doesn't require all these steps.

Client registration is so that (1) the authorization server can obtain the client type (confidential or public), then, (2) if appropriate, obtain the client's Redirection Endpoint URI, so that the authorization server's authorization endpoint can avoid needing to be an open redirector, and (3) to obtain any metadata that the authorization server will display to the resource owner just prior to them approving or denying the authorization request. The spec explains this [1].

Also, service providers who are custodians of the resource owners' data want you to be accountable to them and their users, so they want to have some information about you.

There's a proposed standard for dynamic (and/or programmatic) client registration [2]. While there are some interesting use-cases, it offers little benefit to a service provider who wants to vet clients (or appear as if it did).

The spec contains some design recipes if you want a loose association between which clients are allowed to receive data the user approved (i.e. implicit grant), if you care little about whether the user trusts your app (i.e. resource owner password credentials grant), or if you care little about user approval (i.e. client credentials grant). The catch is that your unilateral opinions are insufficient: the client and service provider need to be in agreement about whether these are okay to use.

And, as is often the case with "kitchen sink"-type specs, these other usage modes muddy the waters around the safer and saner usage modes, so much of the current advice on OAuth2 focuses on dissuading their use.

[1] https://tools.ietf.org/html/rfc6749#section-2 [2] https://tools.ietf.org/html/rfc7591

Technically unregistered clients are within spec. IndieAuth is one such implementation, focused on federated services. Aaron Parecki has a good writeup here[0]. Unfortunately that's not going to help you when playing with the big boys.

[0]: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

There's a spec for dynamic registration of clients for Oauth2/OIDC if I recall correctly. There's a reason that you have to register, and it's because you're potentially obtaining information about users, and they need a way to be able to block specific (potentially malicious) clients using their IDP.

When I was looking up the OAUTHBEARER draft, there's a (OPTIONAL) field in the error response to point to the openid-configuration for dynamic registration. At the time I was implementing things for Thunderbird, no one was using this yet, and I would be surprised if this has actually been implemented by any major provider in any sort of usable way for clients.

Yeah no one uses it because they explicitly want you to authenticate to register the clients on the users behalf so they can lock you out if you abuse it. It's annoying, but it makes sense. Otherwise an abuser can just dynamically create new clients anytime their existing clientID is banned.

Did you end up implementing it in Thunderbird? We're looking to do that at my company and I'm currently implementing OAUTHBEARER in cyrus-sasl (which then could be used in cyrus-imapd & postfix)

I haven't implemented it myself, and as far as I'm aware, it hasn't been in the past few years. If it is going into cyrus-sasl, then I can probably put together containers for testing (which is on my work todo list anyways).

One particularly nasty annoyance I've discovered recently is SoundCloud, which describes in great detail how to use their API and how to register applications, except when you actually try to do that, you discover that they "temporarily" disabled application registration several years ago and never re-enabled it.

> "Don't know why this is necessary"

Ok so the other replies here clarify why — but really it'd have been nice if there was at least some consistent interface between all the OAuth / OIDC providers, so one wouldn't need to learn new interfaces all the time.

... And, worse, now I need to take screenshots and document all these different interfaces, for an open source project I'm building, whose users might want to register OIDC client apps too. :- /

I can only give my perspective, which is likely to be unique. I'm in the process of implementing an Oauth2 server for the first time. I feel like I have a handle on it now, but it was definitely overwhelming at first. If I were confident that RFC6749 had everything in it that I needed, I would read through and implement it. But it quickly became apparent that there are a dizzying array of RFCs with extensions, deletions, and best practices. So I just skipped the specs, and have been using resources like this, Oauth2 Simplified, and of course YouTube.

So I guess the upshot is I find resources like this and the upcoming 2.1 to be valuable.

Don't implement your own, there's tons of open source that can do that, for example https://github.com/ory/hydra

Thanks for the link. I'm rolling my own for a reason. I'm working on not only an Oauth2 implementation, but also a specification for using Oauth2 for filesystem operations (btw if you're aware of such a thing existing already, I'd love to hear about it). So I need to be intimately familiar with Oauth2. I wasn't originally planning to use it, but ultimately it's close enough to what I need, and for better or worse users are familiar with the flows.

> btw if you're aware of such a thing existing already, I'd love to hear about it

Since OAuth is pretty coarse-grained, you tend to have: - A client has a policy configured for the file sharing service or file collection, and does not use e.g. the scope parameter to request particular permissions - A file collection lets scopes be assigned particular permissions, and a client requests access by requesting one or more scopes

Although I am not a fan of the level of complexity it adds, UMA (User Managed Access) makes a pretty strong attempt at solving these sorts of problems as well.

But why do they have to be coarse-grained? If you have a cloud storage provider, why not allow scopes to be set per path, like this:

scope="/dir1:read /dir2:write /dir3/file.txt:read"

Then when the authorization screen is presented, the user could even modify the permissions granted on the fly.

Usually applications only need a single directory to store data, and it shouldn't matter to the app where that directory is in relation to the rest of the user's data. In that case you could do something like this:

scope="dir?:write"

Which tells the authorization server to present the user with a directory picker, so the user has control over where the data is stored. It doesn't make any sense to give write permissions to all your data for every single application.

After 5 minutes of poking around, I still don't understand how exactly UMA works in relation to Oauth2. I agree it seems to be pretty complex.

2.1 will hopefully be a one stop shop for implementors. At least, when I was writing a post about OAuth 2.1, that was the intention of the authors, from what I read on the mailing list.

I always wonder why do companies have to implement oauth2/open id connect. It seems like a big waste in tech to spend so much time implementing the same things by different companies.

can you tell me if there is a good drop in component that I can add to my product and integrate easily to get oauth2/open id connect? I heard good things about identity server but would appreciate if you could share your opinion on it.

At least one problem is that Oauth2 isn't a protocol; it's a framework for making protocols. Things like endpoints, scopes, security practices, etc aren't prescribed, so every implementation is different. And unfortunately none of the big players are really incentivized to standardize anything.

OIDC is basically a protocol, and is what you're describing. It's _the_ attempt to standardize on a common set of scopes, discovery mechanisms, etc for making it easier to build apps that use OAuth2.

And the platforms that do support OIDC properly just require a login portal URL to integrate support for it.

Want to add Microsoft logins with an oidc library? One url.

Want to add Twitter / Facebook signin? Go get an OAuth library and write several hundred LOCs to detail the scopes and crap you want form them because they are non-standard.

Forgive me if I'm mistaken, but isn't OIDC for authentication/profile information? Does it include standards for things like accessing contact lists, reading/writing files, sending email, etc?

OIDC is for authentication and profile information. The standard claims refer to each field of profile information [1].

It doesn't include any domain-specific operations like your examples.

[1] https://openid.net/specs/openid-connect-core-1_0.html#Standa...

A bit late: you're correct, but it does provide a standard API for looking up additional metadata, even if it's non-standard. That's using custom claims and/or the user info endpoint (which can include custom claims). You can use custom scopes to limit what is available as well.

I've recently tried out Keycloak(https://www.keycloak.org/) and have been impressed with it. Saved at least a few weeks on a personal project. It does have a learning curve though.

This, so much.

I've been tasked with implementing oauth/openid at work and in about one month in spare time i was able to read rfc 6749, install keycloak, configure it, create a client, create a very basic app (~80 lines of python and flask) and log in via oauth/openid with user information and groups pulled via LDAP.

Keycloak is really a game changer.

This presentation is very interesting: https://www.youtube.com/watch?v=FyVHNJNriUQ

I've been usjng keycloak as an UMA authorization server, and while it's better than nothing it has a few bugs that make it not exactly compliant with the spec. Additionally the UI is incredibly confusing and the documentation isn't that helpful in some cases. Anything you want to do you have to spend too much time searching the UI and some things are not even available: Want to assign ownership of a resource to a user? Need to run a curl request. Though I haven't tried other implementations, so maybe this one's the best

Keycloak is a great open source identity server that supports openid connect. Works out of the box but also allows for full customization as well. Whatever you do, don't write your own oauth server.

Hydra looks like another popular open source solution, but it leaves you to implement the user login and challenge.

I have been writing a hobby OpenID server as a way to learn Go and to understand auth. Reading the OpenID connect spec is SO much more educational & clearer than the OAuth RFC on its own.

> Whatever you do, don't write your own oauth server.

I wish I could upvote this 10 times. There are open source solutions. There are closed source solutions. There are SaaS solutions.

Pick a solution that meets your needs. Build the differentiating features of your app, not an OAuth server.

Any recommendations or favorites, and any to avoid?

Hiya,

I'm employed by a company which provides an OAuth implementation which I think is worth evaluating; you can look at other comments on this post or in my profile for more details. Happy to chat more over email, which is also in my profile, if that'd be helpful.

Since I don't know your use cases or needs, I would like to take a step back and think about what a developer might think about when evaluating this type of decision. Here are some things I'd consider:

* what does your organization currently use? If your org has experience with an identity solution, I'd evaluate that very seriously. It might not fit all your needs, especially if it is focused on IAM (identity and access management) as opposed to CIAM (customer identity and access management) but since your org uses it and presumably knows how to operate it, start there.

* cost of a solution. What does it cost to run the solution every month? What costs to set up the solution? Don't forget to estimate the time of staff to operate--even if I handed you a great solution for free, it would take an engineer's time to get it up and running, and that costs money.

* features and functionality. These could be what you might think of as features (does it support passwordless, what languages have client libraries, what standards like SAML, WS-Fed, OIDC, LDAP are supported) as well as non functional requirements like tenancy, performance and data center locality (sometimes governments have requirements about where user data can live).

I've built a number of software applications and I can tell you that I wish I'd started out with a separate identity provider more often. It makes it easier to create a single sign on experience, add more applications, and enable new functionality. Add that to the fact that identity is a necessary but not sufficient requirement that doesn't often differentiate or add much value to your application. If you're building a todo app, people expect to be able to login but will rarely rave about how smooth the login experience is :) . If you find a solution that works, you can often drop it in and accelerate delivery of the real value of your application, while giving you flexibility for the future.

Finally, here's a video from RailsConf about the dangers of rolling your own user identity management: https://railsconf.com/2020/video/seyed-m-nasehi-why-you-shou... . I don't know the speaker, but certainly some of the issues his hedgehogs (no, really) encountered seemed familiar.

(Full disclosure, FusionAuth is my employer.)

If you want a drop in OAuth/OIDC server that runs anywhere, I'd recommend looking at FusionAuth. You can set it up in 5 minutes and it runs everywhere: https://fusionauth.io/docs/v1/tech/5-minute-setup-guide

Worth noting: it is free as in beer--if you need an open source solution, it's not a fit.

Edit: typo

A drop-in component so your product can do what exactly?

To be an OIDC Relying Party [1]?

To be an OIDC Provider [1]?

To be an OAuth2 client [2]? Keep in mind, being an OAuth2 client is probably not useful by itself -- you'll have to program your app to deal with the resource server's specific APIs to accomplish anything, and request the appropriate scopes for the situation, based on what you're doing.

[1] https://openid.net/specs/openid-connect-core-1_0.html#Termin... [2] https://tools.ietf.org/html/rfc6749#section-1.1

Company i work in spent 2 years to implement OAuth. For that time application was rewritten 3-4 times. 3 developers worked on that in different times. And guess what? It still doesn't work and serves tiny portion of traffic with tons of issues.

I work at WorkOS (we handle Enterprise SSO among other things, https://workos.com). We interface many... should I say "less elegant"... enterprise identity protocols with an OAuth api. There is support for common identity providers such as Azure, AD FS, Okta, VMware, to name a few. If you'd like access to our beta send me an email (max@workos.com) and mention hn.

Were you implementing a client in all of these OAuth integrations?

I thought the point of OAuth was to make it easy to build clients and push the complexity to the authorization servers :) ?

I have implemented OAuth servers and also OAuth clients because our integrations go both ways: some parts of our systems rely on 3rd-party services and other companies rely on us as well. The take away from my comment is that even if the software specification is clear (I gave RFC 6749 as an example) some engineers will disregard the instructions and make something completely unexpected. The majority of developers expect good quality software from big companies with massive engineering teams, but people who have the opportunity —or should I say misfortune?— to work with them realize software engineering quality is often an illusion.

Whatever the intentions may have been, it is definitely not the case that OAuth pushes complexity to authorization servers. My audit checklist for OAuth clients is fairly long.

As someone in the early stages implementing Oauth2 for the first time, I would be interested in seeing that list, if you don't mind sharing.

Agreed, I'd love to read that blog post.

Or Book/booklet, I'd buy that as I'm sure many would.

Indeed, there are some people when it comes to best practices, that I respect more than industry standards as they are usual best practices that will be standard tomorrow.

I think in addition to a spec, an official test suite that's used to certify an implementation as compliant would also greatly help.

This is why Nylas.com exists now.

Reply on news.ycombinator.com