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

OIDCAuthenticator - makes sense? #254

Open
consideRatio opened this issue Mar 8, 2019 · 14 comments
Open

OIDCAuthenticator - makes sense? #254

consideRatio opened this issue Mar 8, 2019 · 14 comments

Comments

@consideRatio
Copy link
Member

Hey, I figure it would make sense to create a Authenticator that can handle a OpenID Connect endpoints like ".well-known/openid-configuration" providing configuration information, like here:
image

@minrk does it make sense to you? This is something I'd be happy to invest time in, one way or another. I have spent sooooo much time working with auth lately and this is one of the challenging things to setup in general I think, but OIDC implemented OK can make life a bit easier.

@betatim
Copy link
Member

betatim commented Mar 8, 2019

It could be interesting to extend https://github.com/jupyterhub/oauthenticator/blob/master/oauthenticator/generic.py so that it can be configured with just the "well known" URL and get all other links from there.

The generic OAuthenthicator works very well with Auth0 and friends. As far as I can tell OIDC is mostly just the complicated name used in companies for OAuth2.

@consideRatio
Copy link
Member Author

consideRatio commented Mar 8, 2019

I think OIDC is a standard built on top of OAuth2 standardized things, it adds details about how a userinfo endpoint should work for example I believe, and how you should also have this configuration endpoint, often accessible at https://example.com/.../.well-known/openid-configuration. And this endpoint should adhere to various rules etc.

But yes, having an OIDC provider allows an OAuth2 client to authenticate still, but there are parts that is not implemented in OAuth2 libraries to authenticate with OAuth2 providers. I'd like to see us have a "this is a proper generic OIDC Authenticator". I'm open to the idea of making the generic OAuthenticator to become that OIDC compliant authenticator, but I'm currently hesitant as I know too little about the implications.

If I develop this at some point, I probably want to copy some code from the generic oauthenticator, but not require myself to be backward compatible to support non-oidc authentication, whatever this now means. I'm still not confident enough about these topics.

@manics
Copy link
Member

manics commented Mar 8, 2019

@consideRatio You're correct, OIDC is basically OAuth2 with a few extras, though it's surprising how badly documented that is (took me over a week to realise!). I've just written a very experimental OAuth2/OIDC app for one of our apps, so if it's helpful I can point you to the differences between OAuth2 and OIDC, and hopefully save you some of the pain I went through 😀.

@consideRatio
Copy link
Member Author

;D haha yes @manics that is what I experienced as well, but I must say I have spent a lot more than a week by now and still is vague about things ^^

@consideRatio
Copy link
Member Author

consideRatio commented Mar 8, 2019

Related issue, there are potential to reuse the python module tornado.auth for more things than we have done so far I think: #245

@Zsailer
Copy link
Member

Zsailer commented Mar 19, 2019

@consideRatio and @manics For reference, I've found this online book by the Okta team extremely helpful for understanding the relationship between OAuth2 and OIDC.

@minrk minrk transferred this issue from jupyterhub/jupyterhub Mar 25, 2019
@minrk
Copy link
Member

minrk commented Mar 25, 2019

Yeah, I think this makes sense to add here.

@enolfc
Copy link

enolfc commented Oct 18, 2019

was there any progress on this? I'm also interested in an OIDC authenticator.

@manics
Copy link
Member

manics commented Oct 13, 2020

Does anyone still want to work on this? Or should we close this issue, and either re-open when there's a concrete plan or add it in another repo?

@consideRatio
Copy link
Member Author

Agree!

@jmuchovej
Copy link

jmuchovej commented Oct 1, 2022

Just came across this, I don't think there are any open issues relating to this. I'd be interested in seeing this done (and think I can take a crack at it).

Though I'm not super familiar with the actual mechanics of OIDC. Right now I have an instance of Authentik running, which provides OpenID/OAuth2 endpoints (like the .../.well-known/openid-configuration), but I managed to get things working manually filling out details in the generic.GenericOAuthenticator.

My current conception of how this would work is that the OpenIDAuthenticator would extend the GenericOAuthenticator but uses the well_known_url (or similar) to fill-in the gaps – so using the well_known_url as authoritative source for:

  • authorize_url
  • token_url
  • userdata_url
  • logout_url

(There are other things like scopes and claims that could be checked/retrieved, but I figure that a proof-of-concept OpenIDAuthenticator wouldn't need to parse that (yet).)

Are there things that I'm missing/overlooking? (Or otherwise, general thoughts/direction?)

@minrk
Copy link
Member

minrk commented Oct 3, 2022

@jmuchovej I think that's exactly right - OIDC should be able to populate the other config after an initial well-known request, then behave the same, otherwise.

@skapin
Copy link

skapin commented Sep 22, 2023

Authentik

@jmuchovej could you provide your settings for jupyterhub ? Where you configure GenericOAUth,.

I'm using AUthentik, and i'm really interrested

thanks

@minrk
Copy link
Member

minrk commented Dec 7, 2023

I think OIDCAuthenticator makes sense in this repo and seems to be generally accepted as something we should have, so we should keep this open until it's implemented, either in this repo or another.

@minrk minrk reopened this Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants