-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Question: Intended Flow and Configuration for Single Page Apps? #571
Comments
GET {proxy-prefix}/token will output access_token, refresh_token, username, email and expires in json format, if the route is enabled (default: off). Ref bitly#571
I started working on the cookie part, then I realized the /oauth2/token route was probably better. Submitted a pull with that feature, #572 . |
It's mostly intended to use oauth2_proxy in front of apps that don't separately do auth, use tokens, etc. Depending on how much your app is doing with the auth token, you might not too far from having your app do the oauth2 itself. see also #424 |
@ploxiln I can't have the single-page app do oauth itself since I would need the client_secret in the javascript to sign the |
Ah, I didn't fully understand your situation - it actually doesn't have anything to do with whether you your app has one or more pages, but rather with the fact that it's only static file hosting on the server-side, and all logic in client-side JS. So you want oauth2_proxy to be the only dynamic/logic component on the server-side, and want it to send auth info back to the client-side JS. |
Exactly. I just discovered the |
After a lot of trial and error, I got the In my docker-compose.yml I launch it via: In my app I fetch In nginx, I have the following:
With the above config, I can get the following flow:
|
Nice! It could be nice to add this officially to the docs |
Use-Case
I have a single-page react app that needs to authenticate against the Github API, and then, subsequently, use the access_token to access said api. My question: is this an intended use case, and, if so, what should the configuration look like?
Typically, these type of apps can easily authenticate with an implicit-grant; this yields them the access-token, client-side, as part of the final redirect uri which can be parsed and used.
Config and Observations
I set up oauth2_proxy in two ways and observed the following..
config: nginx: proxy_pass everything to oauth2_proxy; oauth2_proxy: set upstream to spa, -set-xauthrequest=true, -pass-access-token=true, -redirect-url=/oauth2/callback.
observation: this sets the X-Auth-Request-Access-Token head on the request made to the spa, but I would have to configure that app to inject the header back into the response / html. Also, this means all requests to the spa are proxying through the oauth2_proxy
config: nginx: proxy_pass /oauth2/ and /oauth2/auth to oauth2_proxy, / to spa with auth_request set to /oauth2/auth, error_page 401 = /oauth2/sign_in, and add_header set-cookie $auth_cookie ($upstream_http_set_cookie); oauth2_proxy has no upstream, -set-xauthrequest=true, -redirect-url=/oauth2/callback.
observation: this performs auth requests when the user isn't authenticated, and then ultimately sets the cookie (default _oauth2_proxy) such that it's visable to the spa. The problem is that when the cookie base64 decoded, no access_token is present.
Possible Solutions
If the solution isn't as simple as adjusting my config, I'm able to help with updating the proxy code. Here are a few solutions I can think of.
The text was updated successfully, but these errors were encountered: