eduvpn / apple

app for iOS and macOS
Other
61 stars 18 forks source link

do not cache token endpoint #487

Closed ghost closed 1 year ago

ghost commented 2 years ago

The app "caches" the OAuth token endpoint when storing an authorization. This is not great if the server changes endpoints, it will break and probably hit a wrong URL that now returns a 400, or 401, or whatever: everything except the proper OAuth error.

This makes the client show an error box which is bad. We want the client to reauthorize right away.

We worked around this in the case of nl.eduvpn.org by placing a file oauth.php in the location of the old endpoint that returns a 400 and some error message on https://nl.eduvpn.org/portal/oauth.php/token:

NOTE: this only works because during 2.x lifetime of nl.eduvpn.org the portal was on /portal and not on /vpn-user-portal. For other servers this WILL NOT WORK.

<?php

// work around a bug in macOS/iOS apps where the old token endpoint
// is used after server upgrade
//
// Hopefully the macOS/iOS apps can be fixed. This file can be removed
// the latest 90 days after 2022-11-10
//
// @see https://github.com/eduvpn/apple/issues/487
//
http_response_code(400);
header('Content-Type: application/json;charset=UTF-8');
header('Cache-Control: no-store');
header('Pragma: no-cache');

echo json_encode(
    ['error' => 'invalid_grant']
);
ghost commented 2 years ago

This becomes a problem when there is a 2.x server that is upgraded to 3.x where the client tries to use the refresh token which occurs if the client didn't perform any API calls in the last hour.

Scenario: on 09:00 client connects to VPN 2.x server, all good. The client goes offline and comes back at 12:00, but the server has been upgraded to 3.x. As >1 hour has expired, the client uses to refresh token to get a new access token, but the token endpoint changed and now the client gets a 404, (or 401) response and shows an error box instead of triggering re-authorization.

ghost commented 2 years ago

image

ghost commented 1 year ago

We implemented a fix in the server that handles this situation when the server is upgraded from 2.x to 3.x:

https://git.sr.ht/~fkooman/vpn-user-portal/commit/4ee4d33dea34e09aacfcae5484cd9c76d6c29959