mobile app to support authelia / other authentication layers

[repomanz]

Is your feature request related to a problem? Please describe. My homeassistant server is external and behind reverse proxy (nginx) and authenticating / protecting URL with Authelia. When I configure home assistant url in mobile application with the has.mydomain.com what happens is that the mobile app opens chrome with the authelia subdomain with a redirect in the url. Example

1. open ha mobile app
2. ha mobile app opens google chrome to login.mydomain.com (with ha url as redirect)
3. enter user credentials
4. authelia then redirects back to ha domain home.mydomain.com
5. mobile app however never sees this authentication. Does not work

Describe the solution you'd like I would like the mobile app to see there is an authentication layer in front of the homeassistant server. So all within the application I would be presented with the authelia login screen and if successful authentication then handed back to the mobile app as an authenticated user. This way I can manage all my ha related activities / sensors, etc within the mobile app.

Describe alternatives you've considered, if any Using google chrome works 100% of the time

Additional context I wanted an additional layer of security in front of home assistant instead of users hitting the home assistant login page directly. If the mobile application uses some additional headers it's possible for me check for this in my reverse proxy setup and bypass authelia for the mobile application.

[dshokouhi]

It looks like this may still be a reverse proxy issue and not an app issue. You are seeing a new site open because the HA app is not receiving the HA authentication call back that we are expecting and instead because its a URL to a different domain the browser loads. This is the same behavior we do in the HA frontend when a user has a link to an external site. I think you need to make sure that your reverse proxy is properly sending data to where it needs to go.

https://github.com/home-assistant/android/blob/52fec8cffd5101b62083470904008690a9e1e2d8/app/src/main/java/io/homeassistant/companion/android/onboarding/authentication/AuthenticationPresenterImpl.kt#L39

[repomanz]

Hello - thanks for responding. Here is what I have in nginx proxy manager under advanced settings. Do you see anything wrong here?

`location /authelia { internal; set $upstream_authelia http://autheliaserver:9091/api/verify; proxy_pass_request_body off; proxy_pass $upstream_authelia;
proxy_set_header Content-Length "";

Timeout if the real server is dead

proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; client_body_buffer_size 128k; proxy_set_header Host $host; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Uri $request_uri; proxy_set_header X-Forwarded-Ssl on; proxy_redirect http:// $scheme://; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_cache_bypass $cookie_session; proxy_no_cache $cookie_session; proxy_buffers 4 32k;

send_timeout 5m; proxy_read_timeout 240; proxy_send_timeout 240; proxy_connect_timeout 240; }

* note this was tailored for docker containers, not hass running on vm / ip. subsituted containername as homeassistant location / { set $upstream_CONTAINERNAME $forward_scheme://$server:$port; proxy_pass $upstream_CONTAINERNAME;

auth_request /authelia; auth_request_set $target_url https://$http_host$request_uri; auth_request_set $user $upstream_http_remote_user; auth_request_set $groups $upstream_http_remote_groups; proxy_set_header Remote-User $user; proxy_set_header Remote-Groups $groups; error_page 401 =302 https://auth.mydomain.com/?rd=$target_url;

client_body_buffer_size 128k;

proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

send_timeout 5m; proxy_read_timeout 360; proxy_send_timeout 360; proxy_connect_timeout 360;

proxy_set_header Host $host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Uri $request_uri; proxy_set_header X-Forwarded-Ssl on; proxy_redirect http:// $scheme://; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_cache_bypass $cookie_session; proxy_no_cache $cookie_session; proxy_buffers 64 256k;

set_real_ip_from 192.168.1.0/16; real_ip_header X-Forwarded-For; real_ip_recursive on;

} `

[dshokouhi]

I don't use a reverse proxy with HA so I am probably not fitted to answer that however if you search in github issues you will see plenty of discussion on that in some closed issues and also in the HA forums. Thats usually where users go to get help with configuration and stuff. You can also try on discord too.

[james-d-elliott]

Regarding the app, is there anything special that distinguishes it from a regular connection? Is the connection directly with an API or similar, or is it just additional headers?

[dshokouhi]

Regarding the app, is there anything special that distinguishes it from a regular connection? Is the connection directly with an API or similar, or is it just additional headers?

a combination of mobile_app integration and also REST API, the app does not support the websockets API currently

the app does use a custom header to help distinguish network calls

for auth and sensors etc.. https://developers.home-assistant.io/docs/api/native-app-integration

for the REST: https://developers.home-assistant.io/docs/api/rest

[philosowaffle]

It looks like this may still be a reverse proxy issue and not an app issue. You are seeing a new site open because the HA app is not receiving the HA authentication call back that we are expecting and instead because its a URL to a different domain the browser loads. This is the same behavior we do in the HA frontend when a user has a link to an external site. I think you need to make sure that your reverse proxy is properly sending data to where it needs to go.

To clarify, are you saying that the mobile web HA will never redirect back to the app after authentication?

Here is my limited understanding of how most mobile apps work when redirecting to browser login pages:

1. App launches and gets 401 unauthenticated
2. App redirects to browser with http://myapp.com/login?isMobile=true (could be a query param, or special header on the request)
3. If a reverse proxy auth is in play, then you end up re-routed to http://login.proxy.com?redirectUri=http://myapp.com/login?isMobile=true
4. Login to proxy, get redirected to http://myapp.com/login?isMobile=true
5. Login to the app
6. The web version of the app now handles the isMobile=true flag (or special mobile header) and redirects to the locally installed app if available.

I'm not positive how y'all have chosen to implement this auth flow. But I think if you could break it down a bit better into what each step is expecting in terms of Uri's, request params, and headers, then we would be better equipped to figure out what needs tweaking in the auth middleware config.

[philosowaffle]

EDIT: This does not work, only appeared to work because the app already had auth cached locally.

For anyone else who lands here, this authelia config might be working (originally posted here):

- domain:
        - ha.mydomain.com
      resources:
        - "^/api.*$"
        - "^/auth/token/.*$"
      policy: bypass

[pmorange]

Hi, As commented on the other Thread, I have found working rules. Please check https://community.home-assistant.io/t/anyone-have-authelia-working-with-ha-to-handle-authentication/321233/18?u=thejuice

[philosowaffle]

@pmorange I tested the updated bypass list and it is still not working. Here is what I observed:

1. Updated my authelia config to be:

   - domain: "ha.<mydomain>.com"
     policy: bypass
     resources:
       - "^/api.*"
       - "^/auth/token.*"
       - "^/.external_auth=."
       - "^/service_worker.js"
       - "^/static/.*"
       - "^/local/community.*"
       - "^/hacsfiles.*"

2. Restarted Authelia
3. Logged out of HA mobile app on my phone
4. Turned off wifi and switched to network data (to simulate remote access)
5. Logged into the HA app.
   1. I was asked to input my HA url: https://ha.<mydomain>.com
   2. I was prompted with Authelia 1st factor login screen (I did not expect this)
   3. After completing Authelia, I was prompted with HA login screen
   4. After completing I was logged into the mobile app and all looked good.
6. I set my phone aside for a few minutes.
7. When I came back and re-launched the HA app, I was kicked over to the web portal login
8. Web portal presented with Authelia 1st factor
9. After completing Authelia 1st factor I was taken to the web version of HA, all looked good here
10. Never redirected back to the app, and each time I try to open the app I am taken back to step 7

Below is the the url that launches in the mobile browser. We can see here that the Redirct URL is GET https://ha.<mydomain>.com. To me this indicates the app makes some call to the root domain, so we won't be able to use filter rules in Authelia, the only way to allow this request through is to bypass the whole domain. What's interesting is I do not see a log entry in my Authelia logs for this redirect, like I normally do when building the resource list above. Its almost as if the app has cached this url and is hitting it directly.

https://login.<mydomain>.com/?rd=https%3A%2F%2Fha.<mydomain>.com%2F&rm=GET

Bypassing the whole domain does allow the mobile app to work. But its obviously not ideal as you loose the extra security across your homeassistant.

And in case its relevant, after putting my Authelia back to bypass all requests to ha.<mydomain>.com I had to completely uninstall and reinstall the app before it would stop trying to do the 7-9 redirect loop.

[pmorange]

