Two sides, mismatched Auth Providers

This used to work, so I’m wondering if something changed in a recent SS version.

I have two webs on the same site - https://somesite.com/svc and https://somesite.com/rpt. The main svc site has 2 methods of authentication - one is a custom CredentialsAuthProvider (that’s only used as an Admin Back Door and on our beta testing site) - the second is an OAuthProvider that interfaces with Okta.

The rpt site has only the CredentialsAuthProvider, which works the same way as the one in the svc site. It is only used for integration tests.

The goal (which again, has worked in the past), is to allow logins from the svc site to work in the rpt site. What I’m finding is that when I use the backdoor/Credentials Auth Provider to login to svc, the rpt site works fine, but when I login to svc using the Okta provider, I get 401s on all my services in the rpt site. I have verified that both are looking at the same cache (Redis). The __type of the auth session in the cache matches exactly. The AuthProvider properties are different in the cached AuthSession, as I would expect. Would the lack of the OktaAuthProvider in the svc class cause an issue with sharing the cached auth session between the two sites?

Wouldn’t be able to identity the issue from just a description, but I’d be looking at the Session Cookies to see if the Auth Providers create an Authenticated Session in the registered caching provider.

The Session docs shows the Cache Key Format used to resolve the authenticated session. I would check what session cookies are being sent in HTTP Requests returning the 401 responses to see if they resolve an Authenticated User Session.

Found the issue - one of the Auth Providers was populating property UserAuthName and the other was not. Once the 2 auth providers both filled this in, the auth was shared across the web as expected.

1 Like