Error when requesing OIDC Authentication with acr_values as request parameter

By: Rui Engana Account Admin 14 Aug 2020 at 3:54 p.m. CDT

12 Responses
Rui Engana gravatar
When passing acr_values in authentication request I can a error message saying "OOPS An unexpected error has occurred at null login.errorSessionInvalidMessage" Authorize URL ``` https://redacted/oxauth/restv1/authorize?client_id=a638ab4a-687d-4e09-85ff-f545bdbc0ef5&scope=openid%20email%20profile%20user_name&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A3005%2Finteraction%2Fcallback%2Fgluu&state=THkbk-KC-yBtx8vBW3nEp%7C0b533aefb7164b845109ea304cc69ba17d162b47e6e38c721f7881baf4676b2e&nonce=0db14d455f006e1b2b09c30a74a21cc4ec4d4c950a252f3e00d3753a00cd761f&acr_values=urn%3Aopenbanking%3Apsd2%3Asca%20urn%3Aopenbanking%3Apsd2%3Aca ``` OpenID Configuration ``` { "request_parameter_supported" : true, "token_revocation_endpoint" : "https://redacted/oxauth/restv1/revoke", "introspection_endpoint" : "https://redacted/oxauth/restv1/introspection", "claims_parameter_supported" : true, "issuer" : "https://redacted", "userinfo_encryption_enc_values_supported" : [ "RSA1_5", "RSA-OAEP", "A128KW", "A256KW" ], "id_token_encryption_enc_values_supported" : [ "A128CBC+HS256", "A256CBC+HS512", "A128GCM", "A256GCM" ], "authorization_endpoint" : "https://redacted/oxauth/restv1/authorize", "service_documentation" : "http://gluu.org/docs", "id_generation_endpoint" : "https://redacted/oxauth/restv1/id", "claims_supported" : [ "street_address", "country", "zoneinfo", "birthdate", "role", "gender", "formatted", "user_name", "phone_mobile_number", "preferred_username", "locale", "inum", "updated_at", "nickname", "email", "website", "email_verified", "profile", "locality", "phone_number_verified", "given_name", "middle_name", "picture", "name", "phone_number", "postal_code", "region", "family_name" ], "scope_to_claims_mapping" : [ { "profile" : [ "name", "family_name", "given_name", "middle_name", "nickname", "preferred_username", "profile", "picture", "website", "gender", "birthdate", "zoneinfo", "locale", "updated_at" ] }, { "openid" : [ ] }, { "https://redacted/oxauth/restv1/uma/scopes/scim_access" : [ ] }, { "permission" : [ "role" ] }, { "super_gluu_ro_session" : [ ] }, { "phone" : [ "phone_number_verified", "phone_number" ] }, { "revoke_session" : [ ] }, { "address" : [ "formatted", "postal_code", "street_address", "locality", "country", "region" ] }, { "clientinfo" : [ "name", "inum" ] }, { "mobile_phone" : [ "phone_mobile_number" ] }, { "email" : [ "email_verified", "email" ] }, { "user_name" : [ "user_name" ] }, { "oxtrust-api-write" : [ ] }, { "oxd" : [ ] }, { "uma_protection" : [ ] }, { "oxtrust-api-read" : [ ] } ], "op_policy_uri" : "http://ox.gluu.org/doku.php?id=oxauth:policy", "token_endpoint_auth_methods_supported" : [ "client_secret_basic", "client_secret_post", "client_secret_jwt", "private_key_jwt" ], "tls_client_certificate_bound_access_tokens" : true, "response_modes_supported" : [ "query", "form_post", "fragment" ], "backchannel_logout_session_supported" : true, "token_endpoint" : "https://redacted/oxauth/restv1/token", "response_types_supported" : [ "token", "id_token code", "id_token", "token code", "token id_token", "code", "token id_token code" ], "request_uri_parameter_supported" : true, "backchannel_user_code_parameter_supported" : false, "grant_types_supported" : [ "password", "implicit", "client_credentials", "urn:ietf:params:oauth:grant-type:uma-ticket", "refresh_token", "authorization_code" ], "ui_locales_supported" : [ "en", "bg", "de", "es", "fr", "it", "ru", "tr" ], "userinfo_endpoint" : "https://redacted/oxauth/restv1/userinfo", "op_tos_uri" : "http://ox.gluu.org/doku.php?id=oxauth:tos", "auth_level_mapping" : { "0" : [ "urn:openbanking:psd2:sca", "urn:openbanking:psd2:ca" ], "-1" : [ "simple_password_auth" ] }, "require_request_uri_registration" : false, "id_token_encryption_alg_values_supported" : [ "RSA1_5", "RSA-OAEP", "A128KW", "A256KW" ], "frontchannel_logout_session_supported" : true, "claims_locales_supported" : [ "en" ], "clientinfo_endpoint" : "https://redacted/oxauth/restv1/clientinfo", "request_object_signing_alg_values_supported" : [ "none", "HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "ES256", "ES384", "ES512" ], "request_object_encryption_alg_values_supported" : [ "RSA1_5", "RSA-OAEP", "A128KW", "A256KW" ], "session_revocation_endpoint" : "https://redacted/oxauth/restv1/revoke_session", "check_session_iframe" : "https://redacted/oxauth/opiframe.htm", "scopes_supported" : [ "address", "openid", "clientinfo", "user_name", "profile", "uma_protection", "permission", "revoke_session", "https://redacted/oxauth/restv1/uma/scopes/scim_access", "oxtrust-api-write", "oxtrust-api-read", "phone", "mobile_phone", "oxd", "super_gluu_ro_session", "email" ], "backchannel_logout_supported" : true, "acr_values_supported" : [ "simple_password_auth", "urn:openbanking:psd2:sca", "urn:openbanking:psd2:ca" ], "request_object_encryption_enc_values_supported" : [ "A128CBC+HS256", "A256CBC+HS512", "A128GCM", "A256GCM" ], "display_values_supported" : [ "page", "popup" ], "userinfo_signing_alg_values_supported" : [ "HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "ES256", "ES384", "ES512" ], "claim_types_supported" : [ "normal" ], "userinfo_encryption_alg_values_supported" : [ "RSA1_5", "RSA-OAEP", "A128KW", "A256KW" ], "end_session_endpoint" : "https://redacted/oxauth/restv1/end_session", "revocation_endpoint" : "https://redacted/oxauth/restv1/revoke", "backchannel_authentication_endpoint" : "https://redacted/oxauth/restv1/bc-authorize", "token_endpoint_auth_signing_alg_values_supported" : [ "HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "ES256", "ES384", "ES512" ], "frontchannel_logout_supported" : true, "jwks_uri" : "https://redacted/oxauth/restv1/jwks", "subject_types_supported" : [ "public", "pairwise" ], "id_token_signing_alg_values_supported" : [ "none", "HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "ES256", "ES384", "ES512" ], "registration_endpoint" : "https://redacted/oxauth/restv1/register", "id_token_token_binding_cnf_values_supported" : [ "tbh" ] } ```
Rhel 8.0
closed

