-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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 RFC8693: Token Exchange #1218
Comments
While it looks like a reasonable approach, there are so many different grant extensions to the existing OAuth2 protocol in draft (or self-defined by e.g. Google) that we simply lack the resources to implement and maintain them, which is why drafts are generally not being implemented. In my personal view, I'm not a fan of using OAuth2, a framework that was initiated to give 3rd party developers a way to access personal information, for things like workload/service auth. I think systems like SPIFFE take a much more sane approach to this. We are actually working with Scytale, co-founded by Evan Gilman (he wrote the Book Zero Trust Networks), to deliver a way to solve workload auth in the context of OAuth2. But this will (obviously) take a while. Closing this, for now, as a wontfix/wontdo. Feel free to keep the conversation going though. |
Sorry @aeneasr for writing in this closed issue but I'm just wondering if you could give more details regarding this statement:
We are already using Hydra and OIDC for user authentication and we are planning to use it for authorizing third party applications using the |
You can use client_credentials if you want to. The proposed draft above is something completely different. |
OK, I misunderstood your sentence then. Thanks for the clarification! |
Hi @aeneasr In our projects we use Hydra as authorisation server and for some use cases we will need a token exchange. |
We currently lack use cases / popular demand and resources to tackle this, but do welcome contributions. As a word of caution, this will be a lot of work to implement! |
Hi @aeneasr |
Sounds good! I'll reopen that - for clarification, this will be about implementing https://tools.ietf.org/html/rfc8693 right? |
Yes that is RFC8693. |
Sorry, I overlooked your comment. Yes - no need to create another issue! |
Our use case: Implementation idea:
Permission checks
Option 2:
What's your opinion on that? |
Thank you for your thoughts! I think that sounds reasonable! The idea of Are there best practices around this? I do think that it might be tricky if every client is allowed to exchange token with one another so we probably need some type of restriction. I think a callback wouldn't work that well because there is no user interaction (similar to client_credentials), so probably option 1 would be the way to go. |
Correct, the may_act claim specifies whether a client is allowed to exchange the token it has received in order to "act" has the original client (of the token it received). So in the example before (and in answer to your question) the token of A should contain may_act claims for B and C (assuming C should keep offline access / get a refresh token), specifying that B and C can exchange the token sent by A. The problem we have in this scenario is that rfc8693 only provides a brief example with a flat structure for may_act, e.g.: "may_act" : and what we need would rather be something like an array of multiple subjects e.g.: "may_act" : [ in order to define a possible chain of delegation, or perhaps something simpler. "The may_act claim makes a statement that one party is authorized to become the actor and act I totally agree with you, not every client should be able to exchange any token it receives, therefore the importance of the "may_act" claim in the token to be exchanged. After a longer discussion we came up with the use case that at some point, in the previously given scenario, user U may wish to revoke the a exchange grant it gave before to some application (e.g. application B or C). If we restrict the check to the may_act claim within the token to be exchanged, it would not be possible to revoke a previously issued token when this has e.g offline access, as the application could indefinitely refresh its token. Considering this, it would be enough to have this information within the client, at least for an first implementation, as a list of "clients" that are allowed to perform the exchange. So in the previous example, U gave exchange rights to applications B and C, B did an exchange and got an own refresh token, passes the token to C and C exchanges and gets an own refresh token. If at some point U remove the exchange permission to B, when using the refresh token again B would get an unauthorized. This would imply extending the refresh logic to check if the client refreshing the exchanged token still has the right to do so. |
I am marking this issue as stale as it has not received any engagement from the community or maintainers in over half a year. That does not imply that the issue has no merit! If you feel strongly about this issue
We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors. Thank you for your understanding and to anyone who participated in the issue! 🙏✌️ If you feel strongly about this issues and have ideas on resolving it, please comment. Otherwise it will be closed in 30 days! |
Marked as stale in error. |
Hello contributors! I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic. Unfortunately, burnout has become a topic of concern amongst open-source projects. It can lead to severe personal and health issues as well as opening catastrophic attack vectors. The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone. If this issue was marked as stale erroneous you can exempt it by adding the Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you! Thank you 🙏✌️ |
Hi, any news on this? |
https://datatracker.ietf.org/doc/html/rfc8693 declares new grant type "urn:ietf:params:oauth:grant-type:token-exchange". We tested hydra 2.0 for use with new grant type but without success. Also, we didn't found any configuration options for this flow or any code in codebase which is intended to support it FYI @aeneasr |
Same here, we are also trying to use the same. Although same is implemented in Keycloak. We were very enthusiastically planning to migrate from keycloak but unfortunately got stuck here. |
Why not implement it and submit a pull request?
I'm sure the project would greatly appreciate it.
|
@ghenry, the release notes state that this RFC is implemented, but I can't seem to find any trace of it in the docs or codebase. |
Where are folks seeing this mentioned? Nothing on the code base - https://github.com/ory/hydra/search?q=RFC8693 |
… On Mon, Nov 28, 2022, 3:55 PM Gavin Henry ***@***.***> wrote:
Nothing here https://github.com/ory/hydra/releases/tag/v2.0.2
—
Reply to this email directly, view it on GitHub
<#1218 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABO2MOOR54MID6D5XNGERDTWKUS5HANCNFSM4GJG2QEQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
It looks like it might just be from the go client sdk: Line 74 in d768cf6
#3337 https://github.com/ory/hydra/blob/74d4569a0c15d7b2d1bbf435937d0cf98175ff57/internal/httpclient/docs/OAuth2TokenExchange.md Line 779 in d768cf6
https://github.com/ory/hydra/blob/74d4569a0c15d7b2d1bbf435937d0cf98175ff57/internal/httpclient/docs/OAuth2Api.md https://github.com/ory/hydra/blob/74d4569a0c15d7b2d1bbf435937d0cf98175ff57/internal/httpclient/docs/OAuth2Api.md#Oauth2TokenExchange hydra/internal/httpclient/api/openapi.yaml Line 3393 in c586e03
Line 2889 in c586e03
|
A low effort search to check if the IETF URN for exchange is used within Hydra or Fosite yields no results: https://github.com/search?l=&q=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange+repo%3Aory%2Fhydra+repo%3Aory%2Ffosite&type=code @aeneasr, any chance we can get clarification and whether it's implemented or the release notes jumped the gun? |
OAuth 2.0 Token Exchange (RFC8693) is now fully supported, including the JSON Web Token profile! it seems only support rfc7523 @aeneasr |
Yes, we messed up in here unfortunately. Can you help us identify all the places where the incorrect RFC is linked? We have to update it :) |
Hello all, have a look at this community project: https://github.com/Exact-Realty/ts-hydra-rfc8693 This will help you use OAuth2 Token Exchange until its implemented in Ory Hydra |
Hello contributors! I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic. Unfortunately, burnout has become a topic of concern amongst open-source projects. It can lead to severe personal and health issues as well as opening catastrophic attack vectors. The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone. If this issue was marked as stale erroneously you can exempt it by adding the Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you! Thank you 🙏✌️ |
Well, that's a bit of an unfair way to categorize it. This is one of the most commented open issues. The fact that people are respectfully not spamming it doesn't mean that it's not one of the more wanted issues right now. Also, for me this was literally THE deal breaker on whether I could use Ory on my last few projects. |
|
I also require this feature. In my use case I trust/verify a Google token in AppScript (for a looker studio connector) and want to exchange it for an access token for auth to my apis. I’m shopping for auth solutions because I’m currently implementing oauth2 myself and that seemed like re-inventing the wheel. This use case is a dealbreaker though. |
Eagerly Waiting, This is a deal breaker. |
In a zero trust microservices architecture, it is extremely useful to have an ability to generate "on behalf of" access tokens with shorter lifespan and narrower scope when performing service to service calls.
Even though OAuth 2.0 Token Exchange (https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is a draft right now, it would be extremely useful if Hydra supported a way to exchange an access token with an "on behalf of" token.
Describe the solution you'd like
Standard-based:
Proprietary:
The text was updated successfully, but these errors were encountered: