Re: [OAUTH-WG] Unified Singular Protocol Flow for OAuth (USPFO) Ecosystem

["Oliva Fernandez, Jorge" <[e-mail]>]

Hi Jaimandeep,

Just about the last point:

"Remote assertion server" is not a new concept and is already widely used to prevent client impersonation in mobile apps. You may like to refer to Aaron's blog in this regard here<https://developer.okta.com/blog/2022/06/01/oauth-public-client-identity#:~:text=What%20is%20OAuth%20client%20impersonation,not%20granted%20to%20other%20clients.>. Our paper proposes entrusting the responsibility of verifying the client's integrity to a third-party endpoint in which the developer holds a stake. Such an endpoint is better positioned to conduct an integrity check and prevent client impersonation than relying solely on basic authentication, which is prone to leakages of client_secret.

I have read Aaron's blog and could not locate any references to a "Remote Assertion Server" I am well acquainted with the issue of using "secrets" in public clients, this issue has been present since the inception of OAuth 2.0, and many individuals misunderstand that mobile applications or single-page web applications (SPA) are public clients, attempting to utilize them as confidential clients by employing `client_secret` (or any other authentication method such as `private_key_jwt`) has led to a significant problem of client impersonation since a browser or mobile application cannot securely store a "secret." In the event that a hacker obtains this secret, they can impersonate the OAuth client by using it.
Aaron proposes a solution for this problem, as described in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps, called BFF (Backend for Frontend), BFF is a proxy solution, where the public client (SPA or mobile application) never obtains the credentials to communicate with the authentication server (i.e., it never receives the client_secret), all the communications with the authentication server is perform by the BFF server, this is how the used client in OAuth can remain confidential since the BFF is a server that can store secrets securely.
Of course, there is still the issue of "How we implement a trust connection between the browser/app and the BFF?" however, in this case, one can use something as simple as a cookie to maintain a session, if an attacker were to steal the cookie, they could impersonate the customer's session and make requests to the resource servers using the BFF as a proxy, but they would never obtain access to the `client_secret`, this is why this solution addresses the client impersonation attack.
However, this is not the same scenario as for the "Remote Assertion Server."aAs far as I understand, this server communicates directly with the browser/mobile app and returns an assertion that serves as the credentials to communicate with the authentication server, therefore, if a hacker steal this assertion or is able to communicate with the assertion server by impersonating the client, then a client impersonation attack could occur. While using an assertion is better than using a client_secret, since the assertion will expire, if an attacker intercepts the assertion with a MITM (man-in-the-middle) attack, it can only be used for a limited amount of time, however, the problem with the "Remote Assertion Server" lies in not stealing the assertion, but rather in stealing whatever is used to entrust the communication between the public client (browser/mobile app) and the "Remote Assertion Server." regardless of what is planned to be used, as the public client it is not secure to store "secrets" and this means that an attacker could steal this information and communicate directly with the "Remote Assertion Server", this cause the attacker to generate as many assertions as they require, this is precisely a client impersonation attack…. therefore, with the "Remote Assertion Server," unless a magical solution is proposed to ensure the identity of a public client, the issue is merely shifted from the client-OAuth server to the client-Remote Assertion Server, which is the same scenario.

Best Regards.

From: Jaimandeep Singh <jaimandeep.phdcs21=[e-mail]>
Date: Sunday, 26 February 2023 at 17:05
To: "Oliva Fernandez, Jorge" <[e-mail]>
Cc: oauth <[e-mail]>
Subject: [EXT]Re: [OAUTH-WG] Unified Singular Protocol Flow for OAuth (USPFO) Ecosystem

CAUTION: This message is from an EXTERNAL sender – be vigilant, particularly with links and attachments. If you suspect it, report it immediately using the phishing button.
Dear Jorge,

Thank you for taking the time and making the efforts to review the paper and offer valuable feedback and suggestions. Your inputs are greatly appreciated and we will definitely consider incorporating your suggestions in our revised or future work. In order to offer a diverse perspective and stimulate further interest in the topic, we have presented some of our thoughts on your suggestions below.

It appears that the paper completely disregards OIDC and all the other features introduced by the OIDC organization. Is this an intentional omission? If so, what is the reason for excluding them?

The paper did not intend to neglect OIDC or other features introduced by OIDC. Rather, it primarily focuses on presenting the Unified Flow for OAuth 2.0, which serves as a binding agent for the latest internet draft features being discussed and addressing common vulnerabilities. Nonetheless, we recognize the significance of OIDC and related features, and we intend to incorporate them in our future/revised work.

I don't understand the statement "Merging of authorization code grant and the implicit grant." The diagram shown in Figure 1 is actually an Authorization Code Grant, whereas the Implicit Grant, by definition, involves obtaining an access token without an intermediate code exchange step. Therefore, it is not possible to merge both grants, as the Implicit Grant is essentially the opposite of the Authorization Code Grant. I do not understand this assertion.

OAuth 2.1, which is currently under the internet draft stage, recommends deprecating the implicit flow. You can refer to the link here <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07#section-10.1> for more information on this. The paper is in line with this recommendation and advocates for more secure flows like the authorization code flow.

 In Section 5.5 ("Authorization Request"), it is stated that "it can initiate a POST authorization request with the client assertion claim as defined in OAuth 2.0 Pushed Authorization Requests (PAR) RFC 9126 Lodderstedt et al. (2021)." However, in the example and flow described in Figure 1, it does not appear that the PAR specification is being used. When using PAR, the response to your PAR request is a request_uri that should be sent to the Auth server in a normal Authorization request. This is not described anywhere, so it is unclear why PAR is mentioned here. It seems more like a normal Authorization request using POST?

The mention of PAR was only to refer to the fact that POST is a preferred way of initiating the authorization code grant flow. You are correct in stating that the PAR specification is not used.

Additionally, I noticed that some security features that are commonly used to enhance the security of OAuth are not mentioned in the paper. For instance, the use of JSON Authorization Response Mode (JARM) specified in the OpenID Financial-grade API (FAPI) specification, which returns a signed JWT as the response of the Authorization request. JARM helps prevent Code Replay and Mix-Up attacks and is becoming increasingly popular in the OAuth community as a security enhancement.

While the terminology of JSON Authorization Response Mode (JARM) has not been used explicitly, the features of JARM are already covered in the paper. We will incorporate the same in revision / future work.

And finally what I don't understand is why the use of a remote assertion server is considered more secure.

"Remote assertion server" is not a new concept and is already widely used to prevent client impersonation in mobile apps. You may like to refer to Aaron's blog in this regard here<https://developer.okta.com/blog/2022/06/01/oauth-public-client-identity#:~:text=What%20is%20OAuth%20client%20impersonation,not%20granted%20to%20other%20clients.>. Our paper proposes entrusting the responsibility of verifying the client's integrity to a third-party endpoint in which the developer holds a stake. Such an endpoint is better positioned to conduct an integrity check and prevent client impersonation than relying solely on basic authentication, which is prone to leakages of client_secret.

Kind Regards
Jaimandeep Singh


On Fri, Feb 24, 2023 at 3:37 PM Oliva Fernandez, Jorge <Jorge.OlivaFernandez=[e-mail]<mailto:[e-mail]>> wrote:
Hi Jaimandeep,

I have read the paper and have some comments/suggestions, it is not an exhaustive review because I had no time to deeply study everything but hope some of my points can help you:


  1.  It appears that the paper completely disregards OIDC and all the other features introduced by the OIDC organization. Is this an intentional omission? If so, what is the reason for excluding them?
  2.  Upon reading the paper, it seems to me that its purpose is to serve as a "Security Profile" (a specification built on top of OAuth that outlines the requirements needed to achieve a certain level of security) Is this the intended purpose of the paper? Additionally, have you compared your recommendations with those in the Financial-grade API (FAPI) specification? It appears that your proposal is quite similar to what FAPI and Open Banking were attempting to define a few years ago.
  3.  Regarding OIDC and FAPI, I notice that some of the features proposed in the USPFO have already been suggested by OIDC/FAPI:

     *   "Eliminating use of client_secret: One of the major features of USPFO is to eliminate the use of the client_secret". -> The use of the client_secret is only for confidential clients, meaning that it is typically used for server-to-server communication. While this makes the MITM attack more complicated, there are alternative solutions proposed by OIDC in section 9, specifically the private_key_jwt method, which uses a private key that is kept safe in the client and is never sent to the Authorization Server to mitigate this issue. Additionally, there is a MTLS auth method proposed in https://www.rfc-editor.org/rfc/rfc8705.txt that is recommended by FAPI as an authentication method and can also address this problem.
     *   "Introducing assertion_verification_uri field" -> In OIDC, there is already a mechanism in place to allow Clients to be informed about public keys that can be rotated using the `jwks_uri` parameter or fixed using the `jwks` parameter. These parameters are defined in https://www.rfc-editor.org/rfc/rfc7591.html and have already been registered in IANA.
     *   Regarding the statement "Authorization Code Grant: This grant type is used by confidential clients such as server-side web applications." that is not entirely accurate. The Authorization Code Grant can also be used, and is even recommended, for public clients. For example, in the case of a Native App, which is always considered a public client, the recommendation is to always use an Authorization Code Grant (as referenced in https://www.rfc-editor.org/rfc/rfc8252). This grant type is also recommended for SPAs or any other public client, so it is incorrect to equate "Authorization Code Grant" with "confidential client."

  1.  I don't understand the statement "Merging of authorization code grant and the implicit grant." The diagram shown in Figure 1 is actually an Authorization Code Grant, whereas the Implicit Grant, by definition, involves obtaining an access token without an intermediate code exchange step. Therefore, it is not possible to merge both grants, as the Implicit Grant is essentially the opposite of the Authorization Code Grant. I do not understand this assertion.
  2.  In Section 5.5 ("Authorization Request"), it is stated that "it can initiate a POST authorization request with the client assertion claim as defined in OAuth 2.0 Pushed Authorization Requests (PAR) RFC 9126 Lodderstedt et al. (2021)." However, in the example and flow described in Figure 1, it does not appear that the PAR specification is being used. When using PAR, the response to your PAR request is a request_uri that should be sent to the Auth server in a normal Authorization request. This is not described anywhere, so it is unclear why PAR is mentioned here. It seems more like a normal Authorization request using POST?
  3.  Additionally, I noticed that some security features that are commonly used to enhance the security of OAuth are not mentioned in the paper. For instance, the use of JSON Authorization Response Mode (JARM) specified in the OpenID Financial-grade API (FAPI) specification, which returns a signed JWT as the response of the Authorization request. JARM helps prevent Code Replay and Mix-Up attacks and is becoming increasingly popular in the OAuth community as a security enhancement.
  4.  And finally what I don't understand is why the use of a remote assertion server is considered more secure. I understand that this server can keep a private key safe, but this solution is only as secure as the communication between the client and the remote assertion server. If you cannot trust that a client can store sensitive information that allows the auth server to identify the client, how can the remote assertion server trust the client to issue an assertion? Essentially, what you're doing is moving the problem from the relationship between the client and the auth server to the relationship between the client and the remote assertion server. When the client is of type 'confidential' and can keep a secret/private key using just the private_key_jwt method or the tls_client_auth, it solves the problem. However, for public clients, you will have exactly the same problem using or not using a remote assertion server. Therefore, for me, using a remote assertion server adds more complexity without increasing the security of the solution.

Best Regards.


From: OAuth <[e-mail]<mailto:[e-mail]>> on behalf of Jaimandeep Singh <jaimandeep.phdcs21=[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 31 January 2023 at 11:21
To: oauth <[e-mail]<mailto:[e-mail]>>
Subject: [EXT][OAUTH-WG] Unified Singular Protocol Flow for OAuth (USPFO) Ecosystem

CAUTION: This message is from an EXTERNAL sender – be vigilant, particularly with links and attachments. If you suspect it, report it immediately using the phishing button.
Dear Rifaat and esteemed community members,

I am pleased to share my research paper on 'Unified Singular Protocol Flow for OAuth (USPFO) Ecosystem'. The highlights of the paper are:

1. Separation of Duties (SoD) - Delegates responsibility of authenticating client applications to a  third-party endpoint, allowing for a more adaptable approach to client application authentication. It also makes it convenient to rotate the security keys.

2. Deprecates use of Basic Authentication - Employing Basic Authentication for clients poses a security risk as client secrets, encoded in Base64, can be exposed through man-in-the-middle attacks or vulnerabilities in the software. These can then be misused for impersonation attacks, potentially granting unauthorized access to restricted scopes which would otherwise not be available to less trustworthy clients.

3. Introduces 'assertion_uri' as an additional parameter to be registered with the authorization server at the time of registration of client application.

4. Built-in support for integrity, authenticity and audience binding.

5. Removes the distinction between confidential and public clients, offering an alternative approach for a cohesive strategy within the OAuth ecosystem.

6. It can be summarized in one equation:
USPFO = assertion_URI + JWS + PAR + PKCE + DPoP - basic_auth

The research paper can be accessed here<https://www.researchgate.net/publication/367557833_Unified_Singular_Protocol_Flow_for_OAuth_USPFO_Ecosystem>.

I'm eager to hear your thoughts and feedback. Please feel free to drop me a message at <[e-mail]<http://nfsu.ac.in>> with your valuable insights.

--
Regards and Best Wishes
Jaimandeep Singh
LinkedIn<http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>


--
Regards and Best Wishes
Jaimandeep Singh
LinkedIn<http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>