Authorization request - 302 redirect response #132

grausof · 2023-09-27T15:01:10Z

Currently in the PID issuing flow and more specifically for the authorization request the response to the authorization endpoint (GET /authorize) is a 302 redirect towards the Wallet Instance (the app itself that is requesting access).

eudi-wallet-it-docs/docs/en/pid-eaa-issuance.rst

Line 222 in 84c2646

    
               Location: eudiw://start.wallet.example.org?code=SplxlOBeZQQYbYS6WxSbIA&state=fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd&iss=https%3A%2F%2Fpid-provider.example.org

Since:

react-native doesn't support manual redirect therefore it is not possible to intercept 302 redirects.
It makes no sense to redirect to a deep link of the calling app itself. This is at best just a reopening of the app.
The app itself is the user agent that is managing that request.

We were thinking if it was possible to replace the responses given by the authorization request in something like "JARM" form_post.jwt .

So I propose to change the response from:

 HTTP/1.1 302 Found
 Location: eudiw://start.wallet.example.org?code=SplxlOBeZQQYbYS6WxSbIA&state=fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd&iss=https%3A%2F%2Fpid-provider.example.org

to:

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Cache-Control: no-cache, no-store
Pragma: no-cache

<html>
 <head><title>Submit This Form</title></head>
 <body onload="javascript:document.forms[0].submit()">
  <form method="post" action="eudiw://start.wallet.example.org">
    <input type="hidden" name="response"
     value="eyJhbGciOiJSUzI1....."/>
    </form>
   </body>
  </html>

Where the decoded response JWT is as follows:

{
  "iss": "pid-provider.example.org",
  "code": "SplxlOBeZQQYbYS6WxSbIA",
  "state": "fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd",
  "iat": 1516239022,
  "exp": 1516240022
}

The text was updated successfully, but these errors were encountered:

TakahikoKawasaki · 2023-09-28T00:48:31Z

What should be fixed is react-native, not the OAuth flow.
"Reopening the app at best" is a matter of the app. The app should extract the query parameters from the URL. Other apps do it.
JARM is irrelevant. The essence of the proposal is changing 302 Found to 200 OK. The proposal completely overturns the redirect-based OAuth protocol.
response_mode=form_post (OAuth 2.0 Form Post Response Mode) returns 200 OK + HTML. It may be possible to write a workaround with the mechanism. FYI: response_mode=form_post.jwt is form_post + JARM.
response_mode=fragment (OAuth 2.0 Multiple Response Type Encoding Practices) or response_mode=fragment.jwt may be usable for your workaround, depending on the design of your app.

grausof · 2023-09-28T07:03:25Z

@TakahikoKawasaki

You say

"Reopening the app at best" is a matter of the app. The app should extract the query parameters from the URL. Other apps do it.

I agree with this, but for this very reason I don't see the point of using a 302 redirect if what the app needs to do is extract the parameters and not follow the redirect. For this reason my proposal was to avoid using a useless redirect (which only applies to the web) and to have something more structured and understandable for the world of apps.

Said that, it would be fine to also use form_post and then have something like this as a response:

HTTP/1.1 200 OK
  Content-Type: text/html;charset=UTF-8
  Cache-Control: no-cache, no-store
  Pragma: no-cache

  <html>
   <head><title>PID Authorization</title></head>
   <body onload="javascript:document.forms[0].submit()">
    <form method="post" action="eudiw://start.wallet.example.org">
      <input type="hidden" name="code"
       value="SplxlOBeZQQYbYS6WxSbIA"/>
      <input type="hidden" name="state"
       value="fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd"/>
      <input type="hidden" name="iss"
       value="https://pid-provider.example.org/"/>
    </form>
   </body>
  </html>

or as you suggest a response_mode=form_post.jwt.

peppelinux · 2023-09-28T11:08:52Z

We agreed on using https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html and response_mode=form_post.jwt would be the way to go in the milestone 0.6.0 if confirmed here

grausof · 2023-09-28T11:12:51Z

OK @peppelinux I changed the original post to what the response should be.

tlodderstedt · 2023-09-28T16:51:13Z

