[HN Gopher] Authlib: Python Authentication
___________________________________________________________________
Authlib: Python Authentication
Author : robertlagrant
Score : 104 points
Date : 2023-06-26 14:21 UTC (8 hours ago)
(HTM) web link (docs.authlib.org)
(TXT) w3m dump (docs.authlib.org)
| qwertox wrote:
| 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 wrote:
| 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.
| mooreds wrote:
| 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 wrote:
| Hey! Thanks for sharing. Do you have a similar tutorial for
| doing the same thing with google/facebook/etc logins?
| mooreds wrote:
| You mean using authlib to do login with facebook/google? If
| so, this looks helpful: https://github.com/authlib/loginpass
| v3ss0n wrote:
| 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.
| teraflop wrote:
| 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 wrote:
| 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 wrote:
| They are relying on holding security fixes hostage.
| beardog wrote:
| 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
| judge2020 wrote:
| 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 wrote:
| 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.
|
| """
| notpushkin wrote:
| 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).
| zyx321 wrote:
| 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.
| OkayPhysicist wrote:
| 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.
| w0m wrote:
| That might be his intention; at least force an intermediary
| OSS app before commercial use. else-payup.
| zyx321 wrote:
| 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.
| malkarouri wrote:
| Exactly. Should be GPL licensed, and commercial projects can
| always buy commercial licenses.
| kkirsche wrote:
| 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.
| malkarouri wrote:
| 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.
| [deleted]
| progval wrote:
| 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. [...]
| colesantiago wrote:
| 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.
| rmbyrro wrote:
| Having multiple options on the market is healthy.
|
| The alternative is called monopoly and it's not good for
| consumers.
| robertlagrant wrote:
| > 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.
| linuxdude314 wrote:
| 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.
| sason wrote:
| 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 wrote:
| 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.
| super_trooper wrote:
| > I just go for Auth0 these days
|
| That's a service that manages OAuth2 for you, for $ at scale
| mooreds wrote:
| 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.
| linuxdude314 wrote:
| 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.
| mooreds wrote:
| Possible. I didn't dig into their understanding, but this
| past week wasn't the first time it has happened.
| quasarj wrote:
| Never even heard of Auth0, lol
| mooreds wrote:
| The world's a big place!
| mrweasel wrote:
| Isn't Auth0 a commercial product? That might not be an option
| for everyone.
| [deleted]
| mooreds wrote:
| 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.
| shreve wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-26 23:01 UTC)