Could `Config::token_url` be made optional?

[NicMcPhee]

Could `Config::token_url` be made optional?

[NicMcPhee]

Actually, am I totally confused here? Doing some more reading, I'm now thinking that token_url should be the GitHub URL that yew-oauth will use to get tokens? Is that true? Have I got this thing totally turned around? Many apologies if I have.

[ctron]

OAuth2 can be quite confusing :) … The redirect URL is sent to the SSO server (GitHub in your case) so that the SSO server know which URL to redirect the user, once the authentication is complete. Part of this is the "code".

Now in order to ensure that the user doesn't get redirected to a malicious site, you configure a list of allowed (redirect) URLs on the SSO side.

The redirect URL normally is your application which started the whole login process. It then gets called back, including the "code", which it internally (by doing an HTTP request in code, JS or WASM) trades for an "access token", using the "token URL".

So:

• The redirect URL should be the URL of your application
• The token URL must be the token URL to trade the code for an access token, for github: https://github.com/login/oauth/access_token (also see: https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps#2-users-are-redirected-back-to-your-site-by-github)

This also means, that the "token URL" can never be optional.

[NicMcPhee]

Thank you so much for your help. I must say I've been really surprised at how confusing this whole OAuth thing has been for me. I've been adjacent to people doing OAuth in the past, and felt like I at least roughly understood what they were doing. Now that I'm trying to deal with it directly (& in a quite different environment), it's clear that I didn't understand nearly as well as I thought I did.

You've helped a lot here, and hopefully I can leverage that to get over this hump in my project. Thanks!

[NicMcPhee]

Sorry to take up more of your time, but I'm still befuddled and I'm hoping you could clarify something for me, @ctron.

The redirect URL should be the URL of your application

I think this is a problem if I want to have a "pure" Yew app deployed on GitHub Pages. I can't have my Yew app be the callback (redirect URL) can I? And even if I can, I'm not "supposed" to do that because then my tokens are in the browser and potentially at risk?

My original vision was to:

• Write my web app using Yew and deploy it as a SPA using GitHub Pages.
• I was hoping I wouldn't need any server infrastructure (everything that's relevant is on GitHub through Pages and their API).
• When I got to the OAuth part of the puzzle, it seemed like I needed at least some (very limited) server infrastructure, and I was hoping to use Cloudflare Workers (or some other "serverless" service) to play the role of the server. And this is where I've gotten all bogged down.

When I try to put the URL for my Cloudflare Worker in as the redirect URL, I always get a mismatched URL error from GitHub, even though the URLs seem to be to be identical.

Do you have a sense of how deep a swamp I've wandered into? To make it work, will all the requests have to go through Cloudflare so that "the URL of your application" will be the Cloudflare worker URL?

I feel like I've read 72.8% of the Internet and run a whole host of examples, and none of them seem to quite line up with what I'm trying to do, and I can't figure out if I'm almost there or tilting at windmills. Sighz.

I realize that this isn't really a yew-oath2 "problem", but I'm not sure what the fundamental issue is or which community to go ask for help. Thanks a ton for your time.

[ctron]

I think you should be able to do that. The Patternfly Quickstart application is also hosted as a GitHub Pages application. And you can use this as a callback too (unless GitHub prevents you from doing so).

From a token perspective I don't think this is a problem either. Because the token is only "stored" in the browser session (not the "local" storage, not as a cookie). So even other tabs don't know about this token. Also, to my understanding, the session store is different for each origin. So you would get the same storage for you.github.io, but that is content that you actually control.

Also see: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage