AndyButland
commented
1 year ago Thanks for the thoughts @abjerner - I'm off on holiday next week so will only give a quick response to a few specific points here, but in general the roadmap will come from exactly discussions like this. Where do people find gaps when they consider the package for integrations, and can we sensibly find ways to fill them?
It would be great if you could spin some of the specifics off from here into individual issues that we can consider. E.g. "Add support for OAuth 1.0a using Instagram as an example", "Add support for API keys using XXX as an example" etc.
Services have to be manually added to appsettings.json
I was thinking here that if someone prefers code over configuration, they could still use "configuration" but do it in code, via Configure or PostConfigure (see e.g. here). That seemed a reasonable compromise on the decision for whether people prefer configuration in files or code, but if I'm missing something and that's not appropriate, please let me know.
abjerner
Hey
The idea for this package was partially spawned from a chat that I had with @AndyButland and others. The chat was about whether HQ could provide some shared logic, so various package developers wouldn't have to implement somewhat the same code that does the same.
I have a number of packages that integrate with third-party APIs, and I were hoping to use this package, but I see a handful of scenarios that isn't covered by the package. I take it from the version number that the package is still at an early stage, but I'm curious to hear HQ's planned scope of the package - or a roadmap if you will.
I've also highlighted some scenarios that I hope the package will cover:
Encoding requires manual setup Part of my conversation with Andy was about having some shared logic to encode and decode access tokens, API keys etc. This package supports that, but a encryption key has to be manually added to
appsettings.json(see #13).I'm not sure how (of if) this can be done with the new
appsettings.jsonformat (opposed to writing toWeb.config), but adding an auto-generated encryption key would be a big plus.Only supports OAuth 2.0 The package seems to only handle OAuth 2.0 server-side web flows. Are there plans to support other forms of authentication? Most services seems to treat OAuth 2.0 as a replacement for OAuth 1.0a, but IMO it's more an alternative. So while the list of OAuth 1.0a services is getting shorter, any plans to support this?
API keys Some services also only support using an API key, or support multiple authorization flows where an API key might be the easiest approach. For instance with YouTube, our clients typically doesn't need to acces private videos, and as such we set up an API key to be used instead of going through an authorization flow.
Manually entering values The package doesn't support manually entering keys/tokens. Eg. with the API key example described above, it would be useful being able to enter an API key via the UI (for services that support API keys).
Other services support generating access tokens from their respective user areas or developer areas. Eg. Vimeo supports OAuth 2.0 server-side web flow, but also support generating an access token from their developer area. TwentyThree supports something similar, but for OAuth 1.0a.
Will these scenarios be supported through this package as well?
Services have to be manually added to
appsettings.jsonOpposes to be added to the database, or registered through code. Any reason for this? Being able to register an auth service through C# would make setting up a package easier.Being able to do something like
builder.AuthorizedServices.Add<InstagramAuthService>at startup could perhaps be better approach. My implementation of theInstagramAuthServiceclass - and which interfaces it extends - could then help determining the settings currently stored inappsettings.json. The implementation of my service could also help determining whether it supports OAuth 1.0a, OAuth 2.0 or regular API keys (or a combination of these).Doesn't support Instagram long lived tokens Instagram's Basic Display API is kinda the odd duck in the pond. After a successful authorization, you get a short-lived access token (IIRC this lives for an hour or so). To be able to access the API at a later point, you need to exchange to short-lived access token for a long-lived access token. Long-lived access token live for about two months. AFAIK this isn't supported by this package as exchanging an authorization code for a long-lived access token has to be done over two requests.
IIRC both Facebook and Instagram also use a non-standardized approach to refreshing access tokens. I can't remember if I tested this with this package, but I could see some potential issues here.
Only supports one "authentication" per provider This might not be ideal in a multi-tenant setup with multiple sites. Any plans to allow this?
No way to get access token for an authorized service The package allows making requests through
IAuthorizedServiceCaller, which is probably fine in most cases. But for many of the services that we integrate with, we have custom packages that handle the communication with the respective APIs. But as far as I can see, the package doesn't support a away to get the access token so we can use our own packages instead.