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

[Jaimandeep Singh <[e-mail]>]

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]> 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."
>    4. 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.
>    5. 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?
>    6. 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.
>    7. 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]> on behalf of Jaimandeep Singh
> <jaimandeep.phdcs21=[e-mail]>
> *Date: *Tuesday, 31 January 2023 at 11:21
> *To: *oauth <[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]> 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>