[Openid-specs-ab] [Openid-specs-mobile-profile] How to authenticate mobile apps with private-key-jwt without issuing ClientIDs or managing public keys
Michael Schwartz
mike at gluu.org
Thu Feb 13 22:24:04 UTC 2025
Tanaka-san,
Sorry for the delayed response! You asked:
>>> According to the specifications, the steps where the Client Instance
receives the
>>> Client Attestation JWT from the Client Backend are out of scope,
therefore we are
>>> assuming that the Authorization Server can also issue the Client
Attestation JWT.
If the AS issues the Client Attestation JWT, it's basically a "software
statement" or SSA "software statement assertion." :
https://datatracker.ietf.org/doc/html/rfc7591#section-2.3
IMHO, it makes a lot of sense for the AS to also issue SSAs. In some cases,
the federation will issue the SSA (e.g. Open Banking federations).
In Jans Auth Server there is an SSA issuance endpoint:
https://gluu.org/swagger-ui/?url=https://raw.githubusercontent.com/JanssenProject/jans/v1.4.0/jans-auth-server/docs/swagger.yaml#/SSA
The key rotation period for SSA keys is longer than for normal OpenID
Connect keys--giving developers an SSA that expires in two days would be
annoying. Otherwise, SSA endpoint is trivial of course.
Just as an example, below is a screenshot from the Janssen TUI (text ui): a
form that enables an Auth Server admin to create an SSA.
[image: add_ssa-tui-panel.png]
Beyond a domain-specific SSA, I would also want an attestation from the
platform before I allowed dynamic client registration. Google and Apple
both have integrity APIs. If the checksum of the app has changed from the
App Store or the phone is rooted, you don't want to allow that client to
register.
My understanding is that ABC authentication is used for one-time privacy
protecting use cases. It's a wallet use case--your wallet is a client, but
it's only going to interact once--no need for a client entity at the OP.
And an rp_id would be bad for privacy. So the RP just makes an
attestation about its security properties--I have this kind of private key
protection...
If high assurance is needed, enterprises will want a unique client entity
for a mobile app--asymmetric client secrets are better. Operationally,
domains may want to have a short lifetime on dynamically registered client
entities. For example, OOTB dynamic client registration expiration is one
day in Jans Auth Server.
Post-DCR, you can allow the client to proceed with FIDO enrollment for the
human. Or perhaps the person can present a Verifiable Credentia from a
wallet.
One other challenge for mobile developers is how to validate JWTs and map
them to access policies. One of the Gluu devs wrote this article recently:
https://medium.com/@arnab.bdutta/janssen-cedarling-uniffi-bindings-for-native-apps-90f36982c894
.
IMHO, you want the "jti" of all the tokens in the PDP decision log for all
actions, to have a complete cryptographic chain of custody for the person,
workload, and policy store version.
One more resource we wrote a while back that you might find of interest:
https://github.com/JanssenProject/jans/wiki/Mobile-DPoP-FIDO-Authn
This has been implemented as part of the Jans Chip demo:
https://github.com/JanssenProject/jans/tree/main/demos/jans-chip/android
Hope that helps!
- Mike
--------------------------------------
Michael Schwartz
Gluu
Founder/CEO
mike at gluu.org
https://www.linkedin.com/in/nynymike
>
> Message: 2
> Date: Thu, 30 Jan 2025 09:36:39 +0000
> From: "sm-tanaka at kddi.com" <sm-tanaka at kddi.com>
> To: Artifact Binding/Connect Working Group
> <openid-specs-ab at lists.openid.net>,
> "openid-specs-mobile-profile at lists.openid.net"
> <openid-specs-mobile-profile at lists.openid.net>
> Cc: "id-contact at kddi.com" <id-contact at kddi.com>
> Subject: Re: [Openid-specs-ab] [Openid-specs-mobile-profile] How to
> authenticate mobile apps with private-key-jwt without issuing
> ClientIDs or managing public keys
> Message-ID:
> <
> TYWPR01MB12102660486FC9CC580C123F794E92 at TYWPR01MB12102.jpnprd01.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Joseph and Mike,
>
> Thank you for your response.
> Attestation-Based Client Authentication that you recommended can be one of
> the solutions.
>
> According to the specifications, the steps where the Client Instance
> receives the Client Attestation JWT from the Client Backend are out of
> scope,
> therefore we are assuming that the Authorization Server can also issue the
> Client Attestation JWT.
>
> Since all of our applications are developed in-house, we can verify the
> legitimacy of the application based on the results of DeviceCheck and
> SafetyNet on the Authorization Server.
> Therefore, we want to create client attestation on the Authorization
> Server.
>
> Do you think it is acceptable? Also, is there any spec regarding protocols
> to issue the Client Attestation JWT?
>
> Best Regards,
>
> -----Original Message-----
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On
> Behalf Of Michael Schwartz via Openid-specs-ab
> Sent: Tuesday, January 28, 2025 9:15 PM
> To: openid-specs-ab at lists.openid.net
> Cc: Michael Schwartz <mike at gluu.org>
> Subject: Re: [Openid-specs-ab] [Openid-specs-mobile-profile] How to
> authenticate mobile apps with private-key-jwt without issuing ClientIDs or
> managing public keys
>
> Did you look at the IETF draft "ABC Authentication" -- Attestation Based
> Client Authn? This is good for situations where you have a one time authn,
> as is the case with many wallet use cases. Check out the IOH livestream on
> this topic: https://gluu.co/ioh-wiki-81
>
> IMHO, if it's your mobile app, and you expect continued authentications,
> is it really a "vast" amount of client entities? AI captures vast amounts
> of data, but you don't have enough room to store a relatively small amount
> of days about this critical metadata about a trusted device, that you plan
> to interact with for years to come? If security is important enough to you
> that you want to do private key authn, maybe it's worth keeping device
> entity metadata. Also, you can consider expiring client registrations that
> are unused to clean the data periodically.
>
> Mike
>
> On Tue, Jan 28, 2025, 9:56?AM sm-tanaka at kddi.com <mailto:
> sm-tanaka at kddi.com> <sm-tanaka at kddi.com <mailto:sm-tanaka at kddi.com> >
> wrote:
>
>
> Dear Members of AB/Connect Working Group and MODRNA Working Group,
>
>
> I hope this message finds you well.
>
> We are considering implementing client authentication using
> private-key-jwt on mobile apps.
> In this context, we have identified the following challenges:
>
> Since the key pairs generated within devices differ for each
> device,
> we need an identifier on the server side to determine which
> device's public key is being used.
> One potential solution is to issue a Client ID for each device
> during "OpenID Connect Dynamic Client Registration 1.0" process.
> However, this raises the issue of managing a vast number of client
> IDs on the server side.
> To address this issue, I would appreciate your insights on the
> following two questions:
>
> Though the vast number of Client IDs appears to be a challenge
> unique to mobile use cases,
> I believe similar challenges may exist in the context of wallet
> use cases.
> Are there any proposed solutions or discussions about this issue
> in the standard specifications?
>
> We are considering having the server issue the public key
> certificate for the application's public key.
> Thereafter, the application would present both the client
> assertion and the public key certificate,
> allowing the server to validate the client assertion without
> storing the public key.
> We would like to implement this in accordance with standard
> specifications.
> Is there a standard method to embed the public key certificate
> within the JWT of the client assertion?
> I found that RFC 7515, section 4.1.6 proposes a method for
> embedding public key certificate in the JWT header.
> Is RFC 7515 applicable to our use case?, and are there any real
> use cases that utilize RFC 7515?
>
> Thank you for your time and assistance. I look forward to your
> insights on these matters.
>
> Best regards,
> --
> --------------------------------------------------
> Tomorrow, Together KDDI
> ?https://www.kddi.com/corporate/kddi/purpose/
>
>
--
*CONFIDENTIALITY NOTICE*
This message may contain confidential or
legally privileged information.
If you are not the intended recipient,
please immediately advise the sender by reply e-mail that you received this
message, and delete this e-mail from your system.
Thank you for your
cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250213/60782784/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_ssa-tui-panel.png
Type: image/png
Size: 90871 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250213/60782784/attachment-0001.png>
More information about the Openid-specs-ab
mailing list