Track FAPI compliant RP libraries
Issue #433
new
It would be good to encourage active OpenID Connect certified RP libraries to add FAPI support and potentially get certified.
We recommend that RPs uses certified libraries, but they don’t exist in many languages. At the moment I am only aware of libraries for Java and Node.JS (https://openid.net/developers/certified/)
Potential projects that we can work with:
Python - https://github.com/IdentityPython/JWTConnect-Python-OidcRP
Go - https://github.com/caos/oidc
C# - https://github.com/IdentityModel/IdentityModel.OidcClient
PHP ?
Ruby ?
Comments (11)
-
-
From a mobile app perspective, is there value in adding FAPI support into the AppAuth iOS and Android libraries? Are there clear use cases where mobile apps need to make FAPI related calls?
-
For iOS AppAuth, it’s pretty much intractable a problem without forking the library, as there’s various policies (e.g. supporting a very wide range of iOS versions and not to pull in third party libraries) that make it very hard to support FAPI. It was discussed a bit here https://github.com/openid/AppAuth-iOS/issues/290 though this was a while ago so I don’t know if much has changed.
-
reporter
This is a PHP OIDC client: https://github.com/steverhoades/oauth2-openid-connect-client
-
reporter
-
https://openid.net/certification/#RPs
has more options.
I maintain the IdentityModel.OidcClient library for C# -
- Does the library support OpenID Connect Discovery?
yes
- Does the library support mTLS?
yes
- For our signing service: Is there support for PAR (and, ideally, RAR)?
no. but as soon as PAR is added to IdentityServer (early 2022) - I will also add it to our client lib.
-
I propose that we discuss this topic at the OAuth Security Workshop: https://barcamps.eu/osw2021/sessions
-
Let’s try to collect the libraries in a sheet: https://docs.google.com/spreadsheets/d/1vO0FJY9FDeq3Z5CPkbfM26ZSBHuRZpjclPCYkRreAvU/edit?usp=sharing
-
Will work on feature support and certification of https://github.com/IdentityPython/JWTConnect-Python-OidcRP in September.
All of the features mention in the spreadsheet are there except for JARM.
-
@Joseph Heenan In not https://github.com/openid/AppAuth-iOS/issues/290 saying that it can now support the hybrid flow so it should be able to do FAPI 1.0 Advanced? (Although, IMHO, FAPI should happen on the server-side so I am not sure how relevant it is.)
-
@Nat Sakimura After the changes mentioned in that ticket it is now “possible” to get AppAuth to do FAPI, but almost none of the functionality is built in - e.g. if you want to do private_key_jwt with appauth you need to select your own JWT/JWS library, produce the client assertion by hand and then manually add it to the token endpoint call.
So you can do it, and as per that ticket I’ve done it, but it’s far from straightforward.
- Log in to comment
At yes.com, I often discuss with customers the options they have for integrating with our (FAPI 2) ecosystem. I usually tell them to check a library for three things:
These three give a good indication whether a library can be used with almost no extra work or if a library is so far behind FAPI that the difference between using the library and rolling your own implementation is not that big. Unfortunately, for the majority of languages and frameworks, you end up in the latter category. And while I would never recommend starting from scratch, I do understand that customers go that way.
With a few exceptions, OAuth/OIDC support for many libraries means supporting Facebook, Google and the likes. FAPI (1 or 2) Certification could be a vehicle to get these libraries to extend their feature set and to adopt current security best practices.
I wonder if this is something we could discuss in the OAuth working group as well? It could benefit the adoption of OAuth 2.1 as well.
(It’s also worth repeating the message to developers that rolling your own OAuth/OIDC implementation is generally not a good idea, but that only works if there actually are libraries supporting all the relevant features.)