Closed bandhit closed 7 months ago
@bandhit, thank you for opening this issue. We will triage it within the next few business days.
I have just come across something related to the issue.
It seems like the Authorization Code replied from Azure AD B2C is longer than expected via comparing to Azure AD.
Azure AD B2C: more than 2,400 characters
eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMCIsInppcCI6IkRlZmxhdGUiLCJzZXIiOiIxLjAifQ..YMkkMiroq3rfMQdx.xXntiWZq-hz0mDlZZdm4x4fhE_HwwbI2-NY6U3fAt1hvSbdgtTpyk0XEC-fGFhWpKU54E3j-tIx-e03mj0Bkkc52DGDaFi7H9XtTIKlk_SdfW52C9SXwYXyvSsa4wRXS-L_L6JqubdLBIw1Ud-1MgXv2hHacTSEYBb_jvBWBbADb4Uvolt6HZ4QZinYVBvMQFa_dn_Y6LDlpa6pHXeWyrVCHZQtn5KHycI6Oxfm1pp7yWrLeH9DKbyv-LnqwDiCrvQYtM1XY6G6bDOMbh88OI0AkhsysWqBxgYHmaYlN0579YD-DOmqSBrd4VjgZ7qzIFD4Yeb6OPDG3-2VbuS0UYg2uki7BIltTgJSsRuuRzWtk3F4FKvD6DE3l00CcFRy6SnH9jzytHM2iku-4deNrkXUTbSRZuFGhJapdU_feTiLGr1qCgiQ6a2LyQ91yrwE48D39ERWv5Q8Dk2gP0S8eALhKEs29AaisahoeCf7kV9gvtuu_fbtgLVUlVGWmIjGkKEz8SmtZFlUZFm20jsh30gZkTM-SM49wxpmoEgvsLP4dIG6ozAsC8c0jD8fC5hXQ5DOMmCUBokrsicA0QwhpGvDY1DNn6c6gr23gXYElKA1NTWszxpCyi5k7ibDsd1nTYkXEJxssZteQk6raSs3gQRfs1i2PLeCIEHEbeP8Q3PoPP9ZaKGYRYKyYfub_tdIgBITElA0EdzHtrnIdgjDncfNjAeTEIzWXxeFuj6wpYTZxjPR2bTXkXYMdKZkB5F3dcvUSeY4OlaViLBJNjygYMBm2npf_c61qVashYkYgA7sO3hApfR_kT1fldqXRM3NDgO1c72dfxMxTZf6d7xhJ42-UKuxtTpUfyxruwcsgErqCtFmUhX-8jx4NJXU0IVgfNZ_fu8_Kcr98LA5EP7agMY7951zpwDDiZTvGiCLaSNGeOEM2QOJ9flOnfLf8a3eVkyRE8xuQSIu5Z1wRykK78HOFWvedtuQVFgqMUwjZBMC_OAmpZYofSDBi6cEhWSotTw8UmPXLwjq2PC9cAmwxNXDv9r-5uOjisMJPM02dwtVZ0aZ1F81vSdaeXXDckziFws5-rFCBzgagOFENpXzajJND_AIDoKMojgGhK-kGX4zeaR3joHMoGccIUXin-hXTWQU6B3ra1ryyBE-22X-eccjyQSi9n8XQ_VHFYzZNVIwLANkak4AZQAbyvT0HiSlW5SmBstu2ORtqb2UcPM6F6SekqQcq23US9H5fuZWb87YeB05K4Rl2GAlse2eInlaPbz47fN8r8t3wtJiBkUwgPH9-x_ZND_lqopQW2D6KjWf6owEOmo-LOzkDfreU8bQftGebIRU-WkXJ8HtiNKtlWnjzROEQgtTHVxUp5MEyxcBHMRLETlWnsbpwYQO20xBXxjmUIKam5cUOjV0sk26Rpw_79RHzxkN5t0Ui5poDaEnyda3ds3PcAFsG9z7ioeL1z_G2c9itYVJh2kSaUsd1K3yUxy8K_OljOdAqTMY4Bdc0K7hBX0kzxOZ30_17uo9hS0T98Yb5l_3LVTMPDs9hVEMAm3N5Cc_cl0QQS3sgW_n87-9tRfsCUx_rDzBH8EchgOZ_lCY3L1H4VsxvjSFpyha8T0E5EIr3SJTNdqNsy4g-SemjKcrWOMF0lyc3BvIlDy1Foqtmz1JC0k3xQqSSQUyqNM06tGlLQqelxejXbg28BMMmCNsOLdHDT8WHDa3MzBa9SYhl_iS8Arv0Z0v4uF5OBPsAw1V2mx1YpPyQ5URGV75LiaIi5dDifDLdCPs51l0uMkVkdBm6aWO_kzioP08hH0KqQBwnHq9WTTjUkpeDA-d19QdGUo3LD4z5XC8PIj7_KfXUcXb6_14P61GkyjHzSfBarQc5XLBTKfUDFrmWB503IXOrXWnlrqMeDXq1sPB067BX1M599y2fYZpAWi_vzTr_Lx6H8hmx8z30qf18O-Gy6unPv3ojRa3RLrCz4E0iyE1Z9v1NoVxPc-pI2eeJILum8ILARfyFyz5dK1envOo29dn6Kk22q49IZc1SXF-2S2JKyHtqk6e3hYMP5pdJnwBkBJPdiv4wM6aO8ztFd0qOPA8AZVrQzXh4RXavD65AMLqfq7vcmlsOeqanF1yZjqS8wYq3HGBEW2Zul6ntUVIoumVQa0pOActyPrZWEBOqmkZuoCNlau1H5SFcmgRIKxD7Q6e4JWoe100gO2Q1VLad8syXZb1X2RnM88Qe4YCRQD0N2zuXqH9tJWhrnlj9gDeAC9aU7cSO.kTpoJDfKaJnnOUCyAVa72g
Azure AD: around 1,000 characters
0.AT4ATsw-bHcgdk2sCnwU3uWblKt3a57vRcBIk998Bp7lmDs_AMA.AgABAAIAAAD--DLA3VO7QrddgJg7WevrAgDs_wUA9P9_RzrmPsJwODgCw4g7kFFgYR2ezs8148Ksb5mYZBakwsI34LP9Q4XuwumCQrkwLNGRCSzyQO0-4bBilARLwu6MTUFruXz7_tT1VTXRfEOKGi77Uo2zUgACBsEZNY5pJmfo7JDij2mDt9vMQbG6Qpd35cIHu9oy9PcYULVJyjghtrWw54KFTetb9ZW6HKMGxGr9__3hUUnTHYFTAL9hE7joX5Lqqyqu-ftepyQ3-7w6aPsJAh2VLA6JrRtWj14TU7z0PJFFPmCWtiXhbTfWEk0VfLaxtRk76KvRCCNth72Jd3-zQusziKugbseKd9RIj4w50jRBMPI7JAeDb3ZHvfrkqdMqr_41api7iyD7NIohBnY6omKudnf3DB9Wd0j2xxfDISwO06udkGsYQBQ7Ui88sO8sW4ZtPE34zz1-CzdlRU-p0Gp1y0Yk-AjOhlBHOKSUyRS7Bfwc4ys4f8HlxJvMCAlHyqdUbiRfg2hl4DwLLQHlZuuVACa7_OXUmoKtApRqabXIhW7RV6xqrs4KV2D-pQfe0uvmrfsTuZEjMV2UT6-iECKtT-obRBfXRofPqXyuakwxVMuCXNuv2tambWH81EO-WFYJePrW9T1g2r1vsyaIQrlGSJ5PTF6T70R6oKaUEjwlafGvcGLnaaBJugXQgWWjth9RDXuKcRJWOUWtIwSWPuDbVROhGxHd6oltLrJJFQTjwkYhP7RMOSfwn0WsiF9PJlcP4EQ_lYiMRirmE8kobe_wW4DJqwnecVKHD8Y2QVWHjKYb3ZYe0I4rYxK0SEilDqVyjvqHqP9a9jCMKJZzKhBVBYJy8w3DrpqJpBlnNEG88JOjUAMiEhvc9VjvAr34DAujyuG8PBRpz_Crgg4s
With that said, when requesting an Authorization Code via query response (response_mode=query
), we might hit the maximum length of a query string depending on the browser preference. For example, Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters.
I believe that the recent bug may not only be related to Azure API Management, but also Azure AD B2C.
Updated on 2023-04-20T22:00:00+09:00
I found that the error occurs when the length of the Authorization Code on query string exceeds 2,000 characters via Postman.
It is interesting to see that it also occurred on jwt.ms as well.
Same issue here. Didn't happen before until recently. Is there any way to configure response_mode=fragment
just like the one used by the OAuth signin widget?
@jimmidier As far as I know for now, if you have options more than Authorization Code flow and its PKCE, you could use other grant types for instance, ROPC flow and I can confirm that is working. At least it could prevent the app break when length of query parameter is exceeded its limit, but this only help you for short period of time. Microsoft recommends you do not use the ROPC flow.
I posted another issue about why AAD B2C Authorization Code is longer than 2000 characters.
I have the same problem.
This is very boring; the MS updated the application and broke another thing.
@carlos-rian-quartile @jimmidier It seems that I have identified the root problem. Azure AD B2C authorization code and refresh token size increase update
I'm not sure now, but it seems to be working correctly now. (Did they rolled it back?)
In past, sometimes the length of the query string reduces to approximately less than 2,000 chars, and the authentication starts working. However, randomly, the length of the authorization code increases and breaks the authentication as mentioned above.
To be honest, the breaking change that caused the authentication issue was poorly communicated, to say the least. The change may have been implemented without adequate notice or explanation, which can be frustrating for users who rely on the service. Clear communication and documentation are essential for ensuring a smooth transition and preventing issues like this from occurring in the future.
@bandhit I was just looking at the same post this morning and you were definitely right about this (good job man). And yes it's back to normal today. Not sure what they did but I couldn't help wondering if it'll just be one of the times that it intermittently works and soon broken again...
We do need a clarification on this before we have the confidence to close the issue. People won't be convinced to reimplement client side auth, or reduce output claims in their B2C policies (doesn't make sense to me), unless been given adequate explanations on what's going on under the hood and why we need to cater to the size change...
Hi @bandhit I tried again, but the specific bug doesn't appear.
But now I have this message:
Since the portal is a black box, I have no idea what's going on.
Hi @bandhit I tried again, but the specific bug doesn't appear.
But now I have this message:
Since the portal is a black box, I have no idea what's going on.
I "fix" this error by simultaneously enabling authorization code + PKCE and authorization code.
Once enabled, I tried to use the Authorization code + PKCE , but as expected, it gave an error.
So I changed it to just the authorization code like before, tried again, and now it's working again.
@jimmidier @carlos-rian-quartile According to eschillercourtalert post, he said they temporarily rolled back this change, but no word when the change will be permanently made.
If i'm understanding correctly, AAD OAuth2 requests should migrate from response_mode=query
to response_mode=from_post
.
Anyway, let's us hear conclusions from APIM developers.
This issue is related to managed developer portal. We advise you to create a Azure support request to get assistance on this issue. Please refer to the below link to create a new Azure support request, Please select Problem Type = "Developer Portal" in the request to route it appropriately.
Bug description
I recently discovered an unusual bug on the developer portal when attempting to log in using the OAuth 2.0 authentication code flow. In the past, I had never experienced this before. Additionally, I didn't make any changes to the Azure App Registration recently. However, it is interesting to see that the behavior is random - sometimes it happens, and sometimes it doesn't. Please see the screenshot below for more information.
Preliminary steps
Reproduction steps
Expected behavior
It should receive and access the token, and then place them in the HTTP header automatically.
Is your portal managed or self-hosted?
Managed
API Management service name
apim-rdgconnect-sv-preview
Environment
Additional context
I believe it relates to the following issue: #2135