Mechanism for SPA to discover auth0 login url

[KarolisL]

SPAs get HTTP 403 after token expires. This works as expected, but it would be nice if in such case, SPA could open a new window with Auth0 login page. For this to work, we need two things:

• NONCE cookie to be set
• Http Header (or other mechanism) to discover the login URI

Relates to #128

[dniel]

I havent created a SPA yet for myself, I have focused on API authentication for now. I should probably create a simple SPA to test how forwardauth + auth0 behaves.

ForwardAuth uses the authorization code grant flow from Auth0/OAuth2/OIDC.
Maybe even it could be that a SPA should actually authenticate by itself by using implicit grant instead https://auth0.com/docs/architecture-scenarios/spa-api/part-1#implicit-grant and adding the resulting tokens as cookies so that when calling a API, ForwardAuth would authenticate and authorize the request not even knowing that the tokens was not retrieved by the normal authorizatoin code flow.

I need to read up on this to find out if acutally most of the implementation could be done using normal implicit grant flow and possible add eventual missing features to ForwardAuth to support it like the normal authentication code flow for APIs.

[dniel]

New guidance in using implicit grant https://auth0.com/blog/oauth2-implicit-grant-and-spa/

[dniel]

If the API are secured with the same middleware used to enforce web sign on, they are likely to return a 302 when the session cookie expires. 302s aren't really actionable when returned in AJAX calls, and that means that the JS code will need some error management logic to handle the situation- one that possibly doesn't end up sending the browser to pages controlled by an attacker

could possibly be the mechanism you are thinking about.

[KarolisL]

Awesome! This looks exactly what we need: we're serving our SPA from the same domain as our API.

Would you accept a PR if I implemented the following logic:
If the call is an API call then forwardauth would:

• Set the cookie header with NONCE
• Return 302 redirect to auth0 signin page with the same NONCE in the state (IIRC) field

[dniel]

Hm, wouldn't that be exactly how the standard non-API type of URL is handled?
I have to check the code to remember exactly. :)

[KarolisL]

Non-API URLs return HTTP 307 so browser follows them when it does AJAX requests. It might be ok to return HTTP 302 in all cases (API and non-API), but we might break existing API clients which expect 403.

[dniel]

The 307 was chosen so that the method would not be changed by the redirect, but when thinking of it, it is probably not a problem because if you want a redirect you want a redirect with GET to Auth0 login anyways.

[KarolisL]

So what do you think about this approach?
I've got another idea that we might return 302 Found for APIs only if client sent some specific header. This way we wouldn't break existing clients which expect 403 Forbidden.

[dniel]

We could try changing for 302 Redirect and see how it behaves, especially for AJAX calls.
The 403 forbidden handling of API calls was done to make it cleaner for api clients that anyway cant do anything about the redirects that only a html client can handle.
How would the SPA handle the redirect, open a new window to authenticate or do a redirect with the whole page and back?

[KarolisL]

I think SPA could do either of those, it is up to SPA to decide. In my case, I'd prefer if I could just open a new window, make user to get new code from auth0, signin with forwardauth to get new token, and then re-try the request which "failed" with 302.

Does that make sense?

[dniel]

Yup, that was the way I was thinking it would work.
Is there a case where a AJAX client would need to distinguish between a redirect for auth, and a normal redirect by the backend API?

[KarolisL]

In my case, there isn't. In most cases I can think of, the backend should use 303 See Other or 307 Temporary Redirect instead of 302.

[dniel]

If you want to have a go at it, create a PR that removes the special response handling of API types, and both API and normal clients get the same 302 redirect. If you have a simple SPA to test with as well, it would be very helpful if you could contribute it for further development for ajax/spa clients. And if you want to use the CI/CD I have configured (have a look at the contribution page) I could add you as a contributor to the repo. Another question just out of curiosity, what environment do you use? Kubernetes, standalone docker or something else? man. 27. jan. 2020 kl. 10:59 skrev Karolis Labrencis < notifications@github.com>:

…

In my case, there isn't. In most cases I can think of, 303 See Other or 307 Temporary Redirect should be used instead of 302. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#151?email_source=notifications&email_token=AAFNMCSHQVTOO5R2HOGJG6TQ72V7RA5CNFSM4KLMFDP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ65WHA#issuecomment-578673436>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFNMCUBMF6QOKYBODSHAZTQ72V7RANCNFSM4KLMFDPQ> .

[KarolisL]

If you want to have a go at it, create a PR that removes the special
response handling of API types, and both API and normal clients get the
same 302 redirect.

Alright, I hope to start sometime this week.

If you have a simple SPA to test with as well, it would be very helpful if
you could contribute it for further development for ajax/spa clients.

I don't have one at the moment, since I'm using my project's SPA to test the flow.

And if you want to use the CI/CD I have configured (have a look at the
contribution page) I could add you as a contributor to the repo.

Sure, that would be nice!
Also, it would be very helpful if you shared your IntelliJ IDEA code style configuration (I assume you use IDEA to develop this project), since I change half of the lines while hitting "auto format file" with my current code style config. :-)

Another question just out of curiosity, what environment do you use?
Kubernetes, standalone docker or something else?

Stable version of forwardauth is deployed to my project's GKE clusters.

When I want to e2e test changes in Forwardauth (i.e. when I'm developing a PR), I use telepresence to swap real ForwardAuth deployment with one started in my IntelliJ IDEA IDE (on my PC). So the traffic flow looks like this:
[User browser (uncluding the one on my PC)] ---> [GCP LoadBalancer] ---> [Traefik] ---> [Telepresence proxy in place of Forwardauth pod] ---> ForwardAuth on my PC.

[dniel]

Kool, I added a .editconfig file from my IDEA to the 2.0-rc1 branch. I use default IDEA settings for code style. And also added you as a collaborator to the repo.