OAuth + Azure AD - 403 on login?

JupyterHub
1

Formerly, I had a config.yaml for the jupyterhub setup, and it was working fine pre-2.0.0. It used Azure AD Oauth for user authentication, which linked in through my university’s service. As below.

hub:
  config:
    AzureAdOAuthenticator:
      client_id: your-client-id
      client_secret: your-client-secret
      oauth_callback_url: https://your-jupyterhub-domain/hub/oauth_callback
      tenant_id: your-tenant-id
    JupyterHub:
      authenticator_class: azuread

After some updating of both the helm chart and my AD OAuth (because it expired), this does run through authentication, but then redirects back to a 403 access forbidden. I’ve reverted to firstuseauthenticator.FirstUseAuthenticator, which is actually an ok solution for my use-case, but I’d prefer if Azure AD was reactivated, for long-term user tracking.

Any idea what to poke into to find out why the access is being forbidden once the login completes successfully?

2

Hi,

can you try the following:

hub:
  config:
    AzureAdOAuthenticator:
      client_id: your-client-id
      client_secret: your-client-secret
      oauth_callback_url: https://your-jupyterhub-domain/hub/oauth_callback
      tenant_id: your-tenant-id
      enable_auth_state: true
      username_claim: unique_name
    JupyterHub:
      authenticator_class: azuread
3

Thanks for the suggestion. Unfortunately, same result, at least in my minimal testing. It’s possible there’s a unique_name mismatch (or actual match … ) between the different auth methods, so that a login via Azure AD actually is trying to access resources already allocated for the same user, but under the second login? That’s all I’ve got as an idea at this point. The 403 doesn’t seem to be tied to any errors I’m finding in the logs.

4

Do you have a list of allowed_users? Version 16+ of Oauthenticator improves the security of the default configuration by not allowing all users, but this is a breaking change which can be overridden:

5

So I just had this happen to myself again. It’s happening when I update my hub helm version. And the issue is the jupyterhub.sqlite files - after update, the database reference hash can’t be found? and then users who had recently logged in can’t, because permissions fail.

Solution: go to the pvc for the hub pod, and delete all the jupyterhub.sqlite files. Re-run the helm install. And everything proceeds as hoped.

Putting a note here because I did not figure this out last September, did somehow figure this out in February, and then went and forgot the step this September. Danger of doing this kind of administration once or twice a year: no memory! Now if I or anyone else googles this, maybe they’ll see this suggestion.