You can use form post and JARM as this are legitimate options. Just be aware making this an interoperable solution would any issuer to support it.
Out of curiosity: why is a form post a better solution than parsing a URL?

peppelinux · 2023-09-28T23:49:00Z

The problem Is not parsing the URL query parameter but the way JS (as happens in the user agents with Ajax) automatically follow the 302 url found, making It tricky to intercept the http status code and then stop the flow for doing parsing

tlodderstedt · 2023-09-29T09:06:31Z

Would be interesting to learn how other JS implementers cope with that, I mean redirects are nothing new. I reached out to some folks in the community to get their feedback.

grausof · 2023-09-29T10:20:00Z

@tlodderstedt In javascript it is possible to block redirects and therefore obtain the URL to parse. This can be done by setting the redirect parameter to manual.

The problem is on react-native (in our specific case) where manual redirect is not supported therefore it is not possible to block the follow of the redirect to obtain the URL to be parsed.
The same also happens when using other libraries such as axios (axios/axios#674 (comment)) as the native browser does not allow blocking the redirect.

peppelinux · 2023-09-29T23:13:16Z

AFAIK the technical strategy is Always possible, for example in the user agents we would be forced to implement approaches that may vary over time. It was a convention before the come of the fetch api.

The scope of this issue Is to explore a way to give/get to/from the specs the most convenient way to keep easy the implementations

Any comments will be appreciated, thx!

peppelinux · 2023-10-02T08:29:59Z

For interop requirements I think that this feature should be published within the Wallet Instance Attestation, with the member name response_modes_supportedm, according to RFC8414, this has a formal posture for the presentation phase, where the Wallet instance acts like an AS, while for the issuance phase it would be a compromise.

response_modes_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0
"response_mode" values that this authorization server supports, as
specified in "OAuth 2.0 Multiple Response Type Encoding Practices"
[OAuth.Responses]. If omitted, the default is "["query",
"fragment"]". The response mode value "form_post" is also defined
in "OAuth 2.0 Form Post Response Mode" [OAuth.Post].

grausof · 2023-10-03T09:21:37Z

@peppelinux #136 resolves your comment

peppelinux · 2023-10-23T12:35:56Z

Even if technically by pagopa/io-react-native-wallet#47 this issue represent a critical issue for the interoperability with other wallet solutions and RPs

for this reason this issue is kept open

stedcl · 2024-06-06T04:57:50Z

I suggest to specifyng a claim "response_mode" inside the request object of the PAR Request, according to OAuth 2.0 Multiple Response Type Encoding Practices. It's useful to replicate for the PAR Request what the spec openid-connect-core-1_0-errata2.html#AuthRequest suggests for the OAuth 2.0 Authorization Request.
With this claim, the Wallet Instance inform the Authorization Server of the mechanism to be used for returning Authorization Response parameters from the Authorization Endpoint (mechanisms supported MUST to be specified into the Entity Configuration of the Authorization Server).

Usable mechanisms:

query: In this mode, Authorization Response parameters are encoded in the query string added to the redirect_uri when redirecting back to the Client.
form_post: In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format. The action attribute of the form MUST be the Client's Redirection URI. The method of the form attribute MUST be POST;
form_post.jwt: In this mode, Authorization Response parameters are specified into a JWT encoded as HTML form value that is auto-submitted in the User Agent, and thus is transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format. The action attribute of the form MUST be the Client's Redirection URI. The method of the form attribute MUST be POST (openid.net/specs/oauth-v2-jarm.html#section-2.3.3)

The claim "response_modes_supported" inside the Wallet Instance Attestation, according to RFC8414, must to contains a list of OAuth2 response_mode values supported by the Wallet Instance when the Wallet Instance works as an authorization server.

* fix issue #132 * fix: non-normative example PAR with response_mode * fix: issue #311

grausof · 2024-06-17T10:05:16Z

@stedcl done in #314

grausof added enhancement Something improving existing features standardization Topics related to the standardization process in IETF/OIDF labels Sep 27, 2023

grausof assigned peppelinux and fmarino-ipzs Sep 27, 2023

peppelinux changed the title ~~Authorization request - 302 redirect response problem~~ Authorization request - 302 redirect response Sep 27, 2023

