Hydra: Implement RFC8693

[adaniline]

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:

• IEFT OAuth 2.0 Token Exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16

Proprietary:

• Azure AD "On Behalf Of" flow with jwt-bearer grant https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow

[aeneasr]

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.

[aberasarte]

Sorry @aeneasr for writing in this closed issue but I'm just wondering if you could give more details regarding this statement:

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

We are already using Hydra and OIDC for user authentication and we are planning to use it for authorizing third party applications using the client_credentials grant. I thought that was the right approach and it would simplify our backend authn/authz infrastructure but maybe I'm missing something here?

[aeneasr]

You can use client_credentials if you want to. The proposed draft above is something completely different.

[aberasarte]

OK, I misunderstood your sentence then. Thanks for the clarification!

[smeir]

Hi @aeneasr
Since January 2020 the OAuth 2.0 token exchange grant type specification is not a draft any more.

In our projects we use Hydra as authorisation server and for some use cases we will need a token exchange.
Are there any plans to implement this extension grant type or is there any documentation on how to do it by ourself?

[aeneasr]

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!

[0ka]

Hi @aeneasr
We would like to thrive this topic forward with a contribution. Digging through the source code some points are pretty clear. But we would like to have a talk before starting this to get the right direction/architecture decisions.

[aeneasr]

Sounds good! I'll reopen that - for clarification, this will be about implementing https://tools.ietf.org/html/rfc8693 right?

[0ka]

Yes that is RFC8693.
We would create a new handler/oauth2/flow_token_exchange.go in the fosite project. Do we need an own issue in fosite or is this issue here sufficient?

[aeneasr]

Sorry, I overlooked your comment. Yes - no need to create another issue!

[mpnunes]

Our use case:
We have three applications A, B, and C.
User U grants application A access to B and C with auth code grant. Offline access should also work, means that A will get a refresh token.
Now application A accesses application B and B accesses application C (in the name of user U), allways with offline access. Here we need the token exchange (A uses its token to access B in the name of U, B exchanges the token to get an own access and refresh tokens to access C in the name of U). This chain of delegation could of course be longer (D, E, ...).

Implementation idea:

• New flow_token_exchnage.go in fosite
• Clients that have grant type "urn:ietf:params:oauth:grant-type:token-exchange" are allowed to ask for token exchange
• Request for token_exchange is similar to client_cresentials request with additional parameters as per RFC8693 (e.g. "subject_token", "subject_token_type")

Permission checks
Option 1:

• Clients have an additional claim "may_act" with a list of all IDs of the clients that should be allowed to exchange tokens. Tokens/request from the cient than contains the "may_act" field. During processing of the token exchange fosite verify that the original token/request allows the exchange for the current client requesting the exchange. (Issue here is that the spec define only one may_act field and not a list, whould be needed for chained delegation)

Option 2:

• On token-exchange hydra calls a configured callback similar to the consent app that allows to make checks externaly.

What's your opinion on that?

[aeneasr]

Thank you for your thoughts! I think that sounds reasonable! The idea of may_act is to restrict who can exchange an access token? So in your example, the client of C would have may_act: B?

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.

[mpnunes]

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" :
{
"sub": "B"
"iss": "..."
}

and what we need would rather be something like an array of multiple subjects e.g.:

"may_act" : [
{
"sub": "B"
"iss": "..."
}
{
"sub": "C"
"iss": "...""
}
...
]

in order to define a possible chain of delegation, or perhaps something simpler.
RFC 8693 is not so clear at this point. Quote:

"The may_act claim makes a statement that one party is authorized to become the actor and act
on behalf of another party. The claim might be used, for example, when a subject_token is
presented to the token endpoint in a token exchange request and may_act claim in the subject
token can be used by the authorization server to determine whether the client (or party
identified in the actor_token ) is authorized to engage in the requested delegation or
impersonation. The claim value is a JSON object, and members in the JSON object are claims that
identify the party that is asserted as being eligible to act for the party identified by the JWT
containing the claim."

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.
Unfortunately I could not find any best practices on this subject.

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.