[
https://issues.apache.org/jira/browse/NIFI-11880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749205#comment-17749205
]
David Handermann commented on NIFI-11880:
-----------------------------------------
Thanks for summarizing this issue and providing the background [~bobeal].
[Keycloak Issue 12916|https://github.com/keycloak/keycloak/issues/12916]
describes this as expected behavior for Access Token revocation, but also notes
that using the OIDC Logout process effectively invalidates the Refresh and
Access Tokens without requiring a call to the revocation endpoints.
Earlier versions of OIDC integration in NiFi used Token Revocation as an
alternative logout processing method in the absence of Provider support for
RP-Initiated Logout. For example, Google's OIDC implementation supports token
revocation, but does not support RP-Initiated Logout. With the introduction of
support for Refresh Tokens in NiFi 1.21.0, Token Revocation occurs regardless
of the logout process.
The challenge is that some Identity Providers support RP-Initiated Logout, but
many do not. In those scenarios, Token Revocation is the next best option.
Another challenge is that the [RP-Initiated Logout
Specification|https://openid.net/specs/openid-connect-rpinitiated-1_0.html]
does not appear to indicate what the Identity Provider does with Access Tokens
and Refresh Tokens. Keycloak's interpretation seems to be ideal in terms of
revocation, but that may not be true of other Identity Providers.
It is worth noting that Access Token revocation and Refresh Token revocation
are separate requests, so some new conditional behavior could be applied
specifically to Access Token revocation, without changing Refresh Token
revocation.
The ideal solution would drive the behavior based on the OIDC Discovery
configuration. We could consider changing the Access Token revocation behavior
on logout to follow the approach from previous versions, where it only occurs
when RP-Initiated Logout is not supported. It would be helpful to evaluate
several other popular Identity Providers for comparison. That would help
determine whether this should be a change in the standard behavior, or whether
it should be a configurable option going forward.
> OIDC - Consents given by users are removed when logging out
> -----------------------------------------------------------
>
> Key: NIFI-11880
> URL: https://issues.apache.org/jira/browse/NIFI-11880
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 1.22.0
> Reporter: Benoit Orihuela
> Priority: Major
>
> Hello,
> I'm using NiFi 1.22.0 with OIDC enabled (backed by Keycloak as the IAM
> solution).
> I noticed that when an user logs out, there are explicit calls to revoke the
> access token and the refresh token (if any) associated to the user. However,
> when revoking an access token, Keycloak also removes the underlying
> authorization grant and thus the user has to accept them again each time he
> logs in.
> I had a look at the OAuth 2.0 Token Revocation specification (and more
> specifically [https://datatracker.ietf.org/doc/html/rfc7009#section-2.1),]
> and it seems it is a compliant (but optional) behavior with respect to
> Keycloak: "Depending on the authorization server's revocation policy, the
> revocation of a particular token may cause the revocation of related tokens
> and the underlying authorization grant"
> So, I was wondering how it could be improved in NiFi. Could these calls to
> the revocation endpoints be optional? Is there a better solution? (I may
> contribute to this if needed)
> Regards,
> Benoit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
