Allow redirect back when using direct_post on a same-device flow

Issue #1713 resolved
Joseph Heenan created an issue

As per discussion under https://bitbucket.org/openid/connect/pull-requests/327/clarified-the-definition-of-response-mode#comment-340334880 it was noted that direct_post has use cases where it may be needed or desirable to use it in a same-device flow (e.g. if the response too large or sensitive to go in a url, but the wallet is an app that can’t provide a token endpoint)..

In that situation, to have a good user experience (may also be security benefits, not sure?), it would still be desirable to be able to redirect back to the original app/website, but there’s no defined way to do that.

I think it might need:

  1. a request parameter to say whether or not a redirect is desired (as it’s probably not helpful to redirect if it’s a cross device flow)
  2. a definition of the redirect uri parameters (maybe just state, but it might need something to say ‘you should have received the result by direct post’ and presumably an alternative of an error parameter for an unsuccessful flow, e.g. if the direct post failed?)

Comments (6)

  1. Torsten Lodderstedt

    What we could do is to introduce a new parameter post_uri and use the presence/absence of the redirect uri as signal whether the RP expects a redirect back.

    Has there been a discussion what parameters should be provided with the redirect?

  2. gffletch

    To this point, I believe the only discussion has been around a response_mode parameter value.

    I think it would be useful to document the different use cases that we want to support that aren’t supported without this “direct_post” feature. That might help with whether a redirect is useful in addition to the direct_post.

    A few use cases that come to mind (and I’m sure there are more) are:

    1. User is using a “wallet” on their mobile device to login to a web site on their laptop/desktop.
    2. User is using a “wallet” on their mobile device to login to an app on their mobile device.
    3. User is using a “wallet” on their mobile device to login to an app on a different mobile device.
    4. User is using a “cloud service” to login to a web site (not sure this needs to be different from current mechanisms)
    5. User is using a “browser extension” in their browser to login to a web site (does this need a “direct_post” method?)
    6. ???

    Conceptually is this whole mechanism really just a “pushed authorization response”?

  3. Torsten Lodderstedt

    I created PR #474, which extends the direct post response mode to support redirects back to the verifier. Please review and approve.

  4. Log in to comment