Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

oidc: Cross-site POST form submissions are forbidden #64

Open
jfroy opened this issue Nov 25, 2024 · 6 comments · May be fixed by #67
Open

oidc: Cross-site POST form submissions are forbidden #64

jfroy opened this issue Nov 25, 2024 · 6 comments · May be fixed by #67
Labels
auth

Comments

@jfroy
Copy link

jfroy commented Nov 25, 2024

Describe the bug
I am trying to configure dashbrr to use pocket-id hosted in the same kubernetes cluster for OIDC auth. Both pocket-id and dashbrr are behind an ingress proxy that handles https termination and load-balancing.

OIDC_ISSUER is set to the https URL of pocket-id (https://pid.example.com) and OIDC_REDIRECT_URL is set to the dashbrr callback URL (https://dashbrr.example.com/api/auth/callback). There is a dashbrr app in pocket-id and OIDC_CLIENT_ID and OIDC_CLIENT_SECRET are set to the correct values.

When I try the flow, after I login from pocket-id and it redirects my browser to dashbrr, I see this error in the dashbrr log:

│ 3:26PM ERROR code exchange failed error="oauth2: cannot fetch token: 403 Forbidden\nResponse: Cross-site POST form submissions are forbidden"

To Reproduce
Steps to reproduce the behavior:

  1. Deploy an OIDC provider and dashbrr behind an https proxy
  2. Configure an app in the OIDC for dashbrr and configure dashbrr.
  3. Configure dashbrr to use that provider.
  4. See error

Expected behavior
OIDC login should work.

Desktop (please complete the following information):
Operating System: Arch Linux
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.12.1-2-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor
Memory: 62.4 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4090/PCIe/SSE2
Manufacturer: ASUS

Google Chrome	131.0.6778.85 (Official Build) (64-bit) 
Revision	3d81e41b6f3ac8bcae63b32e8145c9eb0cd60a2d-refs/branch-heads/6778@{#2285}
OS	        Linux
JavaScript	V8 13.1.201.9
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
@s0up4200 s0up4200 linked a pull request Nov 26, 2024 that will close this issue
Open
@s0up4200
Copy link
Collaborator

s0up4200 commented Nov 26, 2024 •
edited
Loading

Can you test pr-67 and see if that fixes the issue?

I've updated the CORS configuration to properly handle this scenario (hopefully) by allowing credentials and the necessary CORS headers.

@s0up4200
Copy link
Collaborator

s0up4200 commented Nov 26, 2024 •
edited
Loading

I've run OIDC with tailscale serve without any issues since day one though, so kind of interesting. Using auth0, so external provider however.

@jfroy
Copy link
Author

jfroy commented Nov 26, 2024

Can you test pr-67 and see if that fixes the issue?

I've updated the CORS configuration to properly handle this scenario (hopefully) by allowing credentials and the necessary CORS headers.

I've just tested and the error is gone. However, I do not get logged in. I just get back to the login page. The only log entry I go through the flow is

INFO initiating login flow

@s0up4200
Copy link
Collaborator

I fired up a pocket-id instance to debug this further, and I believe I figured it out.

pocket-id does not include token expiry times in their responses. This caused authentication to fail, as the session immediately expired!
Added default 24h expiry when token.Expiry is zero

10:41AM INFO Starting server address=[::]:8080 database=./data/dashbrr.db mode=debug

10:41AM DEBUG initializing auth handler issuer=https://pocketid.dusty-sofa.ts.net/
10:41AM DEBUG OIDC discovery successful issuer=https://pocketid.dusty-sofa.ts.net well_known_url=https://pocketid.dusty-sofa.ts.net/.well-known/openid-configuration
10:41AM DEBUG using discovered endpoints auth_url=https://pocketid.dusty-sofa.ts.net/authorize token_url=https://pocketid.dusty-sofa.ts.net/api/oidc/token

10:41AM INFO initiating login flow

10:41AM DEBUG received callback has_code=true state=a7383699b141a74756af8e6d892903d1
10:41AM DEBUG exchanging code for token
10:41AM DEBUG token exchange completed token_received=true
10:41AM DEBUG token had no expiry, assigned default 24 hours assigned_expiry=2024-11-28T10:41:21+01:00
10:41AM DEBUG session stored in cache expires_at=2024-11-28T10:41:21+01:00 session_key_prefix=oidc:session

10:41AM DEBUG Loading configuration from database display_name=Overseerr instance=overseerr-1
10:41AM DEBUG Loading configuration from database display_name=Tailscale instance=tailscale-1
10:41AM DEBUG Loading configuration from database display_name=Autobrr instance=autobrr-1
........

@s0up4200 s0up4200 linked a pull request Nov 27, 2024 that will close this issue
fix(auth): improve OIDC authentication reliability #67
Open
@s0up4200 s0up4200 added the auth label Nov 27, 2024
@jfroy
Copy link
Author

jfroy commented Nov 27, 2024

Is this an issue with pocket-id (I can file an issue there), or is this allowed by OIDC?

And thanks for figuring it out!

@s0up4200
Copy link
Collaborator

From what I understand, they are correctly sending expiry for id_token (mandatory), but not for access_token (optional), so this was more of a bug on our end I'd say.

Thanks for bringing pocket-id to my attention by the way! I will start using this myself from now on 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auth
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(auth): improve OIDC authentication reliability autobrr/dashbrr
2 participants
@jfroy @s0up4200