Add login with SSO button to the Home Assistant login UI

[voc0der]

So, I got this working! Yay.

It took me a second to realize how you intended for the /auth/oidc/welcome vs /auth/oidc/redirect work. I wanted a more seamless experience like you mentioned, so I put a redirect on / in my location / {} block, like if (exact_path...= '/'), and that worked to get me to /auth/oidc/redirect but after filling out the form to login, it seems to send me in a loop and seems to go back to the same path on POST. But then I realized why automating that wouldn't be ideal, so anyways... it makes more sense to make a button on the root of the login screen to go to the redirect path/welcome path, and have those appear optionally as config.yaml vars.

I think what you did makes sense since you want to open authentication beyond web users (mobile.) But what is confusing to me is that there is no link to the oidc login auth screen at the root login screen. You just get that vague box, (at the very least, it could say its a quick code box as a input text hint) so unless you read the documentation, you aren't going to know how to login.

Anyways, if anyone wants to copy my homework:

auth_oidc:
  client_id: "xxxxxxxxxxxxxxxxx"
  discovery_url: "https://auth.netspace.in/.well-known/openid-configuration"
  client_secret: "xxxxxxxxxxxxxxxxx"
  display_name: "Log in with Authelia"
  id_token_signing_alg: RS256
  features:
    automatic_user_linking: true
    automatic_person_creation: true
  claims:
    display_name: name
    username: preferred_username
    groups: groups


- client_id: 'xxxxxxxxxxxxxxxxx'
  client_name: Home Assistant
  client_secret: 'xxxxxxxxxxxxxxxxx'
  public: false
  authorization_policy: two_factor
  require_pkce: true
  pkce_challenge_method: 'S256'
  consent_mode: implicit
  pre_configured_consent_duration: 1M
  token_endpoint_auth_method: client_secret_post
  redirect_uris:
    - https://homeassistant.xxxxxxxxxxxxxxxxx.com/auth/oidc/callback
  scopes:
    - groups
    - openid
    - profile
  grant_types:
    - authorization_code
  userinfo_signed_response_alg: 'none'

If anyone is using authelia and wants to copy my homework. I know there's already an example but I was surprised to see PCKE not there

And before I forget, thank you for this amazing project.

[manuschillerdev]

i struggled understanding that as well.
Right now I configured the application in Authentik to point to https://home-assistant.***.online/auth/oidc/redirect

Which works fine - but it is not intuitive for users what to do when they see the login screen:

It would be awesome, if we could just have a button there "Sign in using OIDC" that redirects to the configured oidc provider, as it is common in other apps (argocd, grafana, and so on).

But I have no idea, if that is even possible by providing an extension like this, or if it would need to be implemented in core.

Thanks for the awesome work with this integration, using it daily now!

EDIT:
I missed the reference to the open PR at home-assistant/frontend#23204 in the Readme, sorry.
It is approved so this might get released soon :)

[benedikt-bartscher]

To be honest I would probably not put too much work into this, as the upstream PR which allows redirecting to an auth Provider was approved by one of the maintainers today. Hopefully it will be merged soon. This should pave the way to a proper oidc login flow, at least for Desktop. Not Sure about mobile. Please correct me if i am wrong.

Edit: just seen your Edit, seems like you figured out the same :D

[christiaangoossens]

I think you all figured it out mostly, but here's the quick notes:

• I cannot change the login screen as all of this is hard coded in the frontend code. So, I am stuck with the title of "Just checking" and without any description or even a title for the input box. Changing this would require a PR on the Home Assistant frontend repository.

  • If anyone can refactor their code to allow integrations (Auth Providers) to send custom translations to the frontend when sending the form (here: custom_components/auth_oidc/provider.py, line 302), such that I can send custom translation keys for the title (instead of just using the mfa version), description and input label, I would be very happy to accept a PR here as well that accomplishes that.
  • Bonus points if it uses the same translation system you would use for any normal setup/config flow in the UI.
  • Extra bonus points if we can add a button or link besides it that allows for opening the start of the OIDC flow there too, within the description for instance.

• I cannot redirect you to the start of the OIDC process yet, both on mobile and on desktop. Whenever the PR gets merged and a Home Assistant version that's includes the PR is released (or planned), I will hopefully be able to get something like that to work on desktop.

  • It likely will not work on mobile, as the PR that's now approved only does it for desktop, I tested mobile with that code 2 years ago and it didn't work. I will contact someone on the Android team to see if we can make that happen too at some point.
    • If you want details why, I'm happy to write you a post on that.
  • I have not created a development version yet, as I wanted to fully stay away from frontend work to keep my sanity after the mess it was 2 years ago when I first tried this. But, with motivation and that PR merged, I will return to it in the near future.

Other notes (for @voc0der):

• I see you included a tutorial for Authelia with PKCE, I will remove that from here and add it to the wiki soon, when I pick up the info from docs: add Authelia configuration instructions #14 as well.
• Configuring a redirect to disable / is not recommended as it makes it hard to access the code input on mobile, as you need to use a different browser/device to obtain the code there and then input it on the normal code input screen.

Hopefully that clarifies everything for now and we can have a release that makes the login experience much better soon!

[christiaangoossens]

Instructions on how you can help improve the UI are also added here now: https://github.com/christiaangoossens/hass-oidc-auth/blob/main/CONTRIBUTING.md#better-user-experience

[jtdroste]

@christiaangoossens this is going to sound silly, what are your thoughts on just injecting some JS into the authentication page? Given the frontend ships as a python package (hass_frontend), we can technically inject custom JS into the base auth page (authorize.html), that could:

1. Update the MFA text
2. Maybe add a jank button to the OIDC login page?

I'm not sure the appetite to add that to this project ("[..] preferably hack as little as possible."), given it will need to edit "live" files, but it's an option depending on how long the mobile PR sits in limbo / might not solve all issues anyway. If you're down, I'd be willing to take a stab at it - could even be a feature you enable?

[voc0der]

It wouldn't be the only project that does this. There are projects use it as well that are in this same situation (e.g. Jellyfin-sso).

If you're deploying this over docker, then injecting files as volume members, or even after the container starts is not very difficult to automate. https://github.com/tedhinklater/Jellyfin-Featured-Content-Bar/pull/47/files

Depending on how often authorize.html is modified upstream, it could be something that is served as a volume, or replaced on the fly to add it dynamically, either way is trivial to implement (not sure about the other parts just the docker implementation bits).

Obviously this isn't the ideal way but HASS is a big project and it may take years to circle around back to this. Theres at least a half dozen projects I've been subbed more than 1 year on OIDC pull requests for.