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.

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

Support custom registrationId in tokenRelay() for MVC gateway #3541

Open
sjohnr opened this issue Sep 26, 2024 · 4 comments · May be fixed by #3591
Open

Support custom registrationId in tokenRelay() for MVC gateway #3541

sjohnr opened this issue Sep 26, 2024 · 4 comments · May be fixed by #3591

Comments

@sjohnr
Copy link
Contributor

sjohnr commented Sep 26, 2024

In reactive gateway, I can do:

spring:
  cloud:
    gateway:
      routes:
       - id: cashcards
          uri: http://localhost:8090
          predicates:
            - Path=/cashcards/**
          filters:
            - TokenRelay=cashcard-client

In this example, I'm specifying cashcard-client as the registrationId to use for performing a token relay, instead of relying on the default behavior which resolves the registrationId from the current user (via the principal, which is an instance of OAuth2AuthenticationToken).

Note: The same can be accomplished with the DSL using f.tokenRelay("cashcard-client").

The same support and overloaded DSL option could be added to TokenRelayFilterFunctions for the mvc gateway. I'm happy to raise a PR for this.

@spencergibb
Copy link
Member

PR away!

@sjohnr
Copy link
Contributor Author

sjohnr commented Sep 26, 2024

Will do @spencergibb. I'll work on this in the coming week.


It probably goes without saying, but I'm very excited about this feature and have used it in demos already (with reactive gateway). It truly makes this token relay feature useful in a huge variety of scenarios involving OAuth2 flows.

For example, most recently we used it in the talk Cora gave at SpringOne with the token-exchange grant type, where a single access token obtained at login can be exchanged for new access tokens that preserve the identity of the user. This means that each route could potentially pass a unique token with distinct scopes, a unique audience, etc. etc. which really promotes effective use of the principal of least privilege for OAuth2 access tokens.

In that example, the goal was for the user to never even be aware that gateway is exchanging tokens behind the scenes. I personally think this enables a whole new class of OAuth2-based applications where the use of OAuth2 is almost entirely invisible to the end user. Gateway effectively becomes a broker for negotiating and making secured requests to a variety of backend applications. (Of course, it's possible without gateway, but requires a lot more code and configuration.)

/excited rant

@EeeasyCode
Copy link

@sjohnr
Hello, is there currently any ongoing work or a PR for this part? I’d be happy to help or contribute if there’s any area where I can support or collaborate!

sjohnr added a commit to sjohnr/spring-cloud-gateway that referenced this issue Nov 12, 2024
sjohnr added a commit to sjohnr/spring-cloud-gateway that referenced this issue Nov 12, 2024
@sjohnr
Copy link
Contributor Author

sjohnr commented Nov 12, 2024

@EeeasyCode see #3591, let me know if you have any feedback.

sjohnr added a commit to sjohnr/spring-cloud-gateway that referenced this issue Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants