Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sdk: add python sdk #639

Closed
duaneking opened this issue Oct 31, 2017 · 13 comments
Closed

sdk: add python sdk #639

duaneking opened this issue Oct 31, 2017 · 13 comments
Labels
feat New feature or request.
Milestone

Comments

@duaneking
Copy link

duaneking commented Oct 31, 2017

Issue explained in the title.

Unless we can use this in Python 2.7 via Django, and flask. it's not happening as the ability to spin up a fast flask app or API in python and let it authenticate to this server is a key requirement. We can't be limited to only node and golang apps.

@aeneasr
Copy link
Member

aeneasr commented Oct 31, 2017

Thank you for raising this issue. It is most certainly not a defect, but rather a feature request to the existing project.

It should be possible to spin up a python SDK using swagger-codegen as is done for node and go here. However, there will be some additions neccessary, such as requesting an access token using an established library (a quick google search revealed https://github.com/joestump/python-oauth2).

Would you be willing to work on this? I have little python/flask/django experience.

@aeneasr aeneasr added the feat New feature or request. label Oct 31, 2017
@aeneasr aeneasr changed the title No Python SDK Exists. sdk: add python sdk Oct 31, 2017
@duaneking
Copy link
Author

duaneking commented Oct 31, 2017

I used the word "defect" in the general "thing I'm posting about" usage. Word changed to "issue".

As for your question on if I would do this: I'm in an odd situation. I'm currently looking for an oauth2/OIDC solution that fits our needs that we can leverage and is not powered by anything that requires Auth0 in any way (As Auth0 is far too expensive with our number of users); So the solution we find that fits our requirements is going to be the one we will commit to, and as a result will get all of the dev cycles of the team in terms of support and whatever fixes we need to contribute to it in order for the project to continue meet our needs. I have been told by our CTO that this includes upstream patches etc; I just have not found such a solution yet and this lack of python support is one of the things that make this project not a fit for us. I'm not able to commit myself or the team to any work for a project that doesn't already fit our needs in a basic way.

@aeneasr
Copy link
Member

aeneasr commented Oct 31, 2017

I'm currently looking for an oauth2/OIDC solution that fits our needs that we can leverage and is not powered by anything that requires Auth0 in any way (As Auth0 is far too expensive with our number of users);

You are aware that hydra does not solve IDP (login, logout, pw reset, user registration), right?

I have been told by our CTO that this includes upstream patches etc; I just have not found such a solution yet and this lack of python support is one of the things that make this project not a fit for us.

All endpoints of Hydra are REST so python support is definitely there if you know how to make REST calls. Using swagger-codegen is, by the way, probably a task of a couple of minutes (it autogenerates a REST client). You have to figure out how to use an oauth2 client anyways if you want to use oauth2 with python, so it's actually no additional work.

I'm not able to commit myself or the team to any work for a project that doesn't already fit our needs in a basic way.

I know the space very well, there are no OS projects that have full IDP, OAuth2, and OIDC capabilities and are scalable/cloud native (that I know of). Hydra is the only OAuth2/OIDC provider capable of plugging in to any IDP that doesn't have scaling issues and that works in container environments, but it also doesn't solve IDP itself. (if you do happen to know one, please share them here!)

@duaneking
Copy link
Author

Thank you for that response!

I have been trying to get people to understand all of this themselves.. but you said exactly what I have been saying for a week now means its not just me saying it!

@aeneasr
Copy link
Member

aeneasr commented Oct 31, 2017

Absolutely no problem. The open source space of identity management is very difficult, primarily because identity management itself is simply not easy. For Hydra, I suggest looking at AWS Cognito for IDP and Hydra for OAuth2/OIDC. AWS Cognito is less expensive than Auth0, but does get expensive when lots of users are in play.

@duaneking
Copy link
Author

duaneking commented Oct 31, 2017

Fully understand, and if my wording seemed odd my apologies but I'm working with expectations from others that seem.. unrealistic.. to me at this point. Its good to have you say so if only because of the sweet validation it gives me on what I have done so far.

We have enough users that paying per month for them is out of the question, so sadly Cognito isn't a possibility. We can - and I suspect, will - have our own registration and management system to deal with IDP, but my big issue atm is making sure that external services can actually use our OAuth2/identity server and integrate with systems using a JWT that doesn't have to make a call back to a central single point of failure to validate the token, and can do so using Python, Golang, etc and not Java/PHP or their ilk.

@aeneasr
Copy link
Member

aeneasr commented Oct 31, 2017

Fully understand, and if my wording seemed odd my apologies but I'm working with expectations from others that seem.. unrealistic.. to me at this point.

Don't worry, we've all been there.

We have enough users that paying per month for them is out of the question, so sadly Cognito isn't a possibility.

That's what I thought, typically that's the case when Auth0 isn't an option as well.

We can - and I suspect, will - have our own registration and management system to deal with IDP

This is something I can endorse. While IDPs typically have some common things (like storing a username and a password), they are also quite different as in what kind of profile data you store, how you want 2FA to work, if you want to support passwordless auth, and so on.

that external services can actually use our OAuth2/identty server

That is the definition of OAuth2 - libraries for any language exist (and Hydra is fully OIDC/OAuth2 compliant) so anyone is able to consume your OAuth2 APIs.

JWT that doesn't have to make a call back to a central single point of failure to validate the token, and can do so using Python, Golang, etc and not Java/PHP or their ilk.

JWTs are bad practice, because they are not opaque to the client and because JWTs have been subject to multiple vulnerabilities in the past. This is why Hydra does not issue JWT access/refresh tokens and why you almost never see JWT access/refresh tokens in the wild. We are however booting up a commercial product called ORY Gatekeeper ( https://www.ory.am/products/api-security ). Gatekeeper is basically an OAuth2 provider (ORY Hydra w/ GroupCache support), API firewall (ORY Oathkeeper - later to be released as core OSS), and a management UI (ORY Security Console) for both. Oathkeeper transforms opaque access tokens to JWTs for internal service consumption. If you want to get around developing that stuff for yourself it might be an option.

@duaneking
Copy link
Author

Everybody seems to want to sell an auth solution, yet people who want one don't want to buy it.

Do you have anything I can toss up the ladder on the JWT stuff being an antipattern? I appreciate that we are off topic at this point but I'm interested in understanding why JWT's are an issue when tokens themselves expire and should not have data in them that should be considered "insecure" to lose anyway.

@aeneasr
Copy link
Member

aeneasr commented Oct 31, 2017

Everybody seems to want to sell an auth solution, yet people who want one don't want to buy it.

Somebody's gotta get paid to build that "free" stuff.

Do you have anything I can toss up the ladder on the JWT stuff being an antipattern? I appreciate that we are off topic at this point but I'm interested in understanding why JWT's are an issue when tokens themselves expire and should not have data in them that should be considered "insecure" to lose anyway.

The spec itself: https://tools.ietf.org/html/rfc6749#section-1.4 and https://tools.ietf.org/html/rfc6749#section-1.5

JWT (those aren't endorsements, just top 5 google search results):

Also, obviously, you can't revoke JWT access tokens and have to wait up to 60 minutes (or however long your expiration is) in worst case scenario.

@duaneking
Copy link
Author

Thanks!

@hiway
Copy link

hiway commented Nov 27, 2017

Interesting discussion so far.

Just found out this project exists; still reading up but already like how hydra tackles integrating oAuth with existing systems. I'm keen on Python3 integration for 'Sanic' for a personal project, will give it a try this week.

@aeneasr
Copy link
Member

aeneasr commented Nov 28, 2017

Cool, feel free to create a PR

@aeneasr aeneasr added this to the unplanned milestone Jan 15, 2018
@aeneasr
Copy link
Member

aeneasr commented Feb 9, 2018

Closing this, doesn't mean I'm against a python SDK - just want to clean out some issues. Would happily accept a PR. If you need further info or help feel free to open a new issue or comment here

@aeneasr aeneasr closed this as completed Feb 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

No branches or pull requests

3 participants