OpenID Connect scopes unsupported

[UnseenFaith]

The base open id connect provider assumes that the scopes email and profile are available via the external provider, but that isn't always the case. It would be nice to configure these scopes, or have the ability to specify the well known configuration and have trailbase pull the allowed scopes and claims via a fetch request to the url. The latter would be nice in general since you could use the configuration to fill out the auth/token/profile urls, but ultimately I think adjusting scopes manually would be more suited and the most customizable

EDIT: I realize this is probably due to how trailbase expects authentication to work across all providers/stored in data, so removing those two as it stands would probably break stuff.

[ignatz]

EDIT: I realize this is probably due to how trailbase expects authentication to work across all providers/stored in data, so removing those two as it stands would probably break stuff.

From the top of my head, at least "email" would be needed, since TB expects that for its own auth. So yeah, you're spot on.

Other than that, making it more configurable and prefilling maybe even more information seems very reasonable.

Do you specifically want to avoid using emails or is this more of a general nice-to-have? Both is fine, just curious

[UnseenFaith]

Nah it's not to avoid using emails, it's just a matter of the external provider (Twitch) doesn't actually provide those scopes. I was just messing around with the idea of trailbase and found out that it wasn't supported by the base implementation. I don't know of any other providers that do this, but twitch specifically uses scopes to determine what access a user has to certain APIs. I think technically you could get the email via claims? They have claim support via query parameters, again though haven't really interacted with another provider that does stuff like this so it might be more rare/personal.

[ignatz]

Thanks for the context. Many of the big social providers do a little bit of their own thing. We could certainly add Twitch support specifically. Glimpsing at PocketBase's implementation it should be pretty straight forward.

[UnseenFaith]

That would be great as well. The customizable scopes thing might be a little bit out of scope and maybe easier on the actual dev using trailbase to go back and request additional scopes if needed.. which I think would be necessary anyway since I don't think access tokens or refresh tokens are in the scope of what trailbase is trying to handle.. assuming someone was trying to use social login as a two way street for api access anyway

[ignatz]

Just added a twitch provider. I haven't tested it yet because I don't have a twitch setup. Are you comfortable with building from source?

The customizable scopes thing might be a little bit out of scope and maybe easier on the actual dev using trailbase to go back and request additional scopes if needed.. which I think would be necessary anyway since I don't think access tokens or refresh tokens are in the scope of what trailbase is trying to handle.. assuming someone was trying to use social login as a two way street for api access anyway

Right now TB doesn't give you access to the twitch token (or any other external token). It's just used for sign-up. You're right that if you wanted to access twitch APIs, you'd currently have to get one yourself. That's AFAICT what PocketBase, Supabase, ... do as well but if I'm wrong or there's other prior art on how to juggle this, I'd be very interested 🙏

[UnseenFaith]

Downloaded the dev branch and tried building with source using the Dockerfile and seems like it failed to build. I'm not too knowledgeable on cargo/rust but seems like I am missing a package of some sorts, unsure if it's on me or you guys.

Just for reference the L39 of Dockerfile produced this:

Downloaded async-global-executor v2.4.1
Downloaded async-channel v1.9.0
Downloaded anstyle-parse v0.2.7
error: package ID specification `auth-ui-component` did not match any packages 

EDIT: To answer the latter part of that question, the only example I can think of is Auth0/BetterAuth but they don't actually consume the tokens, it's usually made available through some middleware or route overwrite that allows a developer to hijack some of the functions (like one that creates a profile) and access the tokens returned and lets the dev do with them as they will. I think that's probably a bit more involved than trailbase is at it's current state.. I did see some posts about the potential of moving auth to it's own plugin so that things could be extended though. All in all it's usually up to the implementor to overwrite and consume them though so as it currently stands I think it's probably fine

[ignatz]

error: package ID specification auth-ui-component did not match any packages

Yikes. My recent workspace setup "cleanup" botched it :/ - Let me fix this. Also happy to cut a minor release and declare it as experimental. Trying it out would really help me 🙏

it's usually made available through some middleware or route overwrite that allows a developer to hijack some of the functions (like one that creates a profile) and access the tokens returned and lets the dev do with them as they will.

It does sound a bit like hickerey :) - How would you typically get the intercepted token from your "edge midleware" running in your auth server to the backend? Genuinely curious

[UnseenFaith]

Alrighty I pulled the new version and have been testing it. I'm not sure if I'm doing something incorrect or if it's broken so I'll explain how I think the flow should work.

• User hits login on frontend which routes to trailbaseUrl/api/auth/v1/oauth/twitch/login with a redirect_uri back to the frontend
• Trailbase does it's shenanigans to forward the user to twitch, user approves and twitch verifies the callback, which would be the trailbase callback uri here
• Trailbase authenticates with the code returned in the url and verifies that everything is correct, and then should redirect back to the redirect uri provided initially in the login route call

Right now, after approving the application, it gets redirected to trailbase with an HTTP Method 424 error and seems like it's stuck between exchanging and redirecting the user back to the frontend?

Let me know if I'm misunderstanding or have set something up incorrectly here.

It does sound a bit like hickerey :) - How would you typically get the intercepted token from your "edge midleware" running in your auth server to the backend? Genuinely curious

I've seen a couple of examples. Sometimes you can just edit directly what the database stores to tack on the tokens, other times you can attach the tokens somewhere (usually the profile object) just so you have access to them, and then store them in a separate table or however the developer wants.

From there you can just pull the token from the database and use it, or wherever it was stored.

[ignatz]

I've seen a couple of examples. Sometimes you can just edit directly what the database stores to tack on the tokens, other times you can attach the tokens somewhere (usually the profile object) just so you have access to them, and then store them in a separate table or however the developer wants.

From there you can just pull the token from the database and use it, or wherever it was stored.

Thanks for sharing. Maybe customizable profiles is something worth thinking about.

Let me know if I'm misunderstanding or have set something up incorrectly here.

Your expectation of what should happen is spot on. Let me have another go at it

[ignatz]

I didn't cut a new versioned release but the docker image labeled latest, hopefully fixes the issue. Thanks for testing and godspeed.

[UnseenFaith]

I tried building from source after pulling repository and it failed to build correctly again just as an FYI. Something about the favicon for astro being corrupted or something.

After pulling the docker image and running it, still seem to be getting the failed dependency error that I was getting before

[ignatz]

I tried building from source after pulling repository and it failed to build correctly again just as an FYI. Something about the favicon for astro being corrupted or something.

I'm guessing that you're building on window. The build instructions contain

# Windows only: make sure to enable symlinks (w/o `mklink` permissions for your
# user, git will fall back to copies).
git config core.symlinks true && git reset --hard

The docker builds should work either way. If I'm wrong, please let me know.

After pulling the docker image and running it, still seem to be getting the failed dependency error that I was getting before

sorry :/ - was really optimistic. At this point it might be easiest for me to sign up with twitch.

[ignatz]

I'll try later again but twitch's phone number verification doesn't seem to work for me right now :/