Consider exposing decryption functionality for SDK

[kwajiehao]

Problem

There are many projects which provide out-of-the-box integration with custom OIDC providers, such as NextAuth. In the event that one of our users is using one of these libraries, the sgID SDK is not useful because the decryption functionality is currently coupled with the userinfo method. This means that the user will need to implement the decryption step themselves, which is tricky and likely to increase integration time

Proposed solution

Expose the decryption functionality as its own method so that RPs using standard libraries to integrate with custom OIDC providers can use them too

[kwajiehao]

I was looking at some custom OIDC providers, and I thought I would log my research here

PassportJS

PassportJS is an authentication middleware for node which can be dropped into any Express app. It includes 500+ strategies and includes a bunch of custom strategies for integrating with OAuth and OIDC identity providers like Google, Facebook, etc.

I looked at the OIDC and OAuth 2.0 strategies, but it seemed pretty opinionated on how authentication is being done - meaning that there is no room for us to insert the sgID decrypt step for the passport strategy to make sense of the data.

NextAuth

NextAuth is an authentication library for the NextJS framework. It also contains custom providers for integrating with major OIDC identity providers like Google or Facebook. There doesn't seem to be a general OAuth 2.0 or OIDC provider library - rather, you would need to write your own custom provider.

Conclusion

Actually, we don't necessary need to expose the decryption step. For now, if we deem it necessary, we can just add custom strategies or providers to libraries like PassportJS and NextAuth.

Closing this issue and replacing it with one that explicitly mentions creating custom providers.

[LoneRifle]

Given we are trying to offer custom strategies for PassportJS now, would it make sense to shard out the decryption step into a package that is either public, or at least, accessible to both sgid-client and the proposed passport-sgid?