[BUG] Auth types/identity provider settings cannot be configured per organization

[shurwit]

Describe the bug
Currently the identity provider configurations are specified for each app type and the identity providers are associated with an auth type which is specific to an organization (eg. illinois_oidc), however this will not work well for multi-tenant applications that would then need to know which auth type to use for each app org. For example, if we have a multi-tenant client where each tenant has an OIDC provider, the client would need to know that based on the selected organization we should use illinois_oidc, or example_university_oidc... etc.

Expected behavior
Auth types should be associated only with a programmatic authentication implementation (eg. oidc, phone, email... etc). With this change, the auth type database collection does not need to exist since this data is all defined by a specific programmatic implementation which cannot change without updating the code.

Any configurations needed for each auth type should be defined within the app/org on both an app/org and the app type/org basis. For example, the current identity_provider_settings should be defined on the app/org basis (consistent across all app types), while the current identity provider configs need to be different for each app type/organization. This change would make it quite simple to manage multi-tenancy, as the client just needs to specify app type identifier, org, and auth type and the system can use the app org to easily determine the identity provider or external service to use to authenticate the user.

Note that we should not specify different auth types for each app type, as this would result in some users being unable to login on some platforms. For example, a user that signs up with email would not be able to sign in on web without creating a new account.

Example:
App/Org document:

{
	...
	"auth_types": {
		"oidc": {
			"configs": {
				"user_identifier_field": "<id claim name>",
				"first_name_field": "given_name",
				"middle_name_field": "middle_name",
				"last_name_field": "family_name",
				"email_field": "email",
				"roles_field": "<role claim name>",
				"groups_field": "",
				"user_specific_fields": [
					"preferred_username"
				],
				"roles": {
					"<role>": "2000"
				},
				"groups": null
			},
			"app_type_configs": {
				"100": {
					"host": "<host>",
					"token_url": "<token url>",
					"scopes": "<scopes>",
					"use_refresh": true,
					"use_pkce": false,
					"client_id": "<client id>",
					"client_secret": "<client secret>",
					"authorize_claims": "<authorize claims>",
					"required_population": "",
					"populations": {}
				}
			}
		},
		"phone": {
			"configs": {
				"provider": "twilio",
			}
		},
		"email": {
			"configs": {
				"verify_email": true,
				"verify_wait_time": 30,
				"verify_expiry": 24,
			}
                },
		"anonymous": {}
	},
       <remove identity_providers_settings>,
       <remove supported_auth_types>,
	...
}

[petyos]

Hi @shurwit ,

as general I am ok with these changes. The only concern I have is that supporting different auth types for the different app types was a feature. We could want for example the web app to allow people to authenticate only via email but the mobile app to allow email and phone. I agree that this is very rarely case and we could live without it.

[shurwit]

Hi @shurwit ,

as general I am ok with these changes. The only concern I have is that supporting different auth types for the different app types was a feature. We could want for example the web app to allow people to authenticate only via email but the mobile app to allow email and phone. I agree that this is very rarely case and we could live without it.

Thanks for the feedback @petyos!

I do see what you mean about restricting auth types for some platforms, however I think this would usually result in a lot of confusion as people would expect their account to work across all platforms for the same app.

We'll get started on this when we get a chance and submit a PR for you to review as usual. Thanks again!

[shurwit]

We would also like to make an additional change at the same time to allow the login session policies to be configured for a specific app type and/or auth type. The suggested changes are:

• Add nullable app_type_id, auth_type_id to LoginSessionSettings in app/org
• Update login_session_settings as follows and apply first override that matches

login_session_settings {
	Default LoginSessionSettings
	Overrides []LoginSessionSettings
}

• Make delete session timer more efficient (could probably use a Mongo Query to target sessions to be deleted) (will be addressed by [FEATURE] Improve expired session deletion efficiency #647)