Answers

By Michael Schwartz Account Admin 14 Aug 2020 at 4:09 p.m. CDT

Copy
Michael Schwartz gravatar
That's a weird message. It should tell you something more useful. One thing I notice is that that `redirect_uri` is not `https`.

By Rui Engana Account Admin 14 Aug 2020 at 4:14 p.m. CDT

Copy
Rui Engana gravatar
Yes, on development environment we don’t have https. I have strong reservations that redirect uri is related because if I remove acr_values from request parameters the auth flow works fine (using http redirect uri) Get Outlook for iOShttps://aka.ms/o0ukef>

By Rui Engana Account Admin 15 Aug 2020 at 3:05 a.m. CDT

Copy
Rui Engana gravatar
I have updates on this one. The ugly error was due to an issue with the OOTB Person Authenticaton Script. I didn't customise the script and assumed default aligned to Basic and OK, but appears default script added to new auths is broken. Nevertheless, I changed script for the two new types of authentication and I can now retrieve a ID Token with ACR claim. However, the value on ACR claim is incorrect :( it's returning 'auth1 auth2', that is the same value I passed on acr_values in authn start. Let's go back to basics, I initiated a AuthN with request parameter acr_values: 'auth1 auth2' to identify I need one of this auths completed. I expect the ID Token to have only one of this values, according to OIDC spec it should be evaluated in order, so auth1 will be preference. However, since Gluu has authLevels it can leverage that feature I would recommend to go for the higher first, then in order. Independently of how Gluu selected the auth to present to user, the resultant ID Token from AuthN should have a acr claim with a *single* auth value corresponding to the AuthN completed.

