When we use PAR, I see some problems: enter image description here

When we redirect user to login page we have to store (while user is on the login page) the same data as contained in request object referenced by request_uri (because the login page must redirect user to authorization endpoint and authorization endpoint must redirect the user back to the redirect_uri, and the earlier used request_uri is expired so it doesn't actually know redirect_uri).

So I have get an idea that we can generate something like opaque login_code before redirection to login page and keep the necessary information in the database. However, this makes many attacks possible (e.g. guessed or swapped login_code). Then we could use login_code as request_uri or exchange login_code for new request_uri to redirect user with this to the authorization endpoint.

Is this a safe solution? Or maybe it can be done differently e.g. just store necessary information in cookies instead of creating login_code?

NOTE: Login page is a piece of the same service where is authorization and PAR endpoint. It's not an external service.

  • What is the difference between login_page and authorization endpoint in your example? Is login_page where user provide credentials and authorization endpoint is where those credentials are validated? I do not know if I follow your flow but suppose you do not need the proposed solution. Commented Oct 14, 2022 at 18:54
  • Login page is an endpoint where upon GET request login form is displayed and where user provide credentials and next logs in. Authorization endpoint is OIDC authorization endpoint which accepts authorization only using PAR (request_uri). This looks like this: User is redirected to authorization endpoint by client, but if user is not authenticated then he is redirected to login page and then after successful login he is redirected back to authorization endpoint. But problem is that after successful login we don't have valid request_uri.
    – Szyszka947
    Commented Oct 14, 2022 at 19:12

1 Answer 1


In my opinion your design is not correct. Check below.

Push Authorization Request is just a new option of sending authorization request (parameters which initiate authorization flow) which uses request object with POST request, instead of sending parameters in Query String with GET request.

The flow works like this:

  1. Client create request object with initial data for authorization (client_id, redirect_uri, state etc.) and POST it to "PAR_authorization_request_endpoint", for example /authorize/par
  2. In response your client is getting request_uri=URN...
  3. Client is sending the request_uri to authorization_endpoint with client_id included, for example: /authorize?client_id=AAA&request_uri=URN...,
  4. In response authorization server renders the login_page (here I mean redirection in browser to login_page) where user can provide its credentials and submit those to authorization service
  5. Authorization service validates credentials and if successful redirects to redirect_uri which was send in 1. as part of the request object, with data according to flow that was used (i.e. code if authorization_code flow was used).

You do not need to remember the request_uri here. In my opinion you need to redesign your authorization services like it was described.

Please check also RFC and authorization providers explanation: here or here

  • So I just need to store redirect_uri while redirecting to the login page? Should I do this with a query string or a cookie? But I see one problem here: now login page is resposible for generating code for response. Shouldn't that be role of authorization endpoint? For this reason, after successfully logging in the user, I wanted to redirect him back to the authorization endpoint (that login page won't be responsible for generating code). Is it really a problem that the login page and authorization endpoint can generate code?
    – Szyszka947
    Commented Oct 14, 2022 at 20:26
  • 1
    If you say that login_page is responsible for generating "code" it would mean your login_page IS THE authorization_endpoint. Redirect_uri is the URI of your client where browser will be redirected to after successful authentication (with "code"). You do not need to store that anywhere. You just send it to the PAR_authorization_request_endpoint. 1/2 Commented Oct 14, 2022 at 20:46
  • 1
    All solutions of authorization services I was using, considered the authorization_endpoint the one where you were sending the authorization request (either Query String or request_uri) and which was redirecting to login form. Login form was sending user creds to some endpoint (can be the same) which was validating creds and if OK, redirecting with code to redirect_uri. 2/2 Commented Oct 14, 2022 at 20:46
  • 1
    The whole process of authentication/authorization you start with sending the authorization request (see point 1. from my answer) to authorization_endpoint. This endpoint is redirecting you to login page, which then sends the creds to some endpoint which validates the creds. Remember that either authorization_endpoint, login_page and endpoint which validates creds are all part of Authorization Service (AS). When you initiate authentication process, AS is creating a session to identify a requestor during the authentication process. Commented Oct 14, 2022 at 21:45
  • 1
    Let us continue this discussion in chat. Commented Oct 15, 2022 at 9:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .