Allow setting SSO providers to "private"

[david-code]

Description

The goal of this feature will be to let SSO provider applications be set as private applications. This means the following:

• The application name will not show up as an option in the SSO signup page. If the application is the only SSO application, the option to use SSO will not be displayed. Instead the application itself can directly link to the callback URL to initiate SSO signin.
• The application needs also to be removed from API endpoints returning information on SSO providers. These include /me and /environment, but I will also check for others.

I'll add a comment below outlining my proposed solution once I've had a chance to examine the code more closely.

[david-code]

Proposed Solution

• Applications can be given a key "private" in the environment variable settings. For example, I might set the env variable SOCIALACCOUNT_PROVIDERS_openid_connect_SERVERS_0_private=True
  • It doesn't seem like we can modify the SocialApp model itself, which might have been preferable. I will probably just add an extra comment documenting this extra environment variable in the settings file.
• Make a function to return all public SocialApps. This function will just filter all apps that have the key "private" set in their settings.
• Use this functions at the appropriate places

[david-code]

@bufke could you look this over and let me know what you think?

[bufke]

I don't think I like SOCIALACCOUNT_PROVIDERS_openid_connect_SERVERS_0_private because it would be a KPI setting, not a SOCIALACCOUNT setting. Unless we're talking about extending the open_id provider class itself - then maybe it makes sense.

I certainly would prefer to modify SocialApp and never touch django settings ever.

It might make sense to extend SocialApp with a new model via a one-to-one relationship. In the future, that would allow us to add more information such as the oidc server URL (and would thus need to modify the provider as well). Another use case would be associating one social app to one organization to indicate that users of that organization are required to use the social auth provider. The disadvantage would be additional table joins, but joins are cheap. If this extension of SocialApp is not set, then I would expect the default allauth behavior to continue and the social app is considered public.

I think the existence of the Social App extension object would imply that it's private. An alternative would be a boolean to set public/private status. That would allow three states though (unset/true/false). Currently that isn't desirable, it would not be normalized to have unset and false effectively mean the same thing. I suppose a possible case for this would be a valid state where there is a public Social app that is also associated to a specific org. I'm kind of fishing for a use case use.

What do you think @david-code ?

[david-code]

@bufke Yes, that seems like a better solution. I agree with your reasoning for not wanting to put this info in the Django settings.

I think the existence of the Social App extension object would imply that it's private.

I agree with this, I'll implement it this way.

Thanks for the feedback!