My favorite identity provider of all time is https://auth0.com

I was very impressed by their rules concept [1] that allowed me to create quite non-trivial authentication scheme in one day from scratch [2] They also pay attention to development workflows by having great logs and debugging tool chain as a part of their service, very cool!

[1] https://auth0.com/docs/rules [2] https://gravitational.com/blog/aws-github-sso/

Auth0 do the same thing though. They make library abstractions such as "passwordless" and make it a separate authentication flow altogether, where as in reality it is just a matter of generating temporary passwords. There is no need to not be able to just enable and disable temporary passwords for any user.

Also, try implementing generation of API-key like tokens for users that can be expired, revoked, authorized etc.

Auth0 have made products that hide complexity, in my opinion, but if those products fit your particular need, sure it works great.

Sounds like there is room in this market for competition

We don't have any official Okta Python library support at the moment :(

We don't have any full-time Pythonistas on staff right now, so deprecated our old stuff. We're hoping to hire and expand that role out to build proper SDKs + support in the future.

Right now, the best option is to use generic OIDC/OAuth compliant libraries (since Okta is a generic OAuth/OIDC provider). Sorry :(

The company I work for recently became an Okta Partner... and I'm a Software Engineer that primarily works in Python.

I am expecting this quarter to start building out a platform that will use Okta for authentication and authorization.

Do you think Okta would be willing to pay for some engineering hours if we were to take on the mantle of producing a modern Python SDK? If so, I'll be happy to start running that up the line here.

Failing that, are there any resources you recommend for going forward with Python and Okta, in addition to using generic OAuth libraries?

That is awesome! I'm going to forward this comment to our DevEx team and see if that's something we could do. Sounds great to me =D

Excellent -- I sent you an email to the address in your profile from my work email in case anything comes of it.

I don't particularly need a Python SDK. What I need is extremely clear documentation on how to roll my own authentication code against Okta - the equivalent of https://developer.github.com/apps/building-oauth-apps/author...

We use Okta internally where I work and it's been fairly smooth as far as the end user experience. I'm sure it hasn't been perfect but it's always a pleasure having one sign on for everything

My team did use Okta React briefly for an internal project but we couldn't get it to play nicely with Cypress (e2e testing) so we ended up removing it sadly.

I'm pretty sure we had just implemented it incorrectly though since we were still getting to grips with React at the time (as a team that previously had little to no combined UI experience) :)

Interesting, someone I worked with at a previous job left there to go to Okta. He did our Django/python Auth stuff. His Linkedin says he's still at Okta.

Pretty much the same situation here, we just disabled 2fa today on our aws integration because the web-only flow made it impossible to use cli tools.

You don't have to use a web-only flow for MFA. We use a tool that prompts for MFA the execs any CLI with the environment setup with the STS credentials e.g. https://gist.github.com/rectalogic/e99c10bd43a2a8f6542680953...

FWIW, if all you're doing is authenticating a web application, you really can just do it off of the OIDC spec. It's a small subset of the protocol and can be easily understood. I did it recently, writing a multi-tenant application where each tenant can have its own OIDC providers, and it took me about three hours to do and to do correctly (verified against Auth0 and Okta, at least).

Barring that, Okta at least is a conformant OIDC implementation and you can use standard libraries for it.

I'm surprised no one has mentioned FusionAuth (https://fusionauth.io). It's free, has a Python library, and the features that most apps need. There are a couple of people using Python with FusionAuth right now.

The community for FusionAuth is growing quickly and it has an open issue tracker (https://github.com/FusionAuth/fusionauth-issues), good docs (https://fusionauth.io/docs/v1/tech/), and many open source projects as well (https://github.com/FusionAuth).

I'm one of the developers of FusionAuth, so you should give it a try and lot us know what you think.

I like what I see provided out of the box by FusionAuth, but I'm rather weary of the hard dependency on Elasticsearch.

I'm curious why the need for Elastic. You already have a database which can be used to search all the user objects. What does Elastic bring to the party other then an extra ops burden?

This is not necessarily a criticism, just trying to understand what went into that architectural decision.

Elastic provides a much more scalable and fast search for freeform user attributes. Using the databases search works in some cases but when you have freeform data (for example favoriteColor), it breaks down quickly.

While Elastic can be a bit cumbersome, we have made bundles that make it simpler to deploy and manage. We have also worked hard to secure it.

Running FusionAuth in Docker or Kubernetes is a huge benefit to those running on premise.

We just use google oauth which kicks you to okta. This lets us use the x/oauth/google packages from google itself.

The say they have a REST API. Could you use that directly from Python instead of using an SDK?

I've seen a similar situation with payment processors, where they have SDKs in a variety of languages, but not the one I'm using (our back end is in Perl), so I use the underlying low level API.

Amusingly, it often happens that I look at their Java or PHP SDKs, which involve seemingly a bewildering number of classes and methods, and find that just using their underlying REST API directly is massively simpler, clearer, and takes less code, to the point I don't use their SDKs even if I am working in a language they have an SDK for.

But payment processing is pretty simple. Third party authentication is probably more complicated, and so it could be that the SDKs are doing a lot more than just providing a fairly straightforward wrapper for the underlying low level API.

We also ran into issues with using the Okta OAuth/OIDC integration with Teleport and ended up using SAML [0]. Perhaps more painful, especially if you are more familiar OAuth/OIDC but it worked. This was when Okta OAuth/OIDC was still in beta so perhaps it has improved since then.

[0] https://developer.okta.com/authentication-guide/saml-login/ ; https://gravitational.com/teleport/docs/ssh_okta/

Okta's position in this article is missing the bootstrapping problem.

Yes, you don't want people rolling their own crypto libraries. But if nothing has been rolled yet for your environment by anyone? You need a standardized open protocol that you have at least a chance of rolling correct crypto against.

Closing that protocol up in a nice shiny (but exclusively-owned-and-maintained) box does you no good if the box can't be bent to fit your use case.

I'm using Flask-Dance, it works rather nicely.

Thanks, that looks pretty good: https://flask-dance.readthedocs.io/en/latest/providers.html#...