Custom scheme for 'post_logout_redirect_uri' parameter in RP-initiated Logout

Issue #1338 resolved
Marko Ivančić created an issue

In section 2. RP-Initiated Logout, the first sentence states: “An RP requests that the OP log out the End-User by redirecting the End-User's User Agent to the OP's Logout Endpoint.”

In the parameter explanation list, for the ‘post_logout_redirect_uri' parameter, there is a statement that the scheme SHOULD be ‘https’ but it is allowed to be ‘http' if the client is confidential. However, in the RP-Initiated Logout spec there is no mention of the ‘native’ clients and how they can/should initiate logout using this flow.

For example, in the ‘core' spec, there is a clear indication on how a custom scheme can be used for ‘redirect_uri' parameter by native clients. From core spec 3.1.2.1.  Authentication Request: “The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

It seems to me that parameter ‘post_logout_redirect_uri' in RP-initiated logout requests can be used by native clients in a similar way as a parameter ‘redirect_uri’ in authentication requests from the core spec.

Is there any reason why custom scheme is not mentioned/allowed in ‘post_logout_redirect_uri'?

Thank you all for your great work on OIDC!

Comments (9)

  1. David Waite

    Could you clarify your use case/architecture here? Is this a case where the RP is a native app using a web-based OP interface (similar to the setup in RFC 8252), is attempting RP-initiated logout, and needs to terminate in a custom URL scheme (rather than say terminating via applink/universal link?)

  2. Marko Ivančić reporter

    Thank you for your comments…

    Kristina Yasuda, actually, yes, it could be an “ordinary HTTP(S)” URI, but it requires additional steps for implementer like hosting a website domain, verifying ownership and registering it (example with Android: https://developer.android.com/training/app-links#app-links-vs-deep-links). In that scenario the content of the URI is available in the app or on regular website (for users who don’t have an app). However, I’m not sure if this is feasible for everyone, nor if it is available on every OS… In RFC 8252 this is referred to as "claimed "https" scheme URI": https://datatracker.ietf.org/doc/html/rfc8252#section-7.2

    David Waite, yes, exactly, I’m referring to "private-use URI scheme" in RFC 8252: “…a URI scheme defined by the app (following the requirements of Section 3.8 of
    [RFC7595]) and registered with the operating system. URI requests to such schemes launch the app that registered it to handle the request.”, more here https://datatracker.ietf.org/doc/html/rfc8252#section-7.1

    Also, the RFC 8252 states that “… if the authorization server supports native apps, it must support private-use URI schemes…”: https://datatracker.ietf.org/doc/html/rfc8252#appendix-A (it also mentiones loopback adresses for desktop OS-es…).

    So, again, back to the RP-Initiated Logout spec - since it states that the User-Agent (browser) is to be used for logout requests… It seems to me that in order to accommodate / better support native clients, that is, to enable browsers to invoke a native client after logout using a post_logout_redirect_uri, a custom scheme should be allowed… It also seems viable since the OIDC core spec mentions that a custom scheme intended for native clients may be used for redirect_uri in authentication requests…

  3. Michael Jones

    It would seem reasonable to use the same language about the post_logout_redirect_uri that we do for the redirect_uri: “The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

    Would that solution work for people?

  4. Marko Ivančić reporter

    Yes, that would mean that a “private-use” scheme defined by the native app and registered with the operating system can be used. So, in this scenario a request to post_logout_redirect_uri with such scheme can launch an app registered to handle such requests.

  5. Log in to comment