Okay, I've updated the PR to make the IAP middleware more transparent as requested. Now, all the frontend needs to do is call /user/token on refresh and it will get an IAP derived token if there is…
Following up just to make sure I capture the implicit decisions here, so you want for the backend:
- If a valid jwt token is presented from the frontend, use that (e.g. ignore the IAP header) 2.…
Yes, or at least if not already logged in / if current jwt token is expired. Essentially it's similar to an open-id auth from the frontend's point of view except it 1) is hitting vikunja-backend…
What I can do, is abtract this away a bit and make this an /auth/externalprovider/loggedin endpoint, so any future external auth source might also reuse the same endpoint.
Since you unified the external auth providers, could you add some docs about how to add a new auth provider in the future?
@branchmispredictor I'll give it another review, I just haven't…
There's a problem with bootstrapping auth here. The way IAPs work is by setting an http header with claims to the downstream service (vikunja-api), however javascript or front-end code does not have…