peppelinux added the issuance label Sep 27, 2023

peppelinux added this to EUDI Wallet IT Technical Specifications Sep 27, 2023

peppelinux moved this to Todo in EUDI Wallet IT Technical Specifications Sep 27, 2023

peppelinux added this to the 0.6.0 milestone Sep 27, 2023

peppelinux moved this from Todo to In Progress in EUDI Wallet IT Technical Specifications Sep 27, 2023

grausof mentioned this issue Oct 3, 2023

feat!: Add response_modes_supported to Wallet Instance Attestation #136

Merged

grausof mentioned this issue Oct 3, 2023

feat!: [SIW-545] Adds the authorization endpoint for PID issuing pagopa/io-react-native-wallet#47

Merged

2 tasks

peppelinux added the question Further information is requested label Oct 23, 2023

peppelinux moved this from In Progress to Backlog in EUDI Wallet IT Technical Specifications Oct 23, 2023

peppelinux modified the milestones: 0.6.0, 0.7.0 Oct 23, 2023

peppelinux modified the milestones: 0.7.0, 0.8.0 Mar 6, 2024

peppelinux moved this from Backlog to Todo in EUDI Wallet IT Technical Specifications Mar 6, 2024

peppelinux modified the milestones: 0.8.0, 0.9.0 Mar 6, 2024

fventola-ipzs modified the milestones: 0.9.0, 0.7.1 Jun 5, 2024

fmarino-ipzs added a commit that referenced this issue Jun 12, 2024

fix issue #132

038fc27

fmarino-ipzs mentioned this issue Jun 12, 2024

Authorization Response Mode #314

Merged

5 tasks

peppelinux linked a pull request Jun 12, 2024 that will close this issue

Authorization Response Mode #314

Merged

5 tasks

peppelinux moved this from Todo to In Progress in EUDI Wallet IT Technical Specifications Jun 12, 2024

peppelinux pushed a commit that referenced this issue Jun 17, 2024

Authorization Response Mode (#314)

4793c99

* fix issue #132 * fix: non-normative example PAR with response_mode * fix: issue #311

peppelinux closed this as completed in #314 Jun 17, 2024

github-project-automation bot moved this from In Progress to Done in EUDI Wallet IT Technical Specifications Jun 17, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Authorization request - 302 redirect response #132

Authorization request - 302 redirect response #132

grausof commented Sep 27, 2023 •

edited

Loading

TakahikoKawasaki commented Sep 28, 2023

grausof commented Sep 28, 2023

peppelinux commented Sep 28, 2023

grausof commented Sep 28, 2023 •

edited

Loading

tlodderstedt commented Sep 28, 2023

peppelinux commented Sep 28, 2023

tlodderstedt commented Sep 29, 2023

grausof commented Sep 29, 2023

peppelinux commented Sep 29, 2023 •

edited

Loading

peppelinux commented Oct 2, 2023

grausof commented Oct 3, 2023

peppelinux commented Oct 23, 2023

stedcl commented Jun 6, 2024 •

edited

Loading

grausof commented Jun 17, 2024

Authorization request - 302 redirect response #132

Authorization request - 302 redirect response #132

Comments

grausof commented Sep 27, 2023 • edited Loading

TakahikoKawasaki commented Sep 28, 2023

grausof commented Sep 28, 2023

peppelinux commented Sep 28, 2023

grausof commented Sep 28, 2023 • edited Loading

tlodderstedt commented Sep 28, 2023

peppelinux commented Sep 28, 2023

tlodderstedt commented Sep 29, 2023

grausof commented Sep 29, 2023

peppelinux commented Sep 29, 2023 • edited Loading

peppelinux commented Oct 2, 2023

grausof commented Oct 3, 2023

peppelinux commented Oct 23, 2023

stedcl commented Jun 6, 2024 • edited Loading

grausof commented Jun 17, 2024

grausof commented Sep 27, 2023 •

edited

Loading

grausof commented Sep 28, 2023 •

edited

Loading

peppelinux commented Sep 29, 2023 •

edited

Loading

stedcl commented Jun 6, 2024 •

edited

Loading