OIDCAuthenticator - makes sense?

[consideRatio]

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:

@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]

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]

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]

@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]

;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]

Related issue, there are potential to reuse the python module tornado.auth for more things than we have done so far I think: https://github.com/jupyterhub/oauthenticator/issues/245

[Zsailer]

@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]

Yeah, I think this makes sense to add here.

[enolfc]

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

[manics]

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]

Agree!

[jmuchovej]

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]

@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]

Authentik

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

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

thanks

[minrk]

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.