Code repo: https://gitlab.com/danbunea/electric-ring-auth0-authentification

It is pretty simple. Once auth0 authentifies you redirects to your website with a code. You then use that code to make a http call back to auth0 to obtain the logged user info: https://gitlab.com/danbunea/electric-ring-auth0-authentification/-/blame/main/components/auth/src/auth/use_cases/token_from_code/auth0.clj?ref_type=heads#L89

I will continue to improve it and to adapt it to electric-fiddle

also the redirect from auth contains a state which you provide when redirecting to it. I'll need to use it to check that I actually triggered the authentification in the first place.

The middleware so far it;s not quite good, but I'll improve it

thanks for making this! i'm working on an app that will require auth0 so this is perfect timing. will take a look.

Not quite done but the main functionality of redirecting and obtaining the user from the code work well

Yes @U06B8J0AJ sure, I'd like to see it if possible

Here it is : https://gist.github.com/eneroth/1ed58a31f4dc3609309cbb8ff6bfe96e Some notes: • It prefers the Auth0 Java API over the JS one. • The return value is nil while not logged in or logging in, or a map of claims while logged in. A logout URL is amended to the claims map. • This is an entirely stateless (modulo the current browser URL being a state) due to being repeatedly bit in the ass by various problems owing to Auth0 statefulness. Being stateless, it doesn’t store anything in cookies/localstorage, but contacts Auth0 for login on every page load, with the session being effectively as long as the Electric app is live. So no cookies/localstorage/refreshTokens etc. (yet). Being able to silently log in makes it bearable nevertheless. • It makes use of some helpers from namespaces not included here. I’ve left a comment here and there, but if it’s unclear I can elucidate.

Had a brief look, you're using the Auth0 java API, I wanted to do the calls using http from the clojure server backend, so I can reuse them with other systems (directly Google or Azure AD, Keycloak, AWS Cognito). The basic redirection and exchanging the code for an access token then for the user info is quite similar. I just wanted all to have some unit tests. Where we differ is the stateful vs stateless, and I think a stateless approach is better. I'd like to understand it better. Since I want to have the app running on iOS devices, this tends to cut off the websocket every time the app is sent into the background, so when it is active again it recreates the websocket, but I'd need to revalidate the login. Since the code isn't valid anymore and I have nothing on the browser how would I do it? Your Silent Login approach

how would it work?

The flow is roughly: 1. Get a code 1.1 Get the code from query params of the current URL. 1.2 If that didn’t work, try a silent login. A silent login amounts to mounting an iframe and waiting for a webmessage to be passed back containing the code. This could fail inside the iframe, and it won’t be possible to know if or why, so a timeout is needed to cancel the attempt. 2. Use code or redirect 2.1 If there is a code at this stage, use it to exchange for claims etc. 2.2 If that didn’t work, redirect to the (non-silent, visible) login page. On return, the flow will re-run from 1.

I love your solution. My understanding is: In the iframe you're opening the login link, but since you already logged in before this will go directly to the redirect giving you a code which then you integrate in the normal flow

Yeah, exactly. Auth0 itself keeps the user logged in, expiring the login according to the settings from their control plane etc. If the user has a session live over at Auth0, the silent login flow will return a code immediately. This all happens very quickly, so there’s no reason to be stateful except if: • You support offline usage (with Electric, we don’t anyway) • The user has privacy plugins that block iframes. For such users, they’d encounter the visible login screen each time, which is why I’m considering (but not in a hurry) to have some statefulness.

Either way, starting out stateless, and then carefully adding state seemed like a better order of priorities.

In fact the part I found the worse to do was the session part (using wrap-session in Ring). This avoids that part complely, as it relies of the stateful part of auth0's session cookies. As I said I love it. And I will change the code to use it.