Our team is trying to implement a third party authentication called DocCheck. In our tests we have found an issue where sometimes authenticating using this service works and other times we get a 403 error code. We reached out to their team and they said:
What we experienced is, that sometimes the exact same session-ID is set for your users:
You pass this session-ID via the login ID and we hash it, so you can check if the user came from DocCheck. But every time, this exact session-ID gets set (and hashed from our end) we end up on the 403 on your end. Maybe that is a lead.
In general, we always succeed to pass the DocCheck end of the login, and we also end up on your target /content/site/country/j_brand_security with the expected parameters that are used for the authentication on your end (as far as we know): session_id and session_id_enc. But sometimes it throws the 403 and stops your authentication process.
Another thing that some customers are facing is too short timeframes when it comes to the authentication process. When timeframes are set too tightly, the authentication process could fail too. But the repeating session-ID seems very suspicious, so maybe it's worth digging deeper into that for now.
I have checked the logs and found the following repeating debug messages:
02.05.2021 00:00:00.093 *DEBUG* [qtp1051107223-482182] org.apache.sling.auth.core.impl.SlingAuthenticator doHandleSecurity: No credentials in the request, anonymous
02.05.2021 00:00:00.094 *DEBUG* [qtp1051107223-482182] org.apache.sling.auth.core.impl.SlingAuthenticator setAttributes: ResourceResolver stored as request attribute: user=anonymous
02.05.2021 00:00:00.882 *DEBUG* [qtp1051107223-481268] org.apache.sling.auth.core.impl.SlingAuthenticator getAuthenticationInfo: no handler could extract credentials; assuming anonymous