By Yuriy Zabrovarnyy staff 17 Aug 2020 at 8:08 a.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
Single `acr` claim presence for ID Token will be fixed in 4.2.1 within https://github.com/GluuFederation/oxAuth/issues/1446

By Rui Engana Account Admin 17 Aug 2020 at 8:15 a.m. CDT

Copy
Rui Engana gravatar
Hi Yuriy, thank you for referencing this, however, please note this issue in particular is related to processing of acr_values when multiple values are passed and selection of authn flow. Is this the also going to be fixed in 4.2.1? Thank you!

By Yuriy Zabrovarnyy staff 17 Aug 2020 at 8:45 a.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
AS publishes available level and acr as `auth_level_mapping` on `/.well-known/openid-configuration` page. In this way RP can decide what is preferred way of authentication. If multiple `acr_values` are sent then AS will process it in order in which it is provided by RP (letting RP decide order based on published level). ``` "auth_level_mapping" : { "1" : [ "basic_multi_authn", "basic_multi_authn_for_zico" ], "-1" : [ "simple_password_auth" ], "70" : [ "fido2" ], "60" : [ "super_gluu" ], "50" : [ "u2f" ], "20" : [ "basic_lock" ], "10" : [ "basic" ] }, ``` For example if RP send `acr_values=basic u2f` and `basic` is enabled and valid in given context then AS takes `basic` since it's first and after successful authentication `id_token` will contain `acr: basic`. Otherwise with same condition `acr_values=u2f basic`, `id_token` will contain `acr: u2f`. In case script is disabled then AS will take next valid acr (in first case `u2f` and in second `basic`). Will it work for you? We have ticket scheduled to disregard `acr_values` order and force processing based on level but it's scheduled on next version. https://github.com/GluuFederation/oxAuth/issues/1111 Is it important for you to add such handling ? (Given `auth_level_mapping` published on discovery page). Thanks, Yuriy Z

By Rui Engana Account Admin 17 Aug 2020 at 9:04 a.m. CDT

Copy
Rui Engana gravatar
Hi Yuriy, We don't need auth level handling for now, just to mention it's a good idea since Gluu has such feature and can leverage it when selecting authn flows. This feature might need a parameter for admin to control order selection. This ticket is mainly to report that if we send `acr_values=basic u2f` the resulting id_token will have acr claim like `acr: "basic u2f"` which is incorrect. Is this issue to be fixed with https://github.com/GluuFederation/oxAuth/issues/1446 Thanks, Rui

By Yuriy Zabrovarnyy staff 17 Aug 2020 at 10:21 a.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
Right, totally agree. Good, then for now in 4.2.1 we will make sure that `id_token` get *single* acr that was used during authentication. Thanks for feedback, Yuriy Z

By Rui Engana Account Admin 17 Aug 2020 at 10:23 a.m. CDT

Copy
Rui Engana gravatar
Brilliant! Thanks for confirming :)

By Yuriy Zabrovarnyy staff 18 Aug 2020 at 2:59 a.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
Hi Rui, Issue is fixed, latest 4.2.1 war file can be found here: https://ox.gluu.org/maven/org/gluu/oxauth-server/4.2.1-SNAPSHOT/oxauth-server-4.2.1-SNAPSHOT.war It would be great to get confirmation from you that everything works as expected. In case it will not, please attach `oxauth.log` in TRACE log level. Thanks, Yuriy Z

By Rui Engana Account Admin 18 Aug 2020 at 3:28 a.m. CDT

Copy
Rui Engana gravatar
Hi Yuriy, Thank you for quick response. I confirm the issue with multiple acr_values is now resolved. oxAuth return id_token with a single acr value corresponding to first authn enabled in Gluu. NOTE: In case none of the requested acr_values is enabled in Gluu and authn can't be executed, Gluu will return a nasty error :( I think this should be handled but maybe it wouldn't fit this patch level. Thanks, Rui

By Yuriy Zabrovarnyy staff 18 Aug 2020 at 3:43 a.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
Thanks for your quick feedback. Closing this ticket. Please reopen if needed. BR, Yuriy Z

Post an answer