There are two ways to use OAuth2 Proxy: route your traffic through it directly or use it with the Nginx auth_request directive. I’d recommend routing traffic through Nginx if possible, but I’ll walk through both options and explain my recommendation below.
Hi Brian, great article, thanks you so much!
Unfortunately I spent quite some time over it, but couldn’t get it working: I kickoff the flow, but after logging in via Okta, OAuth2-Proxy always returns me a 403 Error, “Login Failed: Unable to find a valid CSRF token. Please try again.”.
I can reliably reproduce it on a remote Linux machine as well as on my Mac.
Any idea what might be wrong?
thanks for this useful post. But I have question. How I can get the username in web_app (upstream application)? I tried getting it from request but that doesn’t seems available. More info here: oauth 2.0 - get username in opengrok from oauth2-proxy - Stack Overflow
Please help asap.
Very nice post… I am looking to make a React app front-end to this whole setup, that will work with the rest of the setup starting with NGINX reverse proxy …
I was wondering if you have built some react app to complement your setup here or can refer to some resource that shows how to…
In my example, the auth state is managed by a session cookie. Session cookies should work with just about every framework 
I am wondering whether the react app should be checking whether the user is logged in or not
In my React app -
I am currently doing this …
I just am making the API calls from the page where ever it needs the data.
it makes the calls via nginx to oauth-proxy,
if the react app does not send the SESSION cookie, the oauth2-proxy enters the login flow and comes back with access token and issues a session cookie for it (storing the accesstoken in redis).
Once that is done, the oauth2-proxy makes the API call to upstream , then I simply end up with the data in the browser. My React app is left behind,
I do not know how to redirect back to the React App on the page from where the call was made from.
The Oauth proxy’s ==> /oauth2/start endpoint does not support sending rd parameter, so how do i communicate to oauth-proxy, where to go back to once all is said and done with upstream api call.
You could configure your REST API endpoints to return a 40x instead of a 302. Then have your front-end trigger handle the redirect in a user-friendly manner.
That way, you can still make use of your browser and the backend to handle the sessions, and your front-end doesn’t need to contain a lot of auth logic.
Hi,
thank you for the artilce. I am a complete newbie to this process. I have done okta start and I have docker-compose up working.
The login works but i get a message that "You are not allowed to access this app. To request access, contact an admin.’
I saw that the application was defined in my dashboard but no users, so i assigned my admin user to the application. This still didnt work, same error, and then i enabled self service. Then a tried adding a group and my admin user to the group. but i still cannot access the applicaton.
In the logs for the application, on the dashboard i see that the login was successful but i am at a loss on how to configure the application to accept my user.
so i believe i solved this issue, I had no default profile setup for my new account.
I did the following and then it started to work. On the dashboard I navigated to security…api…Authorization Servers…default and added a default rule to allow logged in users
Glad to hear it’s working for you, and thank you for updating the forum with your resolution!
Thanks for the article! I am struggling with refresh tokens, however.
In the Nginx config this auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; does not seem to be working, as the Set-Cookie header is not created.
I have the OAUTH2_PROXY_COOKIE_REFRESH set and I know it is working as the cookie expiration is appropriately set in the callback. In Okta-dev I have turned on Refresh Token but I can’t seem to tell if it is actually being passed. Is there a way to check it is being passed? If it is not what might I be missing? Would that cause the header to not be set?
For anyone who cares to have refresh tokens working there are a few things that are needed beyond this article (We spent way too much time figuring this out so thought we should share).
OAUTH2_PROXY_SCOPE: "openid email profile offline_access" to your environment. offline_access is not included by default in Oauth2Proxy and is needed to get a refresh_token. Ref: OAuth 2.0 Scopes (okta.com)OAUTH2_PROXY_COOKIE_EXPIRE shorter than the refresh token lifetime. The refresh token lifetime was hard to find and the default is supposed to be 90days but was 60min on my Okta dev server. Both Access and Refresh Tokens having the same lifetime is problematic unless you use a rotating refresh token in the next step. Refs: ODIC & OAuth 2.0 OKTA token lifetime, Okta Refresh Token Lifetime Does Not MatchOAUTH2_PROXY_COOKIE_SAMESITE: none and OAUTH2_PROXY_COOKIE_SECURE: true but this has not been confirmed.Notes:
set-Cookie header unless it is needed so it will not be present in the first call but a call after the OAUTH2_PROXY_COOKIE_REFRESH time should include it./oauth2/auth by commenting out internal and inspecting its headers.refresh-token: true included in a long message if it is being received.Reports>System Log will help you check if the Refresh token is being sent.I think that covers it. If I think of anything else I will update. Good Luck
Hi there @afox
Thank you so much for adding and documenting this info!