@philosowaffle I followed the same steps as you, and experienced the same things (an additional point was an error in HA login after having logged in through Authelia, but a refresh showed me the HA login page correctly afterwards). I was also surprised about the Authelia login screen appearing, but I also noticed an access to ha.domain.com/auth/authorize which we could add to the bypass in Authelia... But keep reading... As you said, some kind of loop kept on redirecting to HA's web page and there was no way of accessing the app anymore.

What I then did then was go the the app settings in Android, remove all data (thus doing more or less a complete uninstall and reinstall as you did), going through the setup of the app again, Authelia login pages... And all started functioning correctly as before. I did all these steps yesterday, closing app and opening again, encountering no problem. This morning I restarted my phone, still no problem. There is something fishy about all of this, but it's currently working fine again.

After reinstalling the app is it working fine on your end ?

[philosowaffle]

Thanks @pmorange glad to hear someone else could repro the issue I was seeing. Went through all of this again tonight and I tentatively have it working now.

1. Updated my authelia again to bypass the magic list of routes for the HA app
2. Kill HA app and removed all local/cached data
3. On Wifi relaunched the app and set the Internal Url to the local server ip address http://192.x.x.x:8123
4. No Authelia login screen presented (as expected)
5. HA login screen shown, login, app works as expected, this all looks good

Now for the remote access test.

1. Go to app settings and set the external url to https://ha.<mydomain>.com
2. Turn off wifi, switch to cellular data
3. Kill and Re-launch the HA app
4. Blank screen displays and eventually the Unable to connect to Home Assistant message displays

Went back and checked my logs, and found a few new URLs popping up as blocked by authelia. So I went back and updated my bypass rules, then tested again. At this point, most things seem to be working, While poking around my app I found a couple other routes that were getting blocked by Authelia. Below is the final route bypass list I came up with:

- domain: "ha.<mydomain>.com" # for mobile app
      policy: bypass
      resources:
        - "^/api.*"
        - "^/auth/token.*"
        - "^/.external_auth=."
        - "^/service_worker.js"
        - "^/static/.*"
        - "^/local/community.*"
        - "^/hacsfiles.*"
        - "^/frontend_latest.*"
        - "^/lovelace.*"
        - "^/local.*"

Will monitor over the next day to make sure it continues to work. But this seems promising.

[FenixVale]

Thanks @pmorange glad to hear someone else could repro the issue I was seeing. Went through all of this again tonight and I tentatively have it working now.

1. Updated my authelia again to bypass the magic list of routes for the HA app
2. Kill HA app and removed all local/cached data
3. On Wifi relaunched the app and set the Internal Url to the local server ip address http://192.x.x.x:8123
4. No Authelia login screen presented (as expected)
5. HA login screen shown, login, app works as expected, this all looks good

Now for the remote access test.

1. Go to app settings and set the external url to https://ha.<mydomain>.com
2. Turn off wifi, switch to cellular data
3. Kill and Re-launch the HA app
4. Blank screen displays and eventually the Unable to connect to Home Assistant message displays

Went back and checked my logs, and found a few new URLs popping up as blocked by authelia. So I went back and updated my bypass rules, then tested again. At this point, most things seem to be working, While poking around my app I found a couple other routes that were getting blocked by Authelia. Below is the final route bypass list I came up with:

- domain: "ha.<mydomain>.com" # for mobile app
      policy: bypass
      resources:
        - "^/api.*"
        - "^/auth/token.*"
        - "^/.external_auth=."
        - "^/service_worker.js"
        - "^/static/.*"
        - "^/local/community.*"
        - "^/hacsfiles.*"
        - "^/frontend_latest.*"
        - "^/lovelace.*"
        - "^/local.*"

Will monitor over the next day to make sure it continues to work. But this seems promising.

Any chance you've been successful with this? I am completely unable to get these working together for either the app, or the web

[then3rd]

I'm having the same issue; I run split dns for an internal network and route to backends with Traefik. The HA android app won't let me sign in; directly. However I came up with a hack that is temporary in nature that demonstrates working around the issue. It's as if we need a way for the companion app to detect when there's a sso redirection and display an embedded page (with shared session storage) for it.

