[OIDC] Certain IdP fails to work correctly with how AMP implement user lookup
Operating System
Ubuntu ubutn 24.04
AMP Version and Build Date
2.6.1.6 - 20250421.1
AMP Release Stream
Mainline
I confirm that
- [x] I have searched for an existing bug report for this issue.
- [x] I am using the latest available version of AMP.
- [x] my operating system is up-to-date.
Intended Action
Some OIDC providers, like Microsoft Entra, does not provide an OIDC endpoint that contains complete data that's required by AMP to authenticate. Instead, when exchange code is submitted, "access_token" and "id_token" are returned and all the information are on "id_token" instead.
tl;dr using Microsoft Entra as OIDC IdP
Expected Behaviour
AMP attempts to check and parse "id_token" for all the user information before calling "OIDCUserInfoEndpoint" for additional information.
Actual Behaviour
I assume AMP ignores "id_token" and parse all the data from "OIDCUserInfoEndpoint", which leads to
[18:26:08] [System Warning/14] : Returned exception from API call Core/OIDCLogin
[18:26:08] [Core Error/14] : ArgumentNullException
[18:26:08] [Core Error/14] : [0] (ArgumentNullException) : Value cannot be null. (Parameter 'source')
[18:26:08] [Core Error/14] : at Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
at Linq.Enumerable.Where[TSource](IEnumerable`1 source, Func`2 predicate)
at GSMyAdmin.Authentication.InternalAuth.AuthenticateOIDCUser(HttpRequest request, OidcUserInfo info, Nullable`1 serverId)
at GSMyAdmin.WebServer.WebMethods.OIDCLogin(HttpRequest request, String code, String redirect_uri, Nullable`1 serverId)
at GSMyAdmin.WebServer.WebAttributes.InvokeMethod(String MethodName, JObject Data, HttpContext context, IWebSession Session, WebMethodsBase MethodsClass, IPAddress RealIP)
at GSMyAdmin.WebServer.ApiService.InvokeAPI(HttpContext context, IWebSession Session, JObject Data, String RequestModule, String RequestMethod)
Reproduction
N/A
Thanks for providing this bug! This has been discussed on Discord a bit, and I plan to address it before the next release if time allows.
I think having a default behavior if users are not part of the group or if the group attribute are missing would be great: maybe a config to put them in a default group or outright blocking them from accessing the application.
Is there any update on this? I just ran into this problem. Giving me the option for a default group would be fine.
Yikes! I'm sorry this dropped off my radar somehow. Adding it to my shortlist.
Additionally, it would be very useful if we could optionally change the groups claim from groups to roles. This would support the recommended method of permission assignment in Entra for OIDC apps