Current Limitation
In the Wayfinder sample, the user is forced to authenticate twice: once to access the application and again to access the chat. This produces a poor login experience where the user appears to "re-login" even though they already have an active session.
This happens because of how access tokens are issued today. When requesting a token, the sample passes a resource server (audience) in the token request, so ThunderID issues an access token that is bound to a single resource server. As a result:
One access token is valid for exactly one resource server.
The app and the chat are treated as separate resource servers, so the token obtained for the app cannot be reused for the chat.
To call the chat, the sample initiates a fresh token request, which triggers a full login flow again.
Suggested Improvement
Add SSO support to the Wayfinder sample so that the second (and subsequent) token acquisitions reuse the existing authenticated session instead of prompting the user to log in again.
The security model of resource-server-bound tokens stays intact (each resource server still gets its own scoped token), but token acquisition for additional resource servers becomes silent:
- When the app has already established a session with ThunderID, requesting an access token for the chat resource server should leverage that session and skip the interactive login prompt.
- The user logs in once; tokens for the app and the chat are then obtained transparently behind the scenes, each still audience-restricted to its own resource server.
Current Limitation
In the Wayfinder sample, the user is forced to authenticate twice: once to access the application and again to access the chat. This produces a poor login experience where the user appears to "re-login" even though they already have an active session.
This happens because of how access tokens are issued today. When requesting a token, the sample passes a resource server (audience) in the token request, so ThunderID issues an access token that is bound to a single resource server. As a result:
One access token is valid for exactly one resource server.
The app and the chat are treated as separate resource servers, so the token obtained for the app cannot be reused for the chat.
To call the chat, the sample initiates a fresh token request, which triggers a full login flow again.
Suggested Improvement
Add SSO support to the Wayfinder sample so that the second (and subsequent) token acquisitions reuse the existing authenticated session instead of prompting the user to log in again.
The security model of resource-server-bound tokens stays intact (each resource server still gets its own scoped token), but token acquisition for additional resource servers becomes silent: