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

[Aaron Parecki <[e-mail]>]

Hi Jorge and Jaimandeep,

I wanted to clarify something about my blog post that was referenced.

The proposal that I brought up at the OAuth Security Workshop was to be
able to leverage the specific APIs provided by Apple and Google known as
"App Integrity" as this type of assertion. This is fundamentally different
than simply shipping a secret or certificate in the app, since these APIs
use OS-level primitives to create a signature which also include signing by
keys from Apple and Google. While even they admit it's not a perfect
solution, it's a much stronger signal that an app is legitimate than any
other form of client authentication the app developer could ship on their
own. You could think of Apple and Google's servers as this "Remote
Assertion Server", but it's not really something that the developer
interacts with themselves, since it's all done through OS-level APIs.

Here is the link to the slides I presented at the OAuth Security Workshop
talking about this problem:

https://speakerdeck.com/aaronpk/app-integrity-attestations-for-oauth-oauth-security-workshop-2022?slide=25

You can more or less think of the App Integrity APIs as a "magical
solution" for this, since it's nearly impossible for an attacker to
compromise. On Apple, this generates a key that lives in the secure
enclave, so can't be extracted. Again, it's not perfect, both Apple and
Google have carve-outs in their docs that say this, but it is far better
than anything the developer can do themselves.

---
Aaron Parecki


On Mon, Feb 27, 2023 at 2:29 AM Oliva Fernandez, Jorge
<Jorge.OlivaFernandez=[e-mail]> wrote:

> 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]> 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]> 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>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>