Authlib: Python Authentication | Hacker News Reader

Authlib: Python Authentication

docs.authlib.org

125 pointsrobertlagrant39 comments

Open articleView on HN

Plus:

- This plan is for commercial projects.

- License: Commercial License

- security maillist

- quick responses

- private PyPI

- commercial support

- making Authlib sustainable

then:

- We offer a private PyPI server to release early security fixes and features.

Don't they rely on the entire PyPI community to offer their product? Holding security fixes back in exchange for money doesn't look fair to me from this perspective.

It's for 1-day attacks I'd imagine. Especially for python, once the patch is public threat actors can abuse it but they can embargo the cve and offer private patches for commercial customers early to avoid that scenario.

The most confusing thing about autjlib is this.

> Authlib offers two licenses, one is BSD for open source projects, one is a commercial license for closed source projects.

It's not OSS. You can only use it for open source projects for free, otherwise you have to pay $1000/yr to use it.

Or $2,000 a year if your company wants to pay by invoice.

The project is clearly licensed under the BSD License. See the LICENSE file and the in-file comments below. You can't both license under the standard BSD License and carve out commercial usage.

""" authlib ~~~~~~~

    The ultimate Python library in building OAuth 1.0, OAuth 2.0 and OpenID
    Connect clients and providers. It covers from low level specification
    implementation to high level framework integrations.

    :copyright: (c) 2017 by Hsiaoming Yang.
    :license: BSD, see LICENSE for more details.

"""

It used to be AGPL, but they switched to BSD some time ago (and I think just forgot to change wording on the commercial license offering).

Right, shouldn't it be GPL? BSD can be used in commercial products.

And even if the licensing of this project holds up as the author intends: If I make an Open Source project based on this, and someone else uses that in a commercial product, it would be 100% legal according to the BSD license.

That might be his intention; at least force an intermediary OSS app before commercial use. else-payup.

I could create a fork that differs only in name and maybe changes one or two default settings. See also: Chromium forks that disable telemetry and nothing else.

Exactly. Should be GPL licensed, and commercial projects can always buy commercial licenses.

The commercial license comes with some added functionality, and support. I suspect the "for open source projects" and "for commercial software" labels aren't meant as restrictions (i.e., "Only these kinds of projects can use this license") but rather as suggestions ("If you have this kind of project, you'll probably want to use this license"). Though as it stands, it's definitely ambiguous, which is the last thing anyone wants from their licensing agreement.

How would that work? If it is used by an open source project that is BSD-licensed, and then that one was used in a closed source project, what then?

GPL propagates. Presumably BSD doesn't.

If the closed source project redistributes the BSD project, then it must comply with its license:

    Redistribution and use in source and binary forms [...] are permitted [...] provided that the following conditions are met:

    [...]

        * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 

    [...]

Don't some organizations want a business relationship for one reason or another?

From looking at the plans, the value is mostly in support for the commercial license, which is a pretty common approach. I think the wording is the only part that is odd, although it may be an intention nudge.

Also, based on a blurb from their sponsorship page, it appears they give security patches to commercial license holders before the public. https://github.com/sponsors/lepture

This makes it a non-starter for a lot of teams I think, in large enterprises it can be difficult to keep track of licenses like this, especially if you have situations like open core but commercial tiers and whatnot.

The README on GitHub says:

> If your company is creating a closed source OAuth provider, it is strongly suggested that your company purchasing a commercial license.

And the text in the LICENSE file is a bog-standard BSD license, which doesn't say anything about not being able to use it for commercial purposes.

So it looks like they're relying on companies paying for support, or out of goodwill (or confusion), rather than because of any legal obligation.

Or to avoid legal uncertainty. The bigger the company, the more willing they are to pay $1000 a year to not have to track a potential risk, no matter how small that risk is. And another $1000 for paying by invoice, so the accounting department is happy.

They are relying on holding security fixes hostage.

That is scary..

It may also be a way to make financially supporting a project easier for users in corp environments -- it can be easier to get an expense through for a $1k software license than a $100 donation to an open source project or individual author.

