Authlib: Python Authentication

https://docs.authlib.org/en/latest/index.html

by robertlagrant • 3 years ago

125 39 3 years ago

docs.authlib.org

v3ss0n3• 3 years ago

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.

judge2020• 3 years ago

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.

roseway4• 3 years ago

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.

"""

zyx3212• 3 years ago

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.

w0m• 3 years ago

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

malkarouri2• 3 years ago

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

OkayPhysicist• 3 years ago

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.

malkarouri2• 3 years ago

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.

progval• 3 years ago

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. 

    [...]

beardog• 3 years ago

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

kkirsche• 3 years ago

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.

teraflop• 3 years ago

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.

wongarsu• 3 years ago

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.

c4mpute• 3 years ago

They are relying on holding security fixes hostage.

0x0000000• 3 years ago

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.

colesantiago• 3 years ago

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.

sason• 3 years ago

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.

woodruffw• 3 years ago

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.

shreve• 3 years ago

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.

mrweasel• 3 years ago

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

rmbyrro• 3 years ago

Having multiple options on the market is healthy.

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

robertlagrant• 3 years ago

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.

linuxdude3142• 3 years ago

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.

super_trooper• 3 years ago

I just go for Auth0 these days

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

mooreds6• 3 years ago

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.

mooreds6• 3 years ago

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.

v3ss0n3• 3 years ago

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.

mooreds6• 3 years ago

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

jerpint• 3 years ago

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

mooreds6• 3 years ago

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

qwertox• 3 years ago

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.

badrabbit• 3 years ago

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.

Authlib: Python Authentication

Related Stories