[Openid-specs-fapi] Questions / comments on FAPI 2.0 Baseline Profile

Thu Jun 13 03:18:45 UTC 2024

Hi Joseph,

It was very helpful, thank you!
I was afraid that the "threat models" are different between server
client and app client models, but I think it was fully discussed in
the sections you mentioned.
Unless implementers understand those and implement accordingly, it is
rather safer for them to (mis)interpret that native client is a public
client IMHO.

Anyway, I think it is yet another reason why OAuth2.1 emerged, and I'm
hoping it will bring us to the right(er) direction.

Thanks again!

Kosuke

On Thu, Jun 13, 2024 at 12:19 AM Joseph Heenan <joseph at authlete.com> wrote:
>
> Hi Kosuka
>
> I’d agreed that it’s slightly messy.
>
> However ’native app’ is not quite a defined term in OAuth 2.0 (it’s actually the name of a ‘client profile’ as per https://www.rfc-editor.org/rfc/rfc6749#section-2.1 ); in OAuth 2.0 the term is essentially restricted to a native app that is a public client, rather than saying that a native app (in the more general sense) can only be a public client.
>
> https://www.rfc-editor.org/rfc/rfc6749#section-2.1 also states that a confidential client can be any that is 'capable of maintaining the confidentiality of their credentials’.
>
> e.g. https://datatracker.ietf.org/doc/html/rfc6819#section-3.7 makes it clear that this case is a confidential client, albeit it notes "Achieving this level for native applications is much more difficult” - which was very true when written 12 years ago, but a little less true today (iOS’s Secure Enclave was announced 11 years ago and another key change to enable this, device/app attestations, is even more recent).
>
> https://datatracker.ietf.org/doc/html/rfc8252#section-8.5 similarly clarifies that it’s only shared secrets that are problematic, not native apps themselves.
>
> I don’t know if that helps? If you have an idea on what we could do to improve to situations please let us know!
>
> Thanks
>
> Joseph
>
> On 12 Jun 2024, at 15:29, Kosuke Koiwai via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>
> Hi FAPIers,
>
> Sorry for digging out an old thread, but is there a place other than
> the OAuth2.1 draft where it is clearly stated that "a native app that
> can securely manage private keys can be a confidential client"?
> Many websites still say native apps are public clients. The only other
> place I could find where a confidential native app was mentioned was:
> https://bitbucket.org/openid/fapi/src/master/Financial_API_Implementation_And_Deployment_Advice.md
>
> Per-installation confidential client
> On platforms where sufficiently secure storage of secrets is available, each instance of an application can register it's own secrets with the server. For example:
> iOS Secure Enclave accessed via the kSecAttrTokenIDSecureEnclave flag
> Android's hardware-back keystore accessed via the android.security.keystore API
> The method used to protect the registration endpoint at the authorization server is outside of the scope of the FAPI specification.
>
>
> Actually, OAuth2.0 clearly states that "a native application is a
> public client installed and executed on the device used by the
> resource owner."
> So as long as FAPI2.0 is a profile of OAuth2.0, I'm afraid that our
> position might not be able to be against the idea that a native app is
> a public client.
>
> Kosuke
>
>
> On Mon, Mar 16, 2020 at 3:10 AM Ralph Bragg via Openid-specs-fapi
> <openid-specs-fapi at lists.openid.net> wrote:
>
>
> HI Michael,
>
>
>
> On 1; Public client support is removed, the security issues are well documented with public clients however  this does not mean native app clients are not supported. A native app, particularly on modern smart phones, can and should be implemented as private clients.
>
>
>
> Cheers,
>
> RB
>
>
>
> From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of "Peck, Michael A via Openid-specs-fapi" <openid-specs-fapi at lists.openid.net>
> Reply to: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
> Date: Sunday, 15 March 2020 at 18:04
> To: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
> Cc: "Peck, Michael A" <mpeck at mitre.org>
> Subject: [Openid-specs-fapi] Questions / comments on FAPI 2.0 Baseline Profile
>
>
>
> Hi all,
>
>
>
> I have some questions and comments on the current draft of the FAPI 2.0 Baseline Profile (https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md).
>
>
>
> I’m new here, please let me know if I’m misunderstanding something / if these are more appropriate for the issue tracker instead.
>
>
>
> 1.
>
> The profile appears to not allow public clients. Is that intentional? If so, why not – are native app clients not an intended use case?
>
> (Requirements for Authorization Servers #9 states “MUST authenticate clients” and Requirements for Clients #4 states “MUST support client authentication”, which to me preclude public clients.)
>
>
>
> 2.
>
> The profile requires that resource servers verify the revocation status of access tokens (Requirements for Resource Servers #3). Is this practical?
>
>
>
> Requirements for Authorization Servers #15 states “MUST provide a means for resource servers to verify the validity, integrity, sender-constraining, scope…expiration and revocation status of an access token, either by providing an introspection endpoint…by exposing signature verification keys, or by deployment-specific means.”
>
> I would think the revocation status requirement would force the resource server to connect back to the authorization server (to its introspection endpoint or other “deployment-specific means”) every time an access token is presented, which might not always be feasible?
>
> I don’t see how “exposing signature verification keys” would suffice to meet the revocation status verification requirement?
>
>
>
> Another option might be to weaken the MUST for verifying revocation status of access tokens, add a requirement that the AS limit the lifetime of access tokens, and ensure that the AS check the revocation status of refresh tokens when they are presented? That would enable resource servers to more safely accept access tokens without having to reach back to the AS every time to check revocation status?
>
>
>
> 3.
>
> Requirements for Resource Servers #6 states “MUST identify the associated entity to the access token”.
>
> What does “associated entity” mean? Does it mean the subject of the access token?
>
>
>
> 4.
>
> Cryptography and Secrets #3 states “authorization servers MUST provide a client secret that adheres to the requirements…if a symmetric key is used.”
>
> I think this statement should be removed since the profile does not allow a symmetric key / client secret to be used for client authentication?
>
>
>
> Thanks,
>
> Mike
>
>
>
> Michael Peck
>
> The MITRE Corporation
>
> +1-410-272-5959
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
>