Question about using oauth2 in the frontend

[Ben-PH]

We are building an SPA in the frontend. Our design at this point involves navigating to the third party, and in the redirect, setting things up to then pass to the backend to obtain the access token.

The api of this library has raised some questions:

• Following the redirect, it's an arrival at a freshly loaded app, and the only way to check the code is to use some form of persistence as the frontend sees it (e.g. through local storage)
• Similarly for the Pkce challenge/verification
• The backend needs to receive from the frontend the pkce verifier.
• The BasicClient requires reconstruction in the backend

Alternatively, we could rejig our design such that it is all handled in the backend (i.e. the backend sends the authorisation url to the front end, but redirects to speak with the backend), and that might be the way we will end up going, but would rather do that because it's a choice in design, rather than a limitation of the api.

For context, the reason why we are doing the flow in the backend, rather than the frontend, is because when trying to authorize with github, it's blocked by CORS.

[madaster97]

It looks like GitHub is discouraging purely single-page apps in a couple ways, (1) the CORS issue you brought up and (2) it looks like they force you to register a client secret for all apps (if you don't you get this error).

At a high level, there's 2 ways you could approach this:

• You could try doing what this video did. Basically combine this library as a backend, and then trick a "frontend" oauth 2.0 library into thinking your server is the token endpoint. Kinda weird, and uses localStorage for the "session" stuff like state and PKCE
• You could use the server for the "session" portions of the workflow, in a cookie (the normal usage of this library)

That second workflow would require the following:

1. Load your SPA, with a "login with X" button
2. Clicking that button should send a fetch request to your backend, where it constructs the authorize request and sets a cookie referencing the state and PKCE verifier
3. Your SPA redirects to the authorize URL
4. On redirect, your SPA sends a fetch to the server again, which will automatically include the expected state and PKCE verifier referenced by the cookie. You should explicitly pass the code/state from the redirect to your backend here (example from OIDC foundation, may need to change window.href.location to window.location.search)
5. Your server now has enough information to check the state against the cookie and present the PKCE verifier to the auth server

If you're still interested in this, I'm trying to write up an example, derived from these examples (which notably omit the state/PKCE validation)