OktaAuthStateService.authState does not correctly reflect user's state when user is authenticated but not authorized

[nathaniellee87]

Describe the bug?

OktaAuthStateService.authState does not correctly reflect user's state when user is authenticated but not authorized. The OktaAuthStateService.authState.isAuthenticated member has the value of false and OktaAuthStateService.authState..idToken is undefined after the user has successfully logged in and been authenticated. However, the user is not authorized and receives the error "OAuthError: User is not assigned to the client application". Okta Angular treats the user as logged in when I run OktaAuth.signInWithRedirect() (it doesn't not redirect me, but recognizes I'm authenticated and just redirects me to the callback). If I run OktaAuth.signOut(), it successfully signs me out and redirects me to the Okta login page. Despite this, the OktaAuthStateService.authState does not correctly reflect the user's state.

What is expected to happen?

The OktaAuthStateService.authState should correctly reflect the user's state (such as being authenticated but not authorized). User information (such is via [OktaAuthStateService.authState.idToken)] should be provided so that the user's state can be correctly displayed on the UI (such as user's name).

What is the actual behavior?

OktaAuthStateService.authState does not correctly reflect the user's state; if the user is authenticated but not authorized, OktaAuthStateService.authState.isAuthenticated is false and no user information is provided for the authenticated user (such is via OktaAuthStateService.authState.idToken).

Reproduction Steps?

1. Add Okta configuration to app.module.ts per Okta documentation with pkce: true
2. Add guards and callback to Routes array per Okta documentation
3. Do NOT assign the user to the application
4. Navigate to the with the protected route of web app to initiate login redirect
5. Log in
6. View the OktaAuthStateService.authState object to see if it reflects the user's state.

SDK Versions

"@angular/animations": "=13.1.2",
"@angular/cdk": "=12.2.0",
"@angular/common": "=13.1.2",
"@angular/compiler": "=13.1.2",
"@angular/core": "=13.1.2",
"@angular/forms": "=13.1.2",
"@angular/material": "=12.2.0",
"@angular/platform-browser": "=13.1.2",
"@angular/platform-browser-dynamic": "=13.1.2",
"@angular/router": "=13.1.2",
"@azure/msal-angular": "=2.0.5",
"@azure/msal-browser": "=2.19.0",
"@microsoft/signalr": "=6.0.1",
"@okta/okta-angular": "=5.2.0",
"@okta/okta-auth-js": "=6.5.0",
"ajv": "=6.12.3",
"rxjs": "=6.6.0",
"tslib": "=2.3.0",
"zone.js": "=0.11.4"

Execution Environment

Chrome Version 101.0.4951.67 (Official Build) (64-bit)
Windows 10 Version 20H2 (19042.1706)
Angular 13

Additional Information?

No response

[aarongranick-okta]

@nathaniellee87 Thank you for the report. As I understand it, the behavior you are describing is working as designed. This SDK is designed for OIDC applications, and there is no fine-grained distinction between being authenticated with Okta (having an SSO session), vs. having valid tokens in the application. Valid OAuth tokens (id_token and access_token) is the definition of isAuthenticated as far as this SDK is concerned. In this case, the app is receiving an OIDC error on its redirect callback. The app should be prepared to handle errors on the callback and display them appropriately to the user. This particular error is non-recoverable by the user. An Administrator will need to adjust the policy to allow this user to access the app.

If you'd like to determine if a user has a valid SSO session outside of the OIDC flow, you can use the session API: https://github.com/okta/okta-auth-js#session

However, these methods do require access to 3rd party cookies which may be blocked by default in some browsers.

[nathaniellee87]

@aarongranick-okta The user shows having an active session even though they receive that error. Shouldn't they NOT have an active session since they received that error? My issue is the SDK does not accurately display the user's state (in this case, being authenticated and having an active, valid session). Right now, as it stands, when they receive that error, the SDK says they are not authenticated. So I display the error and enable the Log In button in the toolbar. But if they click the Log In button, it just redirects them right back where they were (the page with the error) without going through authentication again since they have an active, valid session. This would be a confusing situation for the user.

[busbina]

I can reproduce this. If a user is signed in already, I assign the user to the application; OKTA will return an error query string saying that the user is not assigned to the application. If the user then signs out and signs back in OR the user signs in on an incognito window, the issue will be fixed. From my end, the application list is cached on login and not updated when the user is added to the application.