1. Temporarily disabled Authelia
2. Add a "web page" card to HomeAssistant (home.example.com) that links to the Authelia sign-in page (auth.example.com)
3. Sign in to Authelia server via the web card via the android app.
4. Re-enable Authelia for the HA route
5. Re-open the andorid app. observe: The session Authelia session persists until the timeouts are reached.

[dugite-code]

@then3rd I was having a similar issue with my setup (Authentik Forward Auth with nginx proxy and the hass-auth-header add-on) where after the session timeout was reached the android app couldn't re-authorize. The initial login for me works fine It looks like as per @philosowaffle's post the android app posts to /auth/token to refresh it's access token outside the /auth/login_flow path. My issue was I didn't configure my bypass regex (Unauthenticated Paths in authentik) correctly as I was attempting to do this in nginx.

My Unauthenticated Paths config. I limited mine a bit more than the above config and this appears to work so far (I tested this with a 30 second session lifetime for testing).

^/api/.*
^/auth/token
^/.external_auth=.
^/service_worker.js
^/static/.*
^/local/.*
^/hacsfiles/.*
^/frontend_latest/.*

*Edit: Looks like I spoke too soon, I've just lost my week old session and I'm unable to re-authenticate. I added the /auth/token to nginx and it started working, then only to suddenly stop working again. Not sure what the real issue is.

[Thesola10]

@dugite-code Your comment was very insightful, my final solution was to do the opposite: only proxy the /auth/ paths behind OAuth2-proxy, and leave the rest of Home-Assistant as-is.

Here's my Nginx config (excerpt):

location ~* /auth/(?!token)(.*) {
    proxy_pass http://hass/auth/$1;

    # Authenticate all auth endpoints except token
    auth_request /oauth2/auth;
    ...
}

location / {
    proxy_pass http://hass/;
    ...
}

[RobinBeismann]

@Thesola10 seems to work for me to, however when I sign in with the mobile app I only see the lower part of the Authentik logon page, it's cut off below the login form. Any idea how one could fix that?

For reference, here is my homeassistant docker config with Authentik:

     # General settings
      - 'traefik.enable=true'
      - "traefik.docker.network=gateway"

      # Routers
      - 'traefik.http.routers.homeassistantPassthrough.rule=Host(`ha.home`) && !( (PathPrefix(`/auth/`)) && !(PathPrefix(`/auth/token`)) ) && !(PathPrefix(`/outpost.goauthentik.io/`))'
      - 'traefik.http.routers.homeassistantPassthrough.entrypoints=websecure'
      - "traefik.http.routers.homeassistantPassthrough.service=homeassistantService"
      - "traefik.http.routers.homeassistantPassthrough.tls.certresolver=le_production"

      - 'traefik.http.routers.homeassistantPreAuth.rule=Host(`ha.home`) && ( (PathPrefix(`/auth/`)) && !(PathPrefix(`/auth/token`)) )'
      - 'traefik.http.routers.homeassistantPreAuth.entrypoints=websecure'
      - "traefik.http.routers.homeassistantPreAuth.service=homeassistantService"
      - "traefik.http.routers.homeassistantPreAuth.tls.certresolver=le_production"

      # Services
      - "traefik.http.services.homeassistantService.loadBalancer.server.port=8123"

      # Middlewares
      - "traefik.http.routers.homeassistantPassthrough.middlewares=secure-headers@file"
      - "traefik.http.routers.homeassistantPreAuth.middlewares=secure-headers@file,authentik@docker"

[Thesola10]

@RobinBeismann apparently Authentik is broken on Android WebView, which is what the HASS app uses. Fwiw, I use Nextcloud as an OIDC backend (with the oidc app) and it displays fine on Android.

[RobinBeismann]

@RobinBeismann apparently Authentik is broken on Android WebView, which is what the HASS app uses. Fwiw, I use Nextcloud as an OIDC backend (with the oidc app) and it displays fine on Android.

I ended up changing the login prompt alignment to left on authentik, this way it displays fine on Android WebView.

[X-Ryl669]

I think I've solved the issue with Authelia and mobile applications. I've documented the complete setup here so you can reproduce it on your installation as well.

My solution doesn't involve bypassing any URL (that would reduce the security of HA, IMHO if API access isn't authenticated). It simply leave the HASS' login for mobile application intact but only allow SSO for web access.

[dougmaitelli]

