General about Mojolicious::Plugin::OAuth2

[daleif]

First of, yes I know it is not a plugin that is maintained here, but (1) the end question is probably a bit more general, (2) it does seem there are users here who use the plugin and (3) the plugins GitHub page ¹ does not have a discussion part and seems a bit dead

For my webapps that require user auth we use Mojolicious::Plugin::OAuth2 against Azure OpenID and run our plugins under hypnotoad. It works quite well.

However from time to time OpenID fails with some strange error, and it always work just fine again if we just reload hypnotoad.

Looking at the sources, the plugin retrieves the well-known data at the time of starting up the app.

But there is no guarantee that the data retrieved via well-known data does not change over time (aka one should never hardcode them).

Wanted to know ask two questions:

(1) Has anyone else had this kind of issues and do you have a general solution for it? Do we need to have systemd reload the hypnotoad from time to time?

(2) Say we wanted to create a OAuth3 plugin that should automatically reload the well-known information after a certain amount of time. Can we do that from within the framework? Or is everything loaded in the startup phase locked in place and is to be considered static once the app is started in hypnotoad?

Hope this made sense.

Footnotes

1. https://github.com/marcusramberg/Mojolicious-Plugin-OAuth2 ↩

[guest20]

1 Reloading your service every now and then would do it, maybe you'd want to stash the last version you fetched in /var/cache or /etc/yourapp as a fall back. You don't want your app to reload in the middle of the night and then fail to start when it can't fetch these .well-known's

2a. Mojolicious::Plugin::OAuth2 is called that because it is the Mojolicious::Plugin for OAuth2. It's not the second Mojolicious::Plugin::OAuth. There isn't an OAuth 3 yet.

2b. Sharing data across the forked workers of your webapp can be troublesome, that's why the info is fetched before the workers are forked. If you want to do it more regularly than that you'll want to rate limit fetches/cache the results in some place all the workers can find it (a database or a network share or an http proxy).

I'm sure Azure won't notice the extra requests from your app, but your users will notice if azure disappears and your app crashes out about it.

[guest20]

I'd expect that a provider changing any of these parameters runs the risk of triggering a wave of helpdesk tickets from their users, so they'd mostly avoid it.

[daleif]

I've seen it enough times now to wonder why it happens. And why reloading helps.

It is not the well-known url that change, it it might be the stuff that well-known returns. Might be an idea to start logging these, just in order to be able to compare the data next time it happens (just to verify if there is a difference in the retrieved data). Might just might need to wait several months before it happens again.

[rabbiveesh]

I've always used a Mojo::IOLoop->timer set to when the key expires which automatically refreshes it

[daleif]

@rabbiveesh (1) is there actually an expire on the data retrieved from well-known url? And (2) how would you refresh the setup? Especially given some of guest20s comments?

(just wondering here)

[guest20]

You can if-modified-since and/or if-none-match to have the server (if it supports it) tell you it hasn't been modified, but you'd still need to signal your workers about it (inotify/kqueue could work for that)...

The easiest choice is to stuff all this into a database table and just select it out as the app needs it... Then keep it updated via cron or a similar scheduled task manager

Stuffing it in a db is super helpful because:

• you can have a different set of data in your dev db so you dont have to deal with all this just to get your dev instance running
• you can write a little admin page to let you add/remove/disable providers without redeployment/restart
• your prod app doesn't have to juggle data files and http requests and timeouts.

Sketchy behaviour during auth is something users are pretty sensitive about, and at worst it can just stop them using your site at all ... so having all your configs in sync us pretty important.

[daleif]

Did a bit more digging. The problem comes from running $c->oauth2->jwt_decode on the id_token that came back from the server-to-server communication. This indicate that it is the keys found during the last part of warm up via jwks_uri and used to build the jwt obj in the provider data, have probably been updated and the ones in memory no longer match the ones used to sign the id_token.

If jwt_decode fails, one might get away with simply extracting jwks_uri again, rebuilding the jwt obj and trying the decoding again.

---

Ahh, no one cannot, the jwks_uri is not stored after the warmup. Too bad.

[guest20]

The other choice is to warm up after each failure (yuck)

[daleif]

If just OAuth2 added the jwks_uri in the provider data after warm up, then on failure, we could just grab the new keys and update the jwt obj in the provider.

As it sits right now I see no other solution than to automatically reload the app from time to time.

Those keys will be replaced from time to time (good practice), so the issue here is that we (currently) have no tools to update the warmup data automatically.

[rabbiveesh]

here's what i've always done

my $gkeys;

async sub refresh_keys ($self) {
  my $url = 'https://www.googleapis.com/oauth2/v3/certs';
  my $tx  = await $self->app->ua->get_p($url);
  $gkeys = $tx->res->json;
  my $now  = time;
  my $then = str2time($tx->res->headers->header('expires')) - $now;
  Mojo::IOLoop->timer($then, sub { $self->refresh_keys });
}

async sub decode_and_validate ($self, $token) {
  if (!$gkeys) { await $self->refresh_keys }

This is in my google openid plugin. you basically store the keys needed to decode somewhere, and then refresh it on demand; in the method that refreshes it you set up a timer for when it expires.

[daleif]

Very interesting. Though I'd probably not rely on the Expires header (and I don't think Azure add that header, wget -S` against yours, does, against mine at Azure does not. Also I'd think the keys can easily be replaced within that Expire time anyway.

I think I have some working code now for my wrapper plugin (that loads and uses Mojo::OAuth2). If the decode_jwt fails (and the err code is key related (RS or HS)), then the jwks_uri is extracted and the jwt obj updated and we try the validation again. If it fails again, we stop and inform admin and the user. If good we proceed. If the frist error was not key related we also inform admin and the user.

It seems to work fine with my similated Azure app. If I start my test app and it has retrieved the Azure data, and I then update the jwks keys, and try to log in, we can see that it goes out and gets the jwks_uri again, update the JWT obj in the provider, and tries the validation again, and now succeeds.

This and periodic reload of the entire app (to reload the entire well-known data set) is probably the best solution, unless one want to retrieve well-known + jwks_uri at each connect request (in order to always have fresh data), which is probably overkill.

I'd add some of this as a feature request for Mojo::OAuth2, though it does not seem to be updated.