mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #4659] [Feature Request] OIDC support for raw tokens and claim verification #3681
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#3681
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @foresturquhart on GitHub (Feb 6, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4659
Originally assigned to: @blizard863 on GitHub.
Describe the feature request
On the client, I propose adding a
rawTokenfield to theAuthOIDCClientConfigstruct. ThegenerateAccessTokenfunction inpkg/auth/oidc.gowould be modified to use thisrawTokenif provided, bypassing the client credentials flow.On the server, I propose adding an
allowedClaimsfield to theAuthOIDCServerConfigstruct. TheVerifyLoginfunction inpkg/auth/oidc.gowould be modified to decode the JWT payload, extract any claims, and compare them against the allowed claims before performing signature verification.Describe alternatives you've considered
No response
Affected area
@blizard863 commented on GitHub (Feb 7, 2025):
I don't think that's the standard for oidc, looks like it's unique to Google ?
I didn't find the definition in the RFC document for oidc.
@foresturquhart
@foresturquhart commented on GitHub (Feb 7, 2025):
I didn't consider that originally, but yes, it does seem to be unique to Google. If I'd realised it was Google-specific I'd have made that clearer in the proposal.
My goal is to enable users to restrict access based on Google Workspace membership, and the
hdclaim is the most direct and reliable way to do that when Google is the OIDC provider. I can see the problem, though, with introducing a Google-specific check.Maybe instead it could have a configuration option of
allowedClaims, which could work likeauth.oidc.allowedClaims = { "hd" = "workspace-domain.com" }? That would allow it to filter based on other types of claim, making it a bit more generic?@foresturquhart commented on GitHub (Feb 7, 2025):
@blizard863 I've amended my feature request, and also made the corresponding change to my PR.
@blizard863 commented on GitHub (Feb 7, 2025):
I don't think this is a standard practice, it's a violation of the semantics of oidc.I looked at your code carefully and it seems that you need to configure a token string on the client side and allowedClaims on the server side to perform Google's special checks before oidc normalization checks.
If so, it seems to me to be a breach of the oidc protocol.I suggest you consider token authentication + metadata + server plugin or oidc authentication + metadata + server plugin.
Did I get it wrong? Or you could go into more detail about your scenario.
https://github.com/fatedier/frp/blob/dev/doc/server_plugin.md
@foresturquhart commented on GitHub (Feb 7, 2025):
@blizard863 It's quite possible I've made a mistake, I'm not an expert on OIDC. The scenario was that we wanted to operate a single FRP server instance, and enable multiple local clients (developers) to connect to the FRP server. We wanted to make use of the OIDC token created by
gcloud auth print-identity-tokento streamline the process and make it easy to use.The idea behind my implementation was to use that token as the rawToken, and then the server would verify it was a valid Google Cloud token, and verify it was associated with the correct workspace/organisation/domain. The reason I didn't use a server plugin was because I thought it still needed to be able to pass a raw token from the client, so unless I could create a client plugin, I felt I'd have to patch the code to enable the behaviour.
I spent a while trying to make this work in other ways before I made the patch and feature request, but I am absolutely more than happy if you have a better way! As I say, I haven't extensively worked with OIDC.
@blizard863 commented on GitHub (Feb 8, 2025):
I don't know why your patch code can work, I think your scenario is like this:
But OIDC work like this:
So I think your scene might not be standard oidc? More like token authentication?