Cool! Here's a full featured tutorial on how to use authlib to add authentication to a python flask app using an OIDC server (in this case, FusionAuth, my employer): https://fusionauth.io/docs/v1/tech/tutorials/integrate-pytho...

Hey! Thanks for sharing. Do you have a similar tutorial for doing the same thing with google/facebook/etc logins?

You mean using authlib to do login with facebook/google? If so, this looks helpful: https://github.com/authlib/loginpass

Do we really need to reimplement and use OAuth anymore? I don't know any service that still uses OAuth last I checked, usually everything is just API keys.

Besides, for any new project I just go for Auth0 these days, that's just me.

Allowing users to register to your app using another service (e.g. Facebook, Spotify, Google) requires OAuth. That’s what I use authlib for, anyways. It simplifies the OAuth process so much that I don’t have to think about the authentication process when designing an app.

Your experience is not necessarily others': IME, OAuth is widely adopted, and OIDC is rapidly gaining traction. GitHub Actions, for example, offers ephemeral identity credentials through OIDC.

OAuth (OIDC) still makes a lot of sense in some scenarios. I work at a university and I just used Authlib a few months ago to consume our single sign-on, and let me tell you, that was much easier than using the API would have been.

Isn't Auth0 a commercial product? That might not be an option for everyone.

Having multiple options on the market is healthy.

The alternative is called monopoly and it's not good for consumers.

> I don't know any service that still uses OAuth last I checked

But

> Besides, for any new project I just go for Auth0 these days, that's just me.

Auth0's primary mode is OAuth2.

The level of ignorance many developers have these days about foundational technologies that power SaaS platforms is truly astounding.

Hopefully there are still people around to build SaaS when the current vanguard retires.

> I just go for Auth0 these days

That's a service that manages OAuth2 for you, for $ at scale

I was just at a developer conference and was amazed at how many people used Auth0 and OAuth interchangeably. They've done a super job of capturing mindshare, and have a great brand.

More likely those people were somewhat junior. It makes no sense to interchange a vendor with a technology unless the name is literally the same.

Isilon for instance was a brand where there main product was... Isilon clusters.

Possible. I didn't dig into their understanding, but this past week wasn't the first time it has happened.

Never even heard of Auth0, lol

The world's a big place!

Full disclosure, I work for an auth server vendor.

So there are three primary use cases for OAuth (I'll include OIDC as well, as they are often paired and OIDC is built on top of OAuth).

* Authentication. Using OIDC for authentication lets you use one of many authentication servers (FusionAuth [my employer], Keycloak, Python OAuthlib, Django with https://django-oidc-provider.readthedocs.io/en/latest/ Auth0, Cognito, etc etc). Using such an identity server lets you have one single place to store user data. It's normalizing user data, which has the same benefits and tradeoffs as normalizing any other kind of data.

* First party API authentication (where the same org controls both the end client and the API server). This is comparable to API keys, but has some differences. Setup is more complicated, but you have credentials that are automatically time bound (tokens expire), support multiple useful flows, and have a refresh mechanism built in. Plenty of security experts have banged on OIDC/OAuth and helped fix issues, and j random developer you just hired is probably more familiar with OAuth than your custom API key scheme. You also have the ability to put more data in the token (if you use JWTs) and have the tokens verified without contacting a central server. This can lead to some nice scaling properties.

* Third party API access. When you are the client and want access to third party APIs, you have to use what the API dictates. That is often either OAuth or API keys. OAuth here has a lot of flavors. See this article which was on HN a month or two ago: https://www.nango.dev/blog/why-is-oauth-still-hard

Source: I work for FusionAuth, an auth provider which supports OAuth and OIDC, and help support users and customers implementing FusionAuth.

Can you use Auth0 in your own , Airgapped intranet? Can you use Auth0 without exposing your user information to Auth0 providers? Can you modify source code of Auth0 for your customizaiton needs?

The answers are No. So i will never need it.

Reply on news.ycombinator.com