I think I've solved the issue with Authelia and mobile applications. I've documented the complete setup here so you can reproduce it on your installation as well.

My solution doesn't involve bypassing any URL (that would reduce the security of HA, IMHO if API access isn't authenticated). It simply leave the HASS' login for mobile application intact but only allow SSO for web access.

So your suggestion is to basically use an alias that does not have Authelia enabled just for the mobile app? I think that is a good solution to make it simple and functional, but wouldn't that have the same consequence as bypassing the API URLs in Authelia? You are basically making the whole domain bypassed by Authalia by not enabling it on that subdomain so if the APIs have any insecure issues they will be vulnerable anyway, right?

[X-Ryl669]

No, it's not the same consequence, IMHO. When you bypass the some URLs via Authelia, you freeze the interface between Authelia and HASS. If HASS decide to add (or modify) any other route in the future, it's very likely you won't notice and will just forget to update Authelia, potentially breaking something (since that new route will trigger a redirect that the automated component will not expect) that's hard to debug.

Also, due to the size of the community of HASS vs Authelia, I think it's more likely a vulnerability to be found in Authelia than in HASS (or at least to have a proper fix quickly). I see Authelia more as a convenience application for SSO, than a security measure (in that particular case, I mean).

Since HASS is using OAuth2 internally, it means that it expect all its URL (but the authentication and static assets) to present a JWT token to prove authorization. When this token expires, HASS redirect to the login page to renew it. Yet, Authelia doesn't know about it and if the Authelia session cookie is still valid, it'll happily bypass the login page without a redirect to Authelia's login page. On a web browser, this is not an issue since the HASS login page will regenerate the JWT token (provided you're using hass-auth-header), so you'll just see a "flash of a login page" that's refreshing HASS's token in your browser's localStorage with a (short) redirect dance.

But on an automation system (like the mobile app), this can not happen as the mobile app doesn't execute the javascript code and even if it does, webview don't have a localStorage anyway. So the authentication is broken anyway whenever the JWT token expire. You have to clean your session on this system (which is a chore to do on Android, since it's not accessible via the application), so a new token can be requested.

By using my scheme, the automation system never see Authelia's redirect. From its point of view, it's a virgin/genuine HASS install, so the token refresh process works out of the box. When using bypass URL, you actually hide Authelia from the mobile application (that's using a limited number of HASS routes now, but that will change in the future) but you also remove the Authelia protection on the web frontend.

This means that if I login via Authelia via whatever other application, then go to HASS (so as to fetch its JWT token) then go to the former application and log out from Authelia, I can still browse and use HASS without being logged out, since HASS' token is still here in my cache, the login page isn't requested since the JWT token is still valid from HASS's POV. This is because the web pages is in my browser cache and the API request that the website is doing doesn't check Authelia's session cookie (the API requests are bypassed).

Said differently, when using bypass URLs, when I log out from my SSO site, any later user of my browser can still use HASS impersonating me. This is not secure at all.

[maxime1992]

@X-Ryl669 I still don't understand something. You do end up with 2 endpoints, one authenticated with authelia, the other not, is that correct? If so, how is this more secure in any way I don't follow? I may be missing something here but if you have 2 doors to access your house and you create one with a 1m depth titanium and the other in cardboard, the titanium door won't be of much help. I must be missing something here, but really I understood that you end up with 2 endpoints, including 1 not protected by Authelia so that doesn't make sense to me, can you please explain differently maybe?

[X-Ryl669]

You are right in your understanding.

You have 2 doors, one is using HASS's authentication (that's the one HASS developers maintain and that is widely tested) and one is behind Authelia AND HASS's modded authentication.

I know I won't make friends in this discussion, but adding Authelia doesn't improve your security here (IMHO) since HASS basically implements the same thing as Authelia (with the same safety level or better). It actually lowers it, since in order to use Authelia you either have to run HASS in single user mode (which is highly discouraged) or use a mod (hass-auth-header) which doesn't remove authentication from HASS, but bypass/hide it. So instead of 2 successive titanium doors (Authelia then HASS) you end up with 1 stainless steel door (Authelia).

Yet, the solution described in this issue (by bypassing some URI) is bad, so I've provided another solution which I think, is way better.

When you add bypass URL as mentioned above, it's like if you leave a open window on the side of your closed door. In my previous post, I've shown that it's very easy to exploit it and I've described the steps for this.

By using an alias domain, you don't have this open window but a second door that's closed. There's no way it could be left opened.

Proof of security issue with bypassed URL

On a system with Authelia installed as `auth.a.com` and Hass installed as `ha.a.com` and with the bypass URL as decribed above: 1. Open a new browser tab 2. Navigate to `ha.a.com`. If your cookie is valid and no authentication is visible, clear your cookie & local storage 4. Refresh the page, it redirects you to `auth.a.com` 5. Log in with your credentials 6. It redirects you to `ha.a.com` 7. If you have installed everything well, you'll see a brief flash of the HASS' login page but you'll be logged in on main interface 8. Open a second browser tab 9. In this tab, navigate to `auth.a.com`, you'll see your user page. Click `Disconnect` (note: if you have other domain protected by Authelia, disconnect from any of them would do too) 10. Reselect the first browser tab and continue to use HASS: **it works :sob:** ### Why ? This is because, when you interact with HASS, the javascript code only call the `/api` routes that are bypassed by Authelia's configuration. So there's no way for HASS to know that Authelia's session is dead. The bypassed URL are like opened window in your protective wall. In my solution, since no route is bypassed, as soon as the first request is made (here `/api`), Authelia realize the session doesn't exist anymore and return a 401. This cascades to HASS redirecting to its login page which causes the browser to redirect to Authelia's login page, as expected. My solution is thus more secure.

[morganchristiansson]

HASS basically implements the same thing as Authelia (with the same safety level or better).

It's ridiculous to state that home-assistant with a large attack surface has same level of safety as a small (attack surface) and dedicated security component which does only authentication. See the recent pwnassistant exploit.

Personally, I will not open HASS to the internet without multiple security layers. Some apps (not naming names) will have recurring exploits and I'm not going to risk it if it's not needed. I'm happily using hass-auth-header with oauth2-proxy, will probably try authelia at some point as it's more configurable.

It's unfortunate that I can't use the Android app. I'm subscribed to this issue if that changes.

[X-Ryl669]

Don't misread me. If you run Authelia like documented here, that is, with bypass URLs, there is no difference with using Authelia + HASS and using HASS directly (that's what bypass URL are for, after all).

So you'll have the same safety level (or better) by not using Authelia in that case, as I've shown.

If you use Authelia like I recommand in my blog (that is, without bypass URL), you might reach a higher safety level than without.

If you need to access with an Android application, you can't use Authelia and it's a bad idea to reduce the safety of your installation (by adding bypass URL) so that your mobile application is authenticating. So you have to make a choice, yours is not to use the Android application and be safe. Other might be to allow android application on a difficult to guess subdomain as alias, even if it's a bit less secure.

The true solution would be for HASS developers to write a OIDC authentication scheme that's working in all application of the ecosystem. But that's a lot of work.

[dougmaitelli]

IMO, @X-Ryl669 solution is simple and functional and does solve the issue with the authentication layer in the mobile app in a consistent way. I will be using that personally instead of having bypass URLs myself. However, I don't agree that this is secure enough and also don't agree that having Authelia with bypass is less secure. On the contrary, having Authelia with bypass URLs should be more secure cause you do have 2 layers and the paths that you are bypassing will have just the natural HASS security, so you are AT LEAST adding more security to "parts" of HA.

[james-d-elliott]

Speaking specifically to the point about bypassing and security; bypassing in Authelia reduces the security to the level the application effectively has inherently. So if you've disabled auth on the API in HASS and you've bypassed it's definitely less secure, otherwise it's as secure as it was previously (if not more as it's more auditable).

If it is true that HASS uses OAuth 2.0 internally for authentication then I'm not entirely sure why they don't support it as a relying party / client. It's a lot easier to implement securely than provider / authorization server elements. I also think storing the JWT in localStorage is arguably significantly less optimal than an opaque token in a session cookie (https only so it's inaccessible to javascript unlike localStorage which is ONLY accessible via javascript, unlike session cookies and sessionStorage can not be set to expire) but I suppose that's another (probably very opinionated) discussion entirely.