OAuth 2.0 Token Exchange (RFC 8693) on Janssen

[tawaren]

In a previous question i mentioned that we use the "OAuth 2.0 Token Exchange" standard on other auth servers to exchange a token issued by janssen with a token from another authentication server. However it turned out that in the future (not now) we need to do this on the Jannsen server as well.

If my scanning of the documentation did not fail me Janssen does not support the RFC 8693 - OAuth 2.0 Token Exchange standard.
Further, I did not find a documented intersception script that allows me to extend the token endpoint with new grant types (RFC6749 - The OAuth 2.0 Authorization Framework - Section 4.5). Is any of this or something simmilar supported and I missed it? If not are their plans to add a mechanism to extend the token endpoint with new grant types?

If not I propably need to missuse the authentication mechanism to implement the token exchange, but I would prefer to use/implement something standard complient.

[ossdhaval]

Hey @tawaren

The good news is that the Janssen Server supports token exchange(RFC 8693). But as you have rightly mentioned, the documentation is lagging and being tracked with this issue.

I would loop-in @yuriyz to comment on support for extension grants.

[tawaren]

If RFC 8693 is implemented and I can figure out how to use / configure it, I do not need extension grants, these would just have been an option to implement the functionality myself in case it would not have been supported.

[yuriyz]

RFC 8693 is implemented. You can see it via discovery response, it has urn:ietf:params:oauth:grant-type:token-exchange.

...
  "grant_types_supported" : [ "password", "urn:ietf:params:oauth:grant-type:token-exchange", "authorization_code", "urn:ietf:params:oauth:grant-type:device_code", "implicit", "client_credentials", "urn:ietf:params:oauth:grant-type:uma-ticket", "tx_token", "refresh_token" ],
...

As @ossdhaval correctly noted some documentation is missed but there should be full support of Token Exchange spec. Let us know if you think something does not work. Simply follow spec samples when calling jans server.

I did not find a documented intersception script that allows me to extend the token endpoint with new grant types

You can inject logic when tokens are created but it's not possible to add new grant types via interception scripts if you meant it.

[tawaren]

I mostly interested in the a usecase where "requested_token_type=urn:ietf:params:oauth:token-type:jwt" for the specific case where "subject_token" was issued by a different authentication server as mentioned in Section 3 of RFC 8693. Here the question is how to configure which tokens are excepted and which aren't. At least I assume their is some way to limit the accepted issuers, even better would be if additionally a required scope can be specified that the "subject_token" must have.

[nynymike]

I think you could use the UpdateToken script to customize the business logic for token exchange.

[tawaren]

If I can access the content of the "subject_token" from an UpdateToken script (could be possible by directly reading request parameters), that is indead a good suggestion for customizing the result and even to do some additional access checks.

[yuriyz]

You can access "subject_token" and make checks which you need in UpdateToken Script.

Example

    def modifyAccessToken(self, accessToken, context):
        var subjectToken = context.getHttpRequest().getParameter("subject_token")
        return True

However AS requires subject type to be urn:ietf:params:oauth:token-type:id_token since it's the only supported subject type currently.

[tawaren]

You mentioned that urn:ietf:params:oauth:token-type:id_token is the only supported type, does the token endpoint only accept id tokens issued by itself or can it be configured to accept id tokens from other authentication servers. Because if it only accepts tokens it issue itself, then I probably need to implement my own token exchange (probably over the authorization challenge endpoint)

[yuriyz]

It accepts only tokens issued by itself.

[nynymike]

It would be nice if during the client credential authn flow, there was a script that could make available the body of the post, a header, or an extra-parameter. But I see we don't have an interception script for client authn... but maybe we should ?

[yuriyz]

I guess it's already possible with authentication custom script but add special "usage_type" configuration with type "service" (or "both") which makes it invoking during client authentication as well.

jansModuleProperty: {"value1":"usage_type","value2":"service","description":""}

I think it was added in very early oxauth version and as far as I can see is present in jans as well. However I can't find any samples in repo.
Maybe @yurem have some samples.

[nynymike]

jansModuleProperty ? I'm not sure what this is used for. Also are you saying it's possible with the Person Authn Script? We have a distrinct script for ROPC, so I think it makes sense for us to have a specific script for client authn. It's an important event. BTW, maybe we also need a script for the Token Exchange Grant to stop the inexorable repetition of people asking about token exchange :-)

[yuriyz]

Yes, jansModuleProperty can be used to trigger PersonAuthenticationType during client authentication. Very cryptic way and also confusing given it's "Person*" name script. I've added two tickets:

• add client authn custom script - feat(jans-auth-server): introduce client authentication custom script #8081
• add token exchange grant custom script - feat(jans-auth-server): add token exchange